From nobody Mon Jan 1 14:33:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DAF1200C5 for ; Mon, 1 Jan 2018 14:33:31 -0800 (PST) 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 GclNr5Md-DJT for ; Mon, 1 Jan 2018 14:33:29 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 385711201F2 for ; Mon, 1 Jan 2018 14:33:29 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id d10so3621646oti.7 for ; Mon, 01 Jan 2018 14:33:29 -0800 (PST) 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=xRhrTT9uk4voz2jjUhbya4st2t8765OKlHwEGlrgmK4=; b=q3b750lBG9Ix9DkcMqO6cQ1QM/eOsLmhp8U0DV+KuS5MBwHQY1F4V0a2hqKfpjuhAe KYn0i0uCku/IcDHsQ9tO0CRX0gjf05dflzHJSP42Vm7YwZFG3AFiUApQQFLJmyvfUvnp 3rKHOTCqi0CXPXJuAdHZUxbFKAwm4bEOQo5kogb3rjrv3pAVuKLlhOljBUDaqEyfblEW G8HPW+PCaONYD36Qm4j9XsR5sYiDAVzr1uvZBZJ3XhP83Y4nrVWWbAttdUPF/SxQbp6x nhWAbfU6weGkojyRx83rWlA+Hua/2e5rnuzTAUoGZYFvAUYMfWZnJPCZ+nT9Hw4eXZXG mUWA== 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=xRhrTT9uk4voz2jjUhbya4st2t8765OKlHwEGlrgmK4=; b=N95d73nEvyZD4nwQFFrmJAt3akGQvwjBUkMivH6TDwRXPQVHvv3mXkcAjJz7GrjWkA wtW1QCEOWVtktaEYwHJDjzjcPsxUz48kAWExRFCc/CE5DJ1WUO+x/Ovd6s237fCVjVv3 HYPHwG2eKSCclmenlOBgd1IANjEMCWJWGT7Z4C4IrmADDn8xKzJE8HmeadGbvpyIoP84 bXRTXXQ3whQKEbbB9SbABX47lOiUjUWr4dU01vG5JNULSDlJT4kJSj5z4LFm383sPf1U d34wypwnAz6BgxaY0UDNxkroJ09niZRdkXh/xqPyw9M65drEp0+lfK6ZBrkKonG3DGrQ Co7g== X-Gm-Message-State: AKGB3mIOckojMb70ywGbddBqRZshQmLg9pAX3ND5dv6V0ael9QS7/gYQ ujWAxkzfKKTA7Mor/Oq2eiQe97sGULEyWWjrVOeYHg== X-Google-Smtp-Source: ACJfBovuL0qeSqeZnhWHSn4n1O1+KTAq5Z14Img2L32yTHuXdzGSWMUxe6jQjZ/XrW14qYK9+TV1nd+9BQl/80Fv6+8= X-Received: by 10.157.88.140 with SMTP id x12mr30022798otg.175.1514846008446; Mon, 01 Jan 2018 14:33:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 14:33:27 -0800 (PST) In-Reply-To: <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 09:33:27 +1100 Message-ID: Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt To: Christian Huitema Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="f4030438fa543913460561be928d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 01 Jan 2018 22:33:31 -0000 --f4030438fa543913460561be928d Content-Type: text/plain; charset="UTF-8" Thanks for doing this Christian. The think that I'm most interested in here is how this relates to the invariants we have established. I don't think that it has any impact and you seem to agree. So I think we're good. I don't think that the section on flow control makes any sense, since flow control operates at your stream layer. I'm going to have to think on it some more, but your suggestion in 4.7 might be a good idea. We don't have to do that now, though we might choose to do so if we can work through the design and implications. On Thu, Dec 28, 2017 at 8:11 AM, Christian Huitema wrote: > Yes, I know full well that multipath is not in scope for V1. But since we > are dabbling in connection migration anyhow, I thought we could just as > well have a document listing multipath requirements and issues... > > -- Christian Huitema > > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt > Date: Wed, 27 Dec 2017 13:07:17 -0800 > From: internet-drafts@ietf.org > To: Christian Huitema > > A new version of I-D, draft-huitema-quic-mpath-req-00.txt > has been successfully submitted by Christian Huitema and posted to the > IETF repository. > > Name: draft-huitema-quic-mpath-req > Revision: 00 > Title: QUIC Multipath Requirements > Document date: 2017-12-27 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-huitema-quic-mpath-req-00.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/ > Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-req-00 > > > Abstract: > This document describes the requirement and plausible architecture of > QUIC multipath extensions. While the first version of QUIC is not > scheduled to include multipath extensions, there are risks that > decisions made in this first version might preclude some options that > we may later find attractive. An early review of multipath extension > requirements and issues should minimize that risk. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > --f4030438fa543913460561be928d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for doing this Christian.

=
The think that I'm most interested in here is how this relates to = the invariants we have established.=C2=A0 I don't think that it has any= impact and you seem to agree.=C2=A0 So I think we're good.

I don't think that the section on flow control makes = any sense, since flow control operates at your stream layer.

=
I'm going to have to think on it some more, but your suggest= ion in 4.7 might be a good idea.=C2=A0 We don't have to do that now, th= ough we might choose to do so if we can work through the design and implica= tions.

On Thu, Dec 28, 2017 at 8:11 AM, Christian Huitema &= lt;huitema@huitema= .net> wrote:
=20 =20 =20

Yes, I know full well that multipath is not in scope for V1. But since we are dabbling in connection migration anyhow, I thought we could just as well have a document listing multipath requirements and issues...

-- Christian Huitema



-------- Forwarded Message --------
Subject: New Version Notification for draft-huitema-quic-mpath-req-00.txt
Date: Wed, 27 Dec 2017 13:07:17 -0800
From: internet-drafts= @ietf.org
To: Christian Huitema <h= uitema@huitema.net> 


A new version of I-D, draft-huitema-quic-mpath-req-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-quic-mpath-req
Revision:	00
Title:		QUIC Multipath Requirements
Document date:	2017-12-27
Group:		Individual Submission
Pages:		11
URL:            https://www.ietf.org/internet-drafts/draft-huit=
ema-quic-mpath-req-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-quic-mpath=
-req/
Htmlized:       https://tools.ietf.org/html/draft-huitema-quic-mpath-req-<=
wbr>00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitem=
a-quic-mpath-req-00


Abstract:
   This document describes the requirement and plausible architecture of
   QUIC multipath extensions.  While the first version of QUIC is not
   scheduled to include multipath extensions, there are risks that
   decisions made in this first version might preclude some options that
   we may later find attractive.  An early review of multipath extension
   requirements and issues should minimize that risk.

                                                                           =
      =20


Please note that it may take a couple of minutes from the time of submissio=
n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--f4030438fa543913460561be928d-- From nobody Mon Jan 1 17:57:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B383F126C89 for ; Mon, 1 Jan 2018 17:57:13 -0800 (PST) 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 GqavfgjWuRXe for ; Mon, 1 Jan 2018 17:57:11 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 CDCD81242EA for ; Mon, 1 Jan 2018 17:57:11 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id q5so20263348oth.2 for ; Mon, 01 Jan 2018 17:57:11 -0800 (PST) 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=xBHqGvyYBCDHs0vKolfxWs8iHMFQYTgOBz5gf14Q1Hk=; b=hr40xGEVwkK1lVJTadeVchtbD6IAUTRTi2mxojqmcT+BhHcbAelwbpGY9LeSKVlfFu FAIbVlZdDNqa/HgBu/UGlyWAK0xHHbs8sEWOaykCFRAY7eW+0aLDnVhUjh4caMvGD1ti dFVdv8hZZFmC37oZ1BtLU0e0M1XEI2c+tHpxNi+0PnPvdeQ4PA5M10Pe/SJAgn7hs0O/ /S+5lTjKDRyPoBTm5DJuWBjckPs6wnKZavZa3jQ4X0BorYWegu8fJ/h4De1t5ch6i28T YhrmmoZWUAbv1luk03aR08ATdveg4I+yBeK7aVv54/nG2IDmP+KbQ21TEOzpDsT2sDNn Zh1w== 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=xBHqGvyYBCDHs0vKolfxWs8iHMFQYTgOBz5gf14Q1Hk=; b=Wmc2TGFQzX9iMEjf8eaexKgIQGK02CFFdpK3tJIXnDt1FWpTRHSIyGeODk2HFvwdRR JS+oWPv47yGYiJZqhWHeXeM4o4IG0CwTVV3t3ZwfC2cjqTc8Ruh1Dv3IgFmtv8dHpTSH gxLAutNxbMOrR6aENDNRQS/47LaRAzK92irFMkHXcgF5yTFNJBidlE0SK8lBYH1YU0I9 eHYUmGpkVV4Z73pUVVDPQtK7O16p/u9XtyccVndjgOSMaCOC7gRh6E1C69ddYBpucFwy xcgkJmiQ5fbJuQDgq+X5jlxG0gixrl3/ialmjYBBoJeAInAcW49Jl3MqxCn0CXnbjRhk wUMQ== X-Gm-Message-State: AKGB3mJRt/U3jQp8P/XAB/93shOkYq2VMp3oAvVwg8bg+XoKdlSytLED rbpaoIrvFyb8pKsuN054MokpV9FfKkeFQDdcid71oecl X-Google-Smtp-Source: ACJfBoug7ZA937vYFxkOaDl81QsETE3nY68Ta5liRt91v8hCGWEao7V8iPOcFTqsq0YehXsz4BKyEa9X9ADCyJPP7rY= X-Received: by 10.157.88.140 with SMTP id x12mr30193293otg.175.1514858230687; Mon, 01 Jan 2018 17:57:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 17:57:10 -0800 (PST) From: Martin Thomson Date: Tue, 2 Jan 2018 12:57:10 +1100 Message-ID: Subject: Removing packet number gaps 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, 02 Jan 2018 01:57:14 -0000 There are number of problems with packet number gaps that I think we need to address. Most are minor. For instance, the initial packet number is not close to zero, which inflates the size of ACK frames from the very beginning of a connection. However, Christian just identified one that I think makes this more important to address: when using a new connection ID, the gap is the same size on both client and server. This makes flows linkable. The gaps between the last packet on the old flow and the first packet on the new flow can be calculated in both directions. Flows can be linked by finding flows where client-to-server packets have the same (or very close) gaps as server-to-client packets. With a few small tweaks to the current design, I think that we get a much better solution. Here is what I propose: Firstly, packet numbers start at zero and always increase monotonically, with no gaps. A side benefit of this is that the first ACK frame will have a small encoding for largest_acknowledged (1 octet rather than 8 in most cases). Packet numbers are never encoded directly onto the wire, they are XORed with a masking value. This value will change for different packet protection keys, and for different connection IDs. Client and server will use different values so that gaps are hard to detect. Thus, we will have a third key derivation: key = QHKDF-Expand(S, "key", key_length) iv = QHKDF-Expand(S, "iv", iv_length) pnmask = QHKDF-Expand(S, "pnmask", 4) To make this work seamlessly, I'm proposing a tweak to QHKDF-Expand that includes the connection ID. For that, the "Context" field that we currently do not use seems like a good choice. This will mean changes to the other uses of QHKDF-Expand: * the handshake secret can be changed to be a fixed rather than a derived value, so that we don't need to use the function (connection ID will be added during expansion into the separate keys) * during a key update, a zero-length or fixed connection ID will need to be used so that there is no confusion about which connection ID was in use at the time the update was made (editorially, I'm not certain how to manage this one, I might just go back to using HKDF-Expand-Label directly for that) Finally, we need to be very clear that even if the connection ID is omitted, those packets still use the implied connection ID in key derivation. We will probably want to recommend that endpoints include a connection ID if they intend to support NEW_CONNECTION_ID or any of the related functions, at least around the time when a connection ID change is in place or the recipient of their packets could have difficulty picking the right keys. This is already a problem of course, but this change would make it worse. From nobody Mon Jan 1 18:13:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561881242EA for ; Mon, 1 Jan 2018 18:13:18 -0800 (PST) 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 zFItRSoeQkOL for ; Mon, 1 Jan 2018 18:13:16 -0800 (PST) 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 29A1C124234 for ; Mon, 1 Jan 2018 18:13:16 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eWC4m-0003mb-Gf for quic@ietf.org; Tue, 02 Jan 2018 03:13:13 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eWC4j-0005qo-HK for quic@ietf.org; Mon, 01 Jan 2018 21:13:11 -0500 Received: (qmail 838 invoked from network); 2 Jan 2018 02:13:07 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jan 2018 02:13:07 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Mon, 1 Jan 2018 18:13:03 -0800 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net> References: To: Martin Thomson Subject: Re: Removing packet number gaps X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gP9yNhAIum9djc75Dnrb6wXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fviwdKnRFViULLhLsmA3fZmB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CjFWgoBUVwntDlC94eiuSMB7gpDNdnenm6TrtCAMOwt1x6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGGzfvfqbdVzWjqC7Wi9Hpea9ribYaFEt5OQzwoifSBR/1 1x8phGMqCLJRaypsRWHLJ1qvkkW9+eJtkgnkYIgKzFz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBCPpTKZiPZvKq7DOUCmAqiB3h1vgDbEdmhrg3iVBpdRYXfz7Ut3+jmMYKlY7u0PndGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 02:13:18 -0000 For clarification: are you proposing to make the encryption key and IV depen= dent on the connection ID, or just the packet number mask? Also, are you proposing applying the mask before encoding the packet header o= n 1, 2, 4 or 8 bytes, or after that? -- Christian Huitema=20 > On Jan 1, 2018, at 5:57 PM, Martin Thomson wrot= e: >=20 > There are number of problems with packet number gaps that I think we > need to address. Most are minor. For instance, the initial packet > number is not close to zero, which inflates the size of ACK frames > from the very beginning of a connection. >=20 > However, Christian just identified one that I think makes this more > important to address: when using a new connection ID, the gap is the > same size on both client and server. This makes flows linkable. The > gaps between the last packet on the old flow and the first packet on > the new flow can be calculated in both directions. Flows can be > linked by finding flows where client-to-server packets have the same > (or very close) gaps as server-to-client packets. >=20 > With a few small tweaks to the current design, I think that we get a > much better solution. Here is what I propose: >=20 > Firstly, packet numbers start at zero and always increase > monotonically, with no gaps. A side benefit of this is that the first > ACK frame will have a small encoding for largest_acknowledged (1 octet > rather than 8 in most cases). >=20 > Packet numbers are never encoded directly onto the wire, they are > XORed with a masking value. This value will change for different > packet protection keys, and for different connection IDs. Client and > server will use different values so that gaps are hard to detect. >=20 > Thus, we will have a third key derivation: >=20 > key =3D QHKDF-Expand(S, "key", key_length) > iv =3D QHKDF-Expand(S, "iv", iv_length) > pnmask =3D QHKDF-Expand(S, "pnmask", 4) >=20 > To make this work seamlessly, I'm proposing a tweak to QHKDF-Expand > that includes the connection ID. For that, the "Context" field that > we currently do not use seems like a good choice. >=20 > This will mean changes to the other uses of QHKDF-Expand: >=20 > * the handshake secret can be changed to be a fixed rather than a > derived value, so that we don't need to use the function (connection > ID will be added during expansion into the separate keys) >=20 > * during a key update, a zero-length or fixed connection ID will need > to be used so that there is no confusion about which connection ID was > in use at the time the update was made (editorially, I'm not certain > how to manage this one, I might just go back to using > HKDF-Expand-Label directly for that) >=20 > Finally, we need to be very clear that even if the connection ID is > omitted, those packets still use the implied connection ID in key > derivation. We will probably want to recommend that endpoints include > a connection ID if they intend to support NEW_CONNECTION_ID or any of > the related functions, at least around the time when a connection ID > change is in place or the recipient of their packets could have > difficulty picking the right keys. This is already a problem of > course, but this change would make it worse. >=20 From nobody Mon Jan 1 18:15:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF44126C89 for ; Mon, 1 Jan 2018 18:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4VyeygcNeCh for ; Mon, 1 Jan 2018 18:15:27 -0800 (PST) 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 20243124234 for ; Mon, 1 Jan 2018 18:15:27 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id w022BtT8028804; Tue, 2 Jan 2018 02:15:24 GMT 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 : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Yrzjs1GyAonq97WAedWfq+ibqowhVSlmjZ1WG66func=; b=ZQo5FEMocWSvFKPTRvXybM04g0S1tFa5Z5obkMuwkv+VQ2jBNZ7D8SEqxKh+5IQcX9h+ N7X68KaJF3T0f+VeaiH2gvdWxsfoXmei8Y9rK7/TO0ci+MSnDoPN1eVxReyO3iVs8bG8 GmhXZOB4rrGhaxLS6DV+Jjpd+GqNndXOlR2/1aPQeGcJV3r90Ks9qCw1gaQiR8i+YjFh as9ZWPKef5vxcyFa3b6L1tMmRGAbQi+zU5I6ZxQwUi3pp9QNr79DYf1s5g7lWhXaG0GZ sibXE+9kQY6VYl0XkJb8f/lE6q0pSu1L+Bl5nhgUsIpMUzLTAfUbz5hDBOa1ltpjorqg dA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2f62x8x7f7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Jan 2018 02:15:24 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w022B4Qg021737; Mon, 1 Jan 2018 21:15:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2f670yr3g8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 01 Jan 2018 21:15:23 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 1 Jan 2018 21:15:22 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 1 Jan 2018 21:15:22 -0500 From: "Lubashev, Igor" To: Martin Thomson , QUIC WG Subject: RE: Removing packet number gaps Thread-Topic: Removing packet number gaps Thread-Index: AQHTg20GYycQfBTojkSomN6WJ1vUtaNf1wqQ Date: Tue, 2 Jan 2018 02:15:22 +0000 Message-ID: <78d51955754d41f081561ffca6f23dee@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.35.58] 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=2018-01-02_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-02_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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801020030 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Jan 2018 02:15:30 -0000 Q291bGQgd2UgdXNlIFBMVVMgaW5zdGVhZCBvZiBYT1I/ICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRo YXQgdGhlcmUgaXMgbGl0dGxlIGNyeXB0b2dyYXBoaWMgZGlmZmVyZW5jZSBiZXR3ZWVuIFhPUiBh bmQgUExVUywgYW5kIGl0IGlzIG5pY2VyIHRvIGhhdmUgY29uc2VjdXRpdmUgcGFja2V0IG51bWJl cnMgb24gdGhlIHdpcmUuLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1h cnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IE1v bmRheSwgSmFudWFyeSAwMSwgMjAxOCA4OjU3IFBNDQpUbzogUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlbW92aW5nIHBhY2tldCBudW1iZXIgZ2Fwcw0KDQpUaGVyZSBhcmUgbnVt YmVyIG9mIHByb2JsZW1zIHdpdGggcGFja2V0IG51bWJlciBnYXBzIHRoYXQgSSB0aGluayB3ZSBu ZWVkIHRvIGFkZHJlc3MuICBNb3N0IGFyZSBtaW5vci4gIEZvciBpbnN0YW5jZSwgdGhlIGluaXRp YWwgcGFja2V0IG51bWJlciBpcyBub3QgY2xvc2UgdG8gemVybywgd2hpY2ggaW5mbGF0ZXMgdGhl IHNpemUgb2YgQUNLIGZyYW1lcyBmcm9tIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiBhIGNvbm5lY3Rp b24uDQoNCkhvd2V2ZXIsIENocmlzdGlhbiBqdXN0IGlkZW50aWZpZWQgb25lIHRoYXQgSSB0aGlu ayBtYWtlcyB0aGlzIG1vcmUgaW1wb3J0YW50IHRvIGFkZHJlc3M6IHdoZW4gdXNpbmcgYSBuZXcg Y29ubmVjdGlvbiBJRCwgdGhlIGdhcCBpcyB0aGUgc2FtZSBzaXplIG9uIGJvdGggY2xpZW50IGFu ZCBzZXJ2ZXIuICBUaGlzIG1ha2VzIGZsb3dzIGxpbmthYmxlLiAgVGhlIGdhcHMgYmV0d2VlbiB0 aGUgbGFzdCBwYWNrZXQgb24gdGhlIG9sZCBmbG93IGFuZCB0aGUgZmlyc3QgcGFja2V0IG9uIHRo ZSBuZXcgZmxvdyBjYW4gYmUgY2FsY3VsYXRlZCBpbiBib3RoIGRpcmVjdGlvbnMuICBGbG93cyBj YW4gYmUgbGlua2VkIGJ5IGZpbmRpbmcgZmxvd3Mgd2hlcmUgY2xpZW50LXRvLXNlcnZlciBwYWNr ZXRzIGhhdmUgdGhlIHNhbWUgKG9yIHZlcnkgY2xvc2UpIGdhcHMgYXMgc2VydmVyLXRvLWNsaWVu dCBwYWNrZXRzLg0KDQpXaXRoIGEgZmV3IHNtYWxsIHR3ZWFrcyB0byB0aGUgY3VycmVudCBkZXNp Z24sIEkgdGhpbmsgdGhhdCB3ZSBnZXQgYSBtdWNoIGJldHRlciBzb2x1dGlvbi4gIEhlcmUgaXMg d2hhdCBJIHByb3Bvc2U6DQoNCkZpcnN0bHksIHBhY2tldCBudW1iZXJzIHN0YXJ0IGF0IHplcm8g YW5kIGFsd2F5cyBpbmNyZWFzZSBtb25vdG9uaWNhbGx5LCB3aXRoIG5vIGdhcHMuICBBIHNpZGUg YmVuZWZpdCBvZiB0aGlzIGlzIHRoYXQgdGhlIGZpcnN0IEFDSyBmcmFtZSB3aWxsIGhhdmUgYSBz bWFsbCBlbmNvZGluZyBmb3IgbGFyZ2VzdF9hY2tub3dsZWRnZWQgKDEgb2N0ZXQgcmF0aGVyIHRo YW4gOCBpbiBtb3N0IGNhc2VzKS4NCg0KUGFja2V0IG51bWJlcnMgYXJlIG5ldmVyIGVuY29kZWQg ZGlyZWN0bHkgb250byB0aGUgd2lyZSwgdGhleSBhcmUgWE9SZWQgd2l0aCBhIG1hc2tpbmcgdmFs dWUuICBUaGlzIHZhbHVlIHdpbGwgY2hhbmdlIGZvciBkaWZmZXJlbnQgcGFja2V0IHByb3RlY3Rp b24ga2V5cywgYW5kIGZvciBkaWZmZXJlbnQgY29ubmVjdGlvbiBJRHMuICBDbGllbnQgYW5kIHNl cnZlciB3aWxsIHVzZSBkaWZmZXJlbnQgdmFsdWVzIHNvIHRoYXQgZ2FwcyBhcmUgaGFyZCB0byBk ZXRlY3QuDQoNClRodXMsIHdlIHdpbGwgaGF2ZSBhIHRoaXJkIGtleSBkZXJpdmF0aW9uOg0KDQog ICBrZXkgPSBRSEtERi1FeHBhbmQoUywgImtleSIsIGtleV9sZW5ndGgpDQogICBpdiAgPSBRSEtE Ri1FeHBhbmQoUywgIml2IiwgaXZfbGVuZ3RoKQ0KICAgcG5tYXNrID0gUUhLREYtRXhwYW5kKFMs ICJwbm1hc2siLCA0KQ0KDQpUbyBtYWtlIHRoaXMgd29yayBzZWFtbGVzc2x5LCBJJ20gcHJvcG9z aW5nIGEgdHdlYWsgdG8gUUhLREYtRXhwYW5kIHRoYXQgaW5jbHVkZXMgdGhlIGNvbm5lY3Rpb24g SUQuICBGb3IgdGhhdCwgdGhlICJDb250ZXh0IiBmaWVsZCB0aGF0IHdlIGN1cnJlbnRseSBkbyBu b3QgdXNlIHNlZW1zIGxpa2UgYSBnb29kIGNob2ljZS4NCg0KVGhpcyB3aWxsIG1lYW4gY2hhbmdl cyB0byB0aGUgb3RoZXIgdXNlcyBvZiBRSEtERi1FeHBhbmQ6DQoNCiogdGhlIGhhbmRzaGFrZSBz ZWNyZXQgY2FuIGJlIGNoYW5nZWQgdG8gYmUgYSBmaXhlZCByYXRoZXIgdGhhbiBhIGRlcml2ZWQg dmFsdWUsIHNvIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byB1c2UgdGhlIGZ1bmN0aW9uIChjb25uZWN0 aW9uIElEIHdpbGwgYmUgYWRkZWQgZHVyaW5nIGV4cGFuc2lvbiBpbnRvIHRoZSBzZXBhcmF0ZSBr ZXlzKQ0KDQoqIGR1cmluZyBhIGtleSB1cGRhdGUsIGEgemVyby1sZW5ndGggb3IgZml4ZWQgY29u bmVjdGlvbiBJRCB3aWxsIG5lZWQgdG8gYmUgdXNlZCBzbyB0aGF0IHRoZXJlIGlzIG5vIGNvbmZ1 c2lvbiBhYm91dCB3aGljaCBjb25uZWN0aW9uIElEIHdhcyBpbiB1c2UgYXQgdGhlIHRpbWUgdGhl IHVwZGF0ZSB3YXMgbWFkZSAoZWRpdG9yaWFsbHksIEknbSBub3QgY2VydGFpbiBob3cgdG8gbWFu YWdlIHRoaXMgb25lLCBJIG1pZ2h0IGp1c3QgZ28gYmFjayB0byB1c2luZyBIS0RGLUV4cGFuZC1M YWJlbCBkaXJlY3RseSBmb3IgdGhhdCkNCg0KRmluYWxseSwgd2UgbmVlZCB0byBiZSB2ZXJ5IGNs ZWFyIHRoYXQgZXZlbiBpZiB0aGUgY29ubmVjdGlvbiBJRCBpcyBvbWl0dGVkLCB0aG9zZSBwYWNr ZXRzIHN0aWxsIHVzZSB0aGUgaW1wbGllZCBjb25uZWN0aW9uIElEIGluIGtleSBkZXJpdmF0aW9u LiAgV2Ugd2lsbCBwcm9iYWJseSB3YW50IHRvIHJlY29tbWVuZCB0aGF0IGVuZHBvaW50cyBpbmNs dWRlIGEgY29ubmVjdGlvbiBJRCBpZiB0aGV5IGludGVuZCB0byBzdXBwb3J0IE5FV19DT05ORUNU SU9OX0lEIG9yIGFueSBvZiB0aGUgcmVsYXRlZCBmdW5jdGlvbnMsIGF0IGxlYXN0IGFyb3VuZCB0 aGUgdGltZSB3aGVuIGEgY29ubmVjdGlvbiBJRCBjaGFuZ2UgaXMgaW4gcGxhY2Ugb3IgdGhlIHJl Y2lwaWVudCBvZiB0aGVpciBwYWNrZXRzIGNvdWxkIGhhdmUgZGlmZmljdWx0eSBwaWNraW5nIHRo ZSByaWdodCBrZXlzLiAgVGhpcyBpcyBhbHJlYWR5IGEgcHJvYmxlbSBvZiBjb3Vyc2UsIGJ1dCB0 aGlzIGNoYW5nZSB3b3VsZCBtYWtlIGl0IHdvcnNlLg0KDQo= From nobody Mon Jan 1 19:39:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A4E126C22 for ; Mon, 1 Jan 2018 19:39:02 -0800 (PST) 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 8gD4Ix0ZPU2Y for ; Mon, 1 Jan 2018 19:39:00 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 916251200FC for ; Mon, 1 Jan 2018 19:39:00 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id d44so33176274otd.12 for ; Mon, 01 Jan 2018 19:39:00 -0800 (PST) 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=60aSrqu7mNAqBvnlxhEWSBZVS79alIOyUAKrlXKHtls=; b=t83v9JMuwXGfm3jbN9VeTqMGlRYMUNTQC2bCoQ06xAYa6TYMQEfhWc+FJ52BXWEJha nToVE4JTUaGn4Bi+Ajhl14Zk3i6FkUzFmqdP1uYpi2zmgMfKU4DhPQlPVdSLzVrXSZTo vgrmrC4G5K80lUfDvVRP5pV42uaDrdmNM7cSdwtO6zomQDFfMPlPWXSjvSFPs0Les0oM GJktx0i5la1coBiNmWBouwpGlue6gjfbtQExU7fUnplyA2nzVYx6t93LzEv9uLNM5h00 s4YDXPnM61dgr5Nn1wMc0gsh/Y1/E5ou95Ag64BpCJC5qtKtcYCjIYM6ajCLxp1DHTFK 79zQ== 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=60aSrqu7mNAqBvnlxhEWSBZVS79alIOyUAKrlXKHtls=; b=i7sytMKqUDNcDvdf0nLWf+bo246G1Z8Ehc5aSiKoYiCFXw+fGfH2z9RNIwDZyXUsV/ QVLG6997fANQMefaMgMop9Qm1FgVXp8Bw+ZH/d0GAKLsI7+EBme7Eysl6lpJ21Ts3/WW VZ9PtR9EC9vFqFi0taro3NToJaB/muriYfePMPpypvckBzIsG+eR0ReZB+FLecZUXXfw K5EufgxQDo8JGnj3zQ/XmJmPO7OXIVKeMdgNyAyKs+zMSrmTsYyypAOKNsm1V32FnSz6 +G+SsO3iULwcojNnjNiWdQtphqdULaiAtCzfBBxRJqWzQZnMWtFGPAJsbCQyWHMpeRe5 MBlA== X-Gm-Message-State: AKGB3mJpc1AbdKyO2LC7+D3703yW33sCjL+JB6DbniwMqa+cOJoX10o8 Znc9C8DM6iCuITSQqvcdlHsHWfPlBRORwZ/mJwqYbw== X-Google-Smtp-Source: ACJfBov6eoH8jKmgvZU3FdjzCacL5vO0gq+aQRdY00c4lc6hJtOCb9dOeSE1r2sYTZ9k7kEsjHCmU01ohz1Xi0GUELc= X-Received: by 10.157.74.52 with SMTP id h49mr34872893otf.308.1514864339856; Mon, 01 Jan 2018 19:38:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 19:38:59 -0800 (PST) In-Reply-To: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net> References: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 14:38:59 +1100 Message-ID: Subject: Re: Removing packet number gaps 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: Tue, 02 Jan 2018 03:39:02 -0000 On Tue, Jan 2, 2018 at 1:13 PM, Christian Huitema wrote: > For clarification: are you proposing to make the encryption key and IV dependent on the connection ID, or just the packet number mask? Both. As you argue in your draft, this makes some things easier, and it fits more naturally if the key, IV, and mask all have similar derivations. > Also, are you proposing applying the mask before encoding the packet header on 1, 2, 4 or 8 bytes, or after that? After. We'd have to be careful to get the bit alignment right, of course. From nobody Mon Jan 1 19:40:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96815126CB6 for ; Mon, 1 Jan 2018 19:40:00 -0800 (PST) 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 eHXyy2AzpRV8 for ; Mon, 1 Jan 2018 19:39:59 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 4B08B1200FC for ; Mon, 1 Jan 2018 19:39:59 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id w4so12397932otg.3 for ; Mon, 01 Jan 2018 19:39:59 -0800 (PST) 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=Q9lU2vOzAQ6zNdIo+1bFFKnxMbGRd7kQcDhSN3B8ix8=; b=RbDkyV5JKRAm1wnWcGO9D/Gg0WR9JREwwLUjA+S/CaB6+sb9c5nRcRL0FgvirmJRkQ J3iNc331p8A9zCyyX47ugluXQJQCF1WSHqA+RtYWIq/BTyRirv7LmLNzigipkturpUKg EMgP4ZuYtsmuxB+gF8Z3DnRey34ZR7R/Bw8EKUdfVwMHCrSb+2rhwcG4k/5pRmRydKEe rMMBW9E3m7V/+yxnVduWze5gFSxLX4s/M7iSkwQ/aMazZcDDD3RFHELC5cNjNeFohHnW VXnpH+HkFkDr8pRfIn1ZCG5ytrQ6/aW2SLcMml7tcUqLUNzxyM/ifrKTKewTFaf0747v l5mw== 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=Q9lU2vOzAQ6zNdIo+1bFFKnxMbGRd7kQcDhSN3B8ix8=; b=KcCgaicPuqcfw1EjcKv0olw1rYHtpb3zugugyJRuGJNYxF2HDBA1z7M1CDS4SptKBz E09+JJuZYUsFSaHWX5v+uGKbfX0L3srjMY5+5UU06nzbeqa0dv/mdiFyofDea+wSNhN+ ShEwpjLHfd7d9wccN1UUeIbUjIJWiW+SewIwVEDloUhi9KP1mnSSQohpb+IDi+ur1g9f 09B2/hi7iX6BpwfXBs6L55NfEOCryTMXEVMrgm1LV4gehTEpzJs3WKIzgXl+eHODF5TX bpIgX46hVkzcvLKNNxL1dkY/fvjzsdYVmdvUoaWe31Kt35x7W3w4aEw/Uzs6ZyipZhuH wqJw== X-Gm-Message-State: AKGB3mIMt4vGZomYTemt8Xn2huSfpw9synxXoHvjn2pmN+0iAZrFbPj0 eA68h1aLRb36fHxYGiYtINev799sTNtUO0nC/en4rQ== X-Google-Smtp-Source: ACJfBov9SOO8WlM2kinjqIaU83f3Adwy6TLuxxKYIOMxQE58oKKe//c+gonYjXDFUfmw7bgk894nEfyvVQJqWzr9XG4= X-Received: by 10.157.35.229 with SMTP id t92mr11995689otb.16.1514864398632; Mon, 01 Jan 2018 19:39:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 19:39:58 -0800 (PST) In-Reply-To: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com> References: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Tue, 2 Jan 2018 14:39:58 +1100 Message-ID: Subject: Re: Removing packet number gaps To: "Lubashev, Igor" Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 03:40:00 -0000 On Tue, Jan 2, 2018 at 1:15 PM, Lubashev, Igor wrote: > Could we use PLUS instead of XOR? My understanding is that there is little cryptographic difference between XOR and PLUS, and it is nicer to have consecutive packet numbers on the wire... It depends on what your goals are, but sure. XOR won't make it impossible to recover numbers, but it would make it annoying and that's petty. Addition modulo the field size works for me. From nobody Mon Jan 1 20:11:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39DC41252BA for ; Mon, 1 Jan 2018 20:11:20 -0800 (PST) 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 sLEnGUNR8QCm for ; Mon, 1 Jan 2018 20:11:18 -0800 (PST) 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 7885E12025C for ; Mon, 1 Jan 2018 20:11:18 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eWDv2-0003L0-Iz for quic@ietf.org; Tue, 02 Jan 2018 05:11:17 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eWDuv-0008EW-05 for quic@ietf.org; Mon, 01 Jan 2018 23:11:13 -0500 Received: (qmail 6428 invoked from network); 2 Jan 2018 04:11:08 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jan 2018 04:11:08 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Mon, 1 Jan 2018 20:11:04 -0800 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net> To: Martin Thomson Subject: Re: Removing packet number gaps X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5t2HaMQv4Z1IGdPClLcY6YwXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftl6fu0np4Sp4emvxygSNSgB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b t00GnuD9zr522QMYlXqmqn0HmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFDJc/3lHzX92E3nO7lXITicibYT4C2qF2lnc18bVJn64R i1TusSFblGB0ZjyNzARkkE+XOWfZ01+dGBM26lIvtTwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTwMPXVqLhHTCtUoQNwWJnsFjI1dRH6f16eQCtvwPkeoxEbFBkDEb7h/VcBU3NCXbKl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 04:11:20 -0000 =20 > On Jan 1, 2018, at 7:38 PM, Martin Thomson wrot= e: >=20 >> On Tue, Jan 2, 2018 at 1:13 PM, Christian Huitema w= rote: >> For clarification: are you proposing to make the encryption key and IV de= pendent on the connection ID, or just the packet number mask? >=20 > Both. As you argue in your draft, this makes some things easier, and > it fits more naturally if the key, IV, and mask all have similar > derivations. Yes, it seems natural. But there is at least one downside: both peers need t= he master secret available when creating or receiving a new connection ID. I= n the current design, the master secret can be erased once encryption keys h= ave been initialized. OTOH, with that design we can get rid of the key phase mechanism. To refresh= the key, just start using a new connection ID. >=20 >> Also, are you proposing applying the mask before encoding the packet head= er on 1, 2, 4 or 8 bytes, or after that? >=20 > After. We'd have to be careful to get the bit alignment right, of course.= You don't actually need to be careful with the XOR solution. Just XOR four b= ytes after completing the payload encryption, and XOR then again before decr= ypting the payload. By the way, can we get 5 bytes instead of just 4? With the 5th byte, we coul= d grease the lower bits of the first byte, greasing the packet type. -- Christian Huitema= From nobody Mon Jan 1 20:32:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40DD126C89 for ; Mon, 1 Jan 2018 20:32:16 -0800 (PST) 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 Wd7MMxAxNsX4 for ; Mon, 1 Jan 2018 20:32:15 -0800 (PST) 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 4B8BD12025C for ; Mon, 1 Jan 2018 20:32:15 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eWEFJ-0002oS-9g for quic@ietf.org; Tue, 02 Jan 2018 05:32:13 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eWEFG-0004jl-ED for quic@ietf.org; Mon, 01 Jan 2018 23:32:11 -0500 Received: (qmail 4790 invoked from network); 2 Jan 2018 04:32:09 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jan 2018 04:32:09 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Mon, 1 Jan 2018 20:32:07 -0800 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <5BC82026-2A30-4A31-87F1-6FBB694C9FAE@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> To: Martin Thomson Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sjEOoY7Jr9ODtX/46hJh38Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsLVxTk0IBx13yeFhiYOi5NB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUw8uEFOG92DI83j3LMNDNEdZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPzFy2BMVafZkKGCe45ASM DbvPZ2MU0aggZCbOzDKduscHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFirtlAtdsrBTAcAoY5WeLmsibYT4C2qF2lnc18bVJn65v jRxjDQ3TvE7lS2eoKehjsGSPZLRpX8VZnBFOnZ4xjTwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTvLpZVaBCgo9IFgw1OrNwYFjI1dRH6f16eQCtvwPkeoxzBkc1CTpvaEJjkrbHF6v+l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 04:32:17 -0000 =20 > On Jan 1, 2018, at 2:33 PM, Martin Thomson wrot= e: >=20 > ... >=20 > I don't think that the section on flow control makes any sense, since flow= control operates at your stream layer. Actually, flow control in TCP is used both as an application layer tool, e.g= . don't send faster than the printer can print, and as a transport level too= l to limit the speed at which the peer can send. If we just look at the appl= ication level, then of course this is purely a stream layer issue. But if we= consider the transport function, then it makes sense to tie it to a path.=20= >=20 > I'm going to have to think on it some more, but your suggestion in 4.7 mig= ht be a good idea. We don't have to do that now, though we might choose to d= o so if we can work through the design and implications. Either separate encryption keys for separate connection ID, or mix IV with c= onnection ID and sequence number for the nonce. The latter might work better= , because it does not require keeping the master secret around. But it leaks= one bit for correlation if the phase bit changes at the same time on all pa= ths after a key rotation. -- Christian Huitema=20= From nobody Mon Jan 1 20:40:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86560126C89 for ; Mon, 1 Jan 2018 20:40:34 -0800 (PST) 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 h6bZLBrWWG51 for ; Mon, 1 Jan 2018 20:40:33 -0800 (PST) Received: from mail-ot0-x243.google.com (mail-ot0-x243.google.com [IPv6:2607:f8b0:4003:c0f::243]) (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 E32AB12025C for ; Mon, 1 Jan 2018 20:40:32 -0800 (PST) Received: by mail-ot0-x243.google.com with SMTP id 14so14466144oth.9 for ; Mon, 01 Jan 2018 20:40:32 -0800 (PST) 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=4Df185gMIxUPkgDPUBz+VLxa2LYVgguHcj/7o0cvs6M=; b=fe6q3ZPYpmEo/UHPQZWBjouNrx8/Od1YodDswtXF+tBWQCRX3dXwJhO1VKmhGu2Han 6dfbrneNgUOp67JvEt/EimSt22Tw3CMs5ithd7tp5LLDUSTJx4/+CzYFFKM9eSjK9o3o Ei+OgzxF8mPnEjFhVOxSBQ4OoLgpN25f54YWHJFWXnrjdtcWXQj6G1J6vZzZMdI/WIvg WPC+qAQwV9+vKE2djKu5FByvgFSs5W3zxjeTgz/Zx1W4sPFXM4RCyc2KWYK6iqzasZTL CyX2K1D/qN5f3cn/N13ez7Tw/dHxkIks+yQ13Hl4GZkri/kaKC/2sQZgbLIJgoJzbcFO HJXw== 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=4Df185gMIxUPkgDPUBz+VLxa2LYVgguHcj/7o0cvs6M=; b=r0SVxcxZXWimHHrBUcMHyBy2XKkOoLhFGY7mKKQwcHN4jl7EXPzIhtLu74zTxJuMVv qyBpxYYBQVR0UArCMA579lUOJq9GqvNYJvZh38dAC79dzZ2ChAjsZ831dyR5qI5UObcX MvKZt+GAJngoFBaYLnIivOV+kGvyc/ZhLufC+LEuwkHTPKKKSh92AaDFZ2cXfnbhkXr0 Dpn8dNGf40B4yLkMdMSfOtIP/bYvQwwTD8NNqohMsw0fbnWr45024tpSMkXq0fIIddvl zX4rGy3PMh0eyuComzn4Km5XW+NzZwU/9flOGrp2WkDOo1KFSItVKH9QUOqqZM8f7XtC SgAQ== X-Gm-Message-State: AKGB3mLfYKTpd2KeBWp7Vk5DWITzjhilGKndivnneBlCG/SO/LQRByhr IsvFVZAnlGxNcXseWD4cYboAoZ/tAesVuIB9x/8= X-Google-Smtp-Source: ACJfBotnWbwUYqLg3Frn89T8yhdRlBDC0FWRBOWLx+rCQbR7awDAipakFho0azTB0XaAL0/Nbddua7d0SR4G5FYxiJA= X-Received: by 10.157.35.229 with SMTP id t92mr12043762otb.16.1514868032129; Mon, 01 Jan 2018 20:40:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 20:40:31 -0800 (PST) In-Reply-To: References: <16F84894-C3D9-4342-83EB-616759E739BD@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 15:40:31 +1100 Message-ID: Subject: Re: Removing packet number gaps 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: Tue, 02 Jan 2018 04:40:34 -0000 On Tue, Jan 2, 2018 at 3:11 PM, Christian Huitema wrote: >> On Jan 1, 2018, at 7:38 PM, Martin Thomson wrote: >> >>> On Tue, Jan 2, 2018 at 1:13 PM, Christian Huitema wrote: >>> For clarification: are you proposing to make the encryption key and IV dependent on the connection ID, or just the packet number mask? >> >> Both. As you argue in your draft, this makes some things easier, and >> it fits more naturally if the key, IV, and mask all have similar >> derivations. > > Yes, it seems natural. But there is at least one downside: both peers need the master secret available when creating or receiving a new connection ID. In the current design, the master secret can be erased once encryption keys have been initialized. You need the packet protection secret around if you ever want to do a key update. > OTOH, with that design we can get rid of the key phase mechanism. To refresh the key, just start using a new connection ID. True, but that would remove the post-compromise security that we get from the current design. >>> Also, are you proposing applying the mask before encoding the packet header on 1, 2, 4 or 8 bytes, or after that? >> >> After. We'd have to be careful to get the bit alignment right, of course. > > You don't actually need to be careful with the XOR solution. Just XOR four bytes after completing the payload encryption, and XOR then again before decrypting the payload. You have to get the right part of the 4 (or 5) bytes or it will fail. That means a htonl() call, but that's easy. Though I note that if we do as Igor suggests, then we get that number just once per connection ID (with a call to ntohl() at that point) and add before encoding and you don't have to worry about the truncation bit. > By the way, can we get 5 bytes instead of just 4? With the 5th byte, we could grease the lower bits of the first byte, greasing the packet type. Sure. I didn't want to burden everyone with this, but it's an obvious extension. From nobody Mon Jan 1 20:44:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F4A126C89 for ; Mon, 1 Jan 2018 20:44:27 -0800 (PST) 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 lrefnWznMOrA for ; Mon, 1 Jan 2018 20:44:26 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 D739612025C for ; Mon, 1 Jan 2018 20:44:25 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id w4so12461297otg.3 for ; Mon, 01 Jan 2018 20:44:25 -0800 (PST) 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=tA5GqrwTeXeUd6DqCFbT1J+YmJKMBmSJmue3CsdVXEk=; b=TI2Vy5Ol5QEoFh9gxz/BGsLKIPC2hrmEp/gjwDaALJMwIdiDSxYDUsHHY6Lwrhooiy lsbXhWxL8JVNakxY1AIiKJiXD+kZqJ2IPcQeBdJqF1p4T5M2TyX/z3PvteSSQMFFYmjB IyYv/CiqjlucenyDt4BCiabR6FhDetN0t/UE4AYNA+eIRf329bxKlFC3oChro/fh5yDh ZKFz6EAGuvaiBzDHxOUXGLKw0LjSA9eT9dSeinZUVMqPdjH/jux3Q7U4flBGGm8amuom ZessK6tZNUrcQ7VC090rVTPs7hTcvO7qQEmOPLQOGjhepUQPMood7RBAl4wGavcH7Kyq eeAQ== 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=tA5GqrwTeXeUd6DqCFbT1J+YmJKMBmSJmue3CsdVXEk=; b=tzDc0MO8N3JXw0zZn68GADYi+Qk5nDO2z0dHKbtnLZBRJazZsAky0B/ZQ9qOfJLwGn gRiKTlHJ8fA5EKG5kMJ+v+d60HnNfQKr9aMd6s2VTWfbAnY5oBhUDE19IqiJYbFXmdT5 yd1sBPT0n38D0En7N5zgITb91x0R+se3puKTeTirrjBUTTWxQwn2aWVBe0PKSUcCTYJ8 ue3mPYXrTKn/P36EVPcqICGUVGBmAV9lcWv9uBXbWAbnOjw8/dBfIvTvzfEr9U66qP4g /Sz+XCcyOtNLRlImwpv1WUGR+DM0QMWBSqmw3qojfRTtymREzltTWZh4eWycvpPUjXid cU/g== X-Gm-Message-State: AKGB3mJz8AnNvPVLoajThgO65o1KUWdH/Lu9cPU+r0lS78iLerWadG3z gfy8FYH7MF2u3dsmP/CYHGp5taFsF9YjdNehd8k= X-Google-Smtp-Source: ACJfBosElcFJYl9nzJA1oQy4ba0urfQLOxExSFg8puJdpscI3xWTNfTd1gq7fFERdlSqVJ4XVs5jWVHui7t3snCk970= X-Received: by 10.157.69.13 with SMTP id w13mr31008283ote.93.1514868265197; Mon, 01 Jan 2018 20:44:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 20:44:24 -0800 (PST) In-Reply-To: <5BC82026-2A30-4A31-87F1-6FBB694C9FAE@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> <5BC82026-2A30-4A31-87F1-6FBB694C9FAE@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 15:44:24 +1100 Message-ID: Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 04:44:27 -0000 With the notice here that we're probably getting ahead of things a little..= . On Tue, Jan 2, 2018 at 3:32 PM, Christian Huitema wro= te: > Actually, flow control in TCP is used both as an application layer tool, = e.g. don't send faster than the printer can print, and as a transport level= tool to limit the speed at which the peer can send. If we just look at the= application level, then of course this is purely a stream layer issue. But= if we consider the transport function, then it makes sense to tie it to a = path. I'm not sure that I see the logical connection here. If the intent is to govern send rate on a given path, then we probably want a different mechanism, but it's not really flow control any more. I think that our TCP heritage might be more of a liability in this case and we should be clear what properties we're seeking - plus some new names for these functions. >> I'm going to have to think on it some more, but your suggestion in 4.7 m= ight be a good idea. We don't have to do that now, though we might choose = to do so if we can work through the design and implications. > > Either separate encryption keys for separate connection ID, or mix IV wit= h connection ID and sequence number for the nonce. The latter might work be= tter, because it does not require keeping the master secret around. But it = leaks one bit for correlation if the phase bit changes at the same time on = all paths after a key rotation. A simpler design has a key rotation for every connection ID change and no key phase bit. There are a few downsides of course, but those can be managed. From nobody Mon Jan 1 20:57:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D32841205D3 for ; Mon, 1 Jan 2018 20:57:07 -0800 (PST) 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 A-ZG6C06mvoO for ; Mon, 1 Jan 2018 20:57:06 -0800 (PST) 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 E521912025C for ; Mon, 1 Jan 2018 20:57:05 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eWEdK-0002Pm-95 for quic@ietf.org; Tue, 02 Jan 2018 05:57:03 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eWEdF-00076f-I7 for quic@ietf.org; Mon, 01 Jan 2018 23:57:01 -0500 Received: (qmail 9174 invoked from network); 2 Jan 2018 04:56:56 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.40]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Jan 2018 04:56:56 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Mon, 1 Jan 2018 20:56:54 -0800 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7F550E54-3899-484F-8478-ED99DF81700F@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> <5BC82026-2A30-4A31-87F1-6FBB694C9FAE@huitema.net> To: Martin Thomson Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5j7LQZ4hpjmYRQimH7Fen9AXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftJcOG9tU10QZjh1NnJPeJ9B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIKcwsOsYjBjCZN249H7KzSqpR+WsWEoFdiO1WLSqm BLjP/AMVb6/YbYeoS4ph6P3GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA1kWiicstEyxcSXS3gzmQ6EONoJfh+XjGSeeT90H/uIET XgycjncURQxgzXxu7/P7fNiHhQn9lhVQeKzH/YK4nGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW7i647gVHMYTji4wyoFXFDffFcHV2tQAVqGdj/zM7G/F/kBR/WQICwWa5uPAEZIkV5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 04:57:08 -0000 > On Jan 1, 2018, at 8:44 PM, Martin Thomson wrot= e: >=20 > With the notice here that we're probably getting ahead of things a little.= .. >=20 >> On Tue, Jan 2, 2018 at 3:32 PM, Christian Huitema w= rote: >> Actually, flow control in TCP is used both as an application layer tool, e= .g. don't send faster than the printer can print, and as a transport level t= ool to limit the speed at which the peer can send. If we just look at the ap= plication level, then of course this is purely a stream layer issue. But if w= e consider the transport function, then it makes sense to tie it to a path. >=20 > I'm not sure that I see the logical connection here. If the intent is > to govern send rate on a given path, then we probably want a different > mechanism, but it's not really flow control any more. I think that > our TCP heritage might be more of a liability in this case and we > should be clear what properties we're seeking - plus some new names > for these functions. Yes. Probably something to develop a bit in the next iteration of my draft. >=20 >>> I'm going to have to think on it some more, but your suggestion in 4.7 m= ight be a good idea. We don't have to do that now, though we might choose t= o do so if we can work through the design and implications. >>=20 >> Either separate encryption keys for separate connection ID, or mix IV wit= h connection ID and sequence number for the nonce. The latter might work bet= ter, because it does not require keeping the master secret around. But it le= aks one bit for correlation if the phase bit changes at the same time on all= paths after a key rotation. >=20 > A simpler design has a key rotation for every connection ID change and > no key phase bit. There are a few downsides of course, but those can > be managed. One downside is that rotations have to be performed in order, probably using= a connection ID sequence like the current packet gap spec. Hashing the conn= ection ID in the key gets rid of that, and that's nice. Plus it allows start= ing using several connection ID in parallel, which is needed for multi path.= But yes, we are getting a bit ahead, and I expect the chairs to try rein in t= hat discussion at any moment now. -- Christian Huitema=20= From nobody Mon Jan 1 21:17:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4744112421A for ; Mon, 1 Jan 2018 21:17:33 -0800 (PST) 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 9RiYPUeJnbMc for ; Mon, 1 Jan 2018 21:17:31 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 AA67D12025C for ; Mon, 1 Jan 2018 21:17:31 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id w131so32720930oiw.0 for ; Mon, 01 Jan 2018 21:17:31 -0800 (PST) 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=ROiC06BTubBc3JMtVGXPcrRZsJOttf+vC9p2n1E0g2U=; b=f2eRYAumqetN58VeFSlkrjRQ1dVung5mSH3S0lJJdVJe9fI9H70aDwfjs5+pMwkJAK nHoIMx9TYxDhvQ6o9yQYqiURNpBgp/+wxWBoOvRU3G3IubMi3A8jmF7TP20TQswhkuP5 jGrqtenCEuzeKdpQDKcE40qRVsyJt4+lgQqETjHUVwNpZ3Sh4NhhPQbjSnqsaxxXqCN5 lqiHQqqRPGTC9CCqz2TrWhLDJqqT7hqc6X1e8lsLgFzk51+6NCYxXRUYqjSfqhcIXlZS yuFBzOn3nzfkJ5AvXQT3TRh4OwmyoiFg4TUGUSHT+FTrJa5ylSC4o78TPCG/QSUoPkWV vTnQ== 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=ROiC06BTubBc3JMtVGXPcrRZsJOttf+vC9p2n1E0g2U=; b=i/4ucygNNEKrzRUtHgsRXzMpaqGjm1h8ZnJK1Fv4Q0hUDhy62cIBT0pi5JR0MsfT3c t7yqjWS/h6JQpRtYG114ciGQF2gYUWVQs4vfhIO8a2d449IsQ9d4q2izdHymm64wvYEG MDbWL5BcKrX7RqwBf+AkoCdDpidX3amArZ+pi8TAv8iQ26vrgkMhTb/hjXJu5iP6stYF EfzPmmPJHsuYNh4jW+FQsontKWmkeMSVuVlVNTaNfAmiT7LE6WM+qgbhgKAt089qdOmd wdRjGcTldJiUrEwY3DYKcYMbYwuxnl728IVXK2Y4k8HtItJiFZKAol5GQnf/JqPWH6r5 qquA== X-Gm-Message-State: AKGB3mJ2azNjdrjjTcGGDsfgVmNUnw2v6lshfmqnyv+QlsX1HeQH5lq4 SLBp2BSMX3gM8sQ2rxxgBUYPuyZ5bGiuHNbHnBI= X-Google-Smtp-Source: ACJfBos9puw8uckTcR2MxG/gtvsYpsA2bT1ljyFdAghTqO78qoST9/8QDsQWygYmNY1rL0c6LicbedDp4Ao7+Ro0eGo= X-Received: by 10.202.166.206 with SMTP id t75mr32231600oij.28.1514870250959; Mon, 01 Jan 2018 21:17:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Mon, 1 Jan 2018 21:17:30 -0800 (PST) In-Reply-To: <7F550E54-3899-484F-8478-ED99DF81700F@huitema.net> References: <151440883747.29897.3176327891691875461.idtracker@ietfa.amsl.com> <1728cfeb-e2ce-61cd-9a4e-770d76816fff@huitema.net> <5BC82026-2A30-4A31-87F1-6FBB694C9FAE@huitema.net> <7F550E54-3899-484F-8478-ED99DF81700F@huitema.net> From: Martin Thomson Date: Tue, 2 Jan 2018 16:17:30 +1100 Message-ID: Subject: Re: New Version Notification for draft-huitema-quic-mpath-req-00.txt To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 05:17:33 -0000 On Tue, Jan 2, 2018 at 3:56 PM, Christian Huitema wro= te: > One downside is that rotations have to be performed in order, probably us= ing a connection ID sequence like the current packet gap spec. Hashing the = connection ID in the key gets rid of that, and that's nice. Plus it allows = starting using several connection ID in parallel, which is needed for multi= path. In order rotations might still be valuable to allow for some predictability. I think that I'd still want to retain the ordering, if only to retain the post-compromise security. Parallel flows can still work with that. > But yes, we are getting a bit ahead, and I expect the chairs to try rein = in that discussion at any moment now. Well, they are probably still on a break, as I realize that I should also b= e. From nobody Mon Jan 1 22:12:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1735F12421A for ; Mon, 1 Jan 2018 22:12:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-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 UkGijAfmb16t for ; Mon, 1 Jan 2018 22:12:25 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 44887120227 for ; Mon, 1 Jan 2018 22:12:25 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4C57F39096B3F for ; Tue, 2 Jan 2018 06:12:22 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 2 Jan 2018 06:12:22 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Tue, 2 Jan 2018 14:12:18 +0800 From: "Roni Even (A)" To: "Lubashev, Igor" , Martin Thomson , QUIC WG Subject: RE: Removing packet number gaps Thread-Topic: Removing packet number gaps Thread-Index: AQHTg20Lw9Ok9TbA2kavZCGkcbFIbKNfUh8AgADIO0A= Date: Tue, 2 Jan 2018 06:12:17 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD85C616@DGGEMM506-MBX.china.huawei.com> References: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.69] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Jan 2018 06:12:27 -0000 KzENClJvbmkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWJhc2hldiwgSWdvcg0KU2Vu dDogVHVlc2RheSwgSmFudWFyeSAwMiwgMjAxOCA0OjE1IEFNDQpUbzogTWFydGluIFRob21zb247 IFFVSUMgV0cNClN1YmplY3Q6IFJFOiBSZW1vdmluZyBwYWNrZXQgbnVtYmVyIGdhcHMNCg0KQ291 bGQgd2UgdXNlIFBMVVMgaW5zdGVhZCBvZiBYT1I/ICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg dGhlcmUgaXMgbGl0dGxlIGNyeXB0b2dyYXBoaWMgZGlmZmVyZW5jZSBiZXR3ZWVuIFhPUiBhbmQg UExVUywgYW5kIGl0IGlzIG5pY2VyIHRvIGhhdmUgY29uc2VjdXRpdmUgcGFja2V0IG51bWJlcnMg b24gdGhlIHdpcmUuLi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRp biBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IE1vbmRh eSwgSmFudWFyeSAwMSwgMjAxOCA4OjU3IFBNDQpUbzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlbW92aW5nIHBhY2tldCBudW1iZXIgZ2Fwcw0KDQpUaGVyZSBhcmUgbnVtYmVy IG9mIHByb2JsZW1zIHdpdGggcGFja2V0IG51bWJlciBnYXBzIHRoYXQgSSB0aGluayB3ZSBuZWVk IHRvIGFkZHJlc3MuICBNb3N0IGFyZSBtaW5vci4gIEZvciBpbnN0YW5jZSwgdGhlIGluaXRpYWwg cGFja2V0IG51bWJlciBpcyBub3QgY2xvc2UgdG8gemVybywgd2hpY2ggaW5mbGF0ZXMgdGhlIHNp emUgb2YgQUNLIGZyYW1lcyBmcm9tIHRoZSB2ZXJ5IGJlZ2lubmluZyBvZiBhIGNvbm5lY3Rpb24u DQoNCkhvd2V2ZXIsIENocmlzdGlhbiBqdXN0IGlkZW50aWZpZWQgb25lIHRoYXQgSSB0aGluayBt YWtlcyB0aGlzIG1vcmUgaW1wb3J0YW50IHRvIGFkZHJlc3M6IHdoZW4gdXNpbmcgYSBuZXcgY29u bmVjdGlvbiBJRCwgdGhlIGdhcCBpcyB0aGUgc2FtZSBzaXplIG9uIGJvdGggY2xpZW50IGFuZCBz ZXJ2ZXIuICBUaGlzIG1ha2VzIGZsb3dzIGxpbmthYmxlLiAgVGhlIGdhcHMgYmV0d2VlbiB0aGUg bGFzdCBwYWNrZXQgb24gdGhlIG9sZCBmbG93IGFuZCB0aGUgZmlyc3QgcGFja2V0IG9uIHRoZSBu ZXcgZmxvdyBjYW4gYmUgY2FsY3VsYXRlZCBpbiBib3RoIGRpcmVjdGlvbnMuICBGbG93cyBjYW4g YmUgbGlua2VkIGJ5IGZpbmRpbmcgZmxvd3Mgd2hlcmUgY2xpZW50LXRvLXNlcnZlciBwYWNrZXRz IGhhdmUgdGhlIHNhbWUgKG9yIHZlcnkgY2xvc2UpIGdhcHMgYXMgc2VydmVyLXRvLWNsaWVudCBw YWNrZXRzLg0KDQpXaXRoIGEgZmV3IHNtYWxsIHR3ZWFrcyB0byB0aGUgY3VycmVudCBkZXNpZ24s IEkgdGhpbmsgdGhhdCB3ZSBnZXQgYSBtdWNoIGJldHRlciBzb2x1dGlvbi4gIEhlcmUgaXMgd2hh dCBJIHByb3Bvc2U6DQoNCkZpcnN0bHksIHBhY2tldCBudW1iZXJzIHN0YXJ0IGF0IHplcm8gYW5k IGFsd2F5cyBpbmNyZWFzZSBtb25vdG9uaWNhbGx5LCB3aXRoIG5vIGdhcHMuICBBIHNpZGUgYmVu ZWZpdCBvZiB0aGlzIGlzIHRoYXQgdGhlIGZpcnN0IEFDSyBmcmFtZSB3aWxsIGhhdmUgYSBzbWFs bCBlbmNvZGluZyBmb3IgbGFyZ2VzdF9hY2tub3dsZWRnZWQgKDEgb2N0ZXQgcmF0aGVyIHRoYW4g OCBpbiBtb3N0IGNhc2VzKS4NCg0KUGFja2V0IG51bWJlcnMgYXJlIG5ldmVyIGVuY29kZWQgZGly ZWN0bHkgb250byB0aGUgd2lyZSwgdGhleSBhcmUgWE9SZWQgd2l0aCBhIG1hc2tpbmcgdmFsdWUu ICBUaGlzIHZhbHVlIHdpbGwgY2hhbmdlIGZvciBkaWZmZXJlbnQgcGFja2V0IHByb3RlY3Rpb24g a2V5cywgYW5kIGZvciBkaWZmZXJlbnQgY29ubmVjdGlvbiBJRHMuICBDbGllbnQgYW5kIHNlcnZl ciB3aWxsIHVzZSBkaWZmZXJlbnQgdmFsdWVzIHNvIHRoYXQgZ2FwcyBhcmUgaGFyZCB0byBkZXRl Y3QuDQoNClRodXMsIHdlIHdpbGwgaGF2ZSBhIHRoaXJkIGtleSBkZXJpdmF0aW9uOg0KDQogICBr ZXkgPSBRSEtERi1FeHBhbmQoUywgImtleSIsIGtleV9sZW5ndGgpDQogICBpdiAgPSBRSEtERi1F eHBhbmQoUywgIml2IiwgaXZfbGVuZ3RoKQ0KICAgcG5tYXNrID0gUUhLREYtRXhwYW5kKFMsICJw bm1hc2siLCA0KQ0KDQpUbyBtYWtlIHRoaXMgd29yayBzZWFtbGVzc2x5LCBJJ20gcHJvcG9zaW5n IGEgdHdlYWsgdG8gUUhLREYtRXhwYW5kIHRoYXQgaW5jbHVkZXMgdGhlIGNvbm5lY3Rpb24gSUQu ICBGb3IgdGhhdCwgdGhlICJDb250ZXh0IiBmaWVsZCB0aGF0IHdlIGN1cnJlbnRseSBkbyBub3Qg dXNlIHNlZW1zIGxpa2UgYSBnb29kIGNob2ljZS4NCg0KVGhpcyB3aWxsIG1lYW4gY2hhbmdlcyB0 byB0aGUgb3RoZXIgdXNlcyBvZiBRSEtERi1FeHBhbmQ6DQoNCiogdGhlIGhhbmRzaGFrZSBzZWNy ZXQgY2FuIGJlIGNoYW5nZWQgdG8gYmUgYSBmaXhlZCByYXRoZXIgdGhhbiBhIGRlcml2ZWQgdmFs dWUsIHNvIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byB1c2UgdGhlIGZ1bmN0aW9uIChjb25uZWN0aW9u IElEIHdpbGwgYmUgYWRkZWQgZHVyaW5nIGV4cGFuc2lvbiBpbnRvIHRoZSBzZXBhcmF0ZSBrZXlz KQ0KDQoqIGR1cmluZyBhIGtleSB1cGRhdGUsIGEgemVyby1sZW5ndGggb3IgZml4ZWQgY29ubmVj dGlvbiBJRCB3aWxsIG5lZWQgdG8gYmUgdXNlZCBzbyB0aGF0IHRoZXJlIGlzIG5vIGNvbmZ1c2lv biBhYm91dCB3aGljaCBjb25uZWN0aW9uIElEIHdhcyBpbiB1c2UgYXQgdGhlIHRpbWUgdGhlIHVw ZGF0ZSB3YXMgbWFkZSAoZWRpdG9yaWFsbHksIEknbSBub3QgY2VydGFpbiBob3cgdG8gbWFuYWdl IHRoaXMgb25lLCBJIG1pZ2h0IGp1c3QgZ28gYmFjayB0byB1c2luZyBIS0RGLUV4cGFuZC1MYWJl bCBkaXJlY3RseSBmb3IgdGhhdCkNCg0KRmluYWxseSwgd2UgbmVlZCB0byBiZSB2ZXJ5IGNsZWFy IHRoYXQgZXZlbiBpZiB0aGUgY29ubmVjdGlvbiBJRCBpcyBvbWl0dGVkLCB0aG9zZSBwYWNrZXRz IHN0aWxsIHVzZSB0aGUgaW1wbGllZCBjb25uZWN0aW9uIElEIGluIGtleSBkZXJpdmF0aW9uLiAg V2Ugd2lsbCBwcm9iYWJseSB3YW50IHRvIHJlY29tbWVuZCB0aGF0IGVuZHBvaW50cyBpbmNsdWRl IGEgY29ubmVjdGlvbiBJRCBpZiB0aGV5IGludGVuZCB0byBzdXBwb3J0IE5FV19DT05ORUNUSU9O X0lEIG9yIGFueSBvZiB0aGUgcmVsYXRlZCBmdW5jdGlvbnMsIGF0IGxlYXN0IGFyb3VuZCB0aGUg dGltZSB3aGVuIGEgY29ubmVjdGlvbiBJRCBjaGFuZ2UgaXMgaW4gcGxhY2Ugb3IgdGhlIHJlY2lw aWVudCBvZiB0aGVpciBwYWNrZXRzIGNvdWxkIGhhdmUgZGlmZmljdWx0eSBwaWNraW5nIHRoZSBy aWdodCBrZXlzLiAgVGhpcyBpcyBhbHJlYWR5IGEgcHJvYmxlbSBvZiBjb3Vyc2UsIGJ1dCB0aGlz IGNoYW5nZSB3b3VsZCBtYWtlIGl0IHdvcnNlLg0KDQo= From nobody Tue Jan 2 06:43:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E1912773A for ; Tue, 2 Jan 2018 06:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 qEGYAH_zUfD5 for ; Tue, 2 Jan 2018 06:43:54 -0800 (PST) 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 23334127735 for ; Tue, 2 Jan 2018 06:43:54 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id v188so34183331qkh.11 for ; Tue, 02 Jan 2018 06:43:54 -0800 (PST) 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=aFwSkR/QQaEJDMfAjmZ2VO3h4sbdiqwPWwuz1eLmSsg=; b=btirxH7F0hqw/JkeXcySeWn3ay4ULIlisa/JnH/DrUk1XB4XzoU47O9zArq+nNz6YZ wfknj1jueVXgBpmm9BIhLUzaYgsv1f3Em3s/PbyFO0bM+BsynQ9MX/iai3rfxEGuiPGV eCPBtztM+PU1bCmtHhmvc4ttYC69ydXRGLuWlfyx31/uN6fyyAI43Hs2rwDr0tnjLhv2 t+aIJRuNJAyfKIjJhmihYzyFd8bVolxVszOtTQ9rtR9Qrc/YD0+iBRIyADDcJa+6lBE1 40lYP9Ys+6AJ7wbQCevucp90D4iPDe96+xycowAnVFDNdTNn21wkTp+hl8YzsXMRO+Ir vedA== 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=aFwSkR/QQaEJDMfAjmZ2VO3h4sbdiqwPWwuz1eLmSsg=; b=gL3b1bLBRwrocahsuhjqQlPz5yDwPku1wUDl93H46IsmrqlM5fmH1is3jv//Rr1cGX +0VeaW+VWoL+p1NDhzNQJe2Ie06UbWzw0x1HmOvoLe5/NAFb0uSDszjTpKX6DfSPIQN4 RHFoBiThrelEkzhEciwVYKBgwIyU/feBU5xPeqbVzITij5q1V0HlUrbteIKRXJrQpWMg aPOA3gkyIJVJZw4YazxlZ8SManCVhGiUzOy9nCDxzjthfS4iAI1VQp42OlxtFzjYqJMd 6GKfPbxV98hQkd2OzvVsUvLwk6jVXO7VRE7V3aGRHQqNcTTvLSpNHU7aFp5oy16+FBxH z1bA== X-Gm-Message-State: AKGB3mKyRTaQdzbrXRpexbQAXX09COswkElyIe3F2JZgEkeob8Iw9BYC irpsKuMWnXGQg2GdBIxqA/nuJZU4jXo8eEJZjgr7Ug== X-Google-Smtp-Source: ACJfBot+SwnazM041cvnzRuWDECUDttn1nZqeusToIpgOLVGXXw3GKVJ+8GZuBlz/XiOm/+sVEgDtC+izzdCbaNwiOM= X-Received: by 10.55.159.6 with SMTP id i6mr18234029qke.315.1514904232998; Tue, 02 Jan 2018 06:43:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.233.237.211 with HTTP; Tue, 2 Jan 2018 06:43:52 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 2 Jan 2018 09:43:52 -0500 Message-ID: Subject: Re: Removing packet number gaps To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05d984adc5990561cc20a2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Jan 2018 14:43:56 -0000 --94eb2c05d984adc5990561cc20a2 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 1, 2018 at 8:57 PM, Martin Thomson wrote: > However, Christian just identified one that I think makes this more > important to address: when using a new connection ID, the gap is the > same size on both client and server. This makes flows linkable. The > gaps between the last packet on the old flow and the first packet on > the new flow can be calculated in both directions. Flows can be > linked by finding flows where client-to-server packets have the same > (or very close) gaps as server-to-client packets. > Why not just have different gaps for the client and the server? --94eb2c05d984adc5990561cc20a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Jan 1, 2018 at 8:57 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
However, Christia= n just identified one that I think makes this more
important to address: when using a new connection ID, the gap is the
same size on both client and server.=C2=A0 This makes flows linkable.=C2=A0= The
gaps between the last packet on the old flow and the first packet on
the new flow can be calculated in both directions.=C2=A0 Flows can be
linked by finding flows where client-to-server packets have the same
(or very close) gaps as server-to-client packets.

=
Why not just have different gaps for the client and the server?= =C2=A0
--94eb2c05d984adc5990561cc20a2-- From nobody Tue Jan 2 15:03:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEB912D811 for ; Tue, 2 Jan 2018 15:03:18 -0800 (PST) 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 nG0oxeIm91Gv for ; Tue, 2 Jan 2018 15:03:17 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42E671200C1 for ; Tue, 2 Jan 2018 15:03:17 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id f69so34200743oig.10 for ; Tue, 02 Jan 2018 15:03:17 -0800 (PST) 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=NH6j4jAu312zqXoHXlQxtMZ1NsDj9qENW9b7Rf5Z3vE=; b=KubOxD0sJwdFk+wCgg6i6kgDxRfpxfZWNLIHzuikBHi++UQgaXDXwvCp3BUKurK4rx ajG11iEnuXbM9WX1oLLMYptLl8TdwCjADp+8ibJfhN/vS3VWXcLPkOaMAZOm0LKoaMbo SZQ05hH79E36Fs6zlEXXke3IIEaL64Gt+W0GJRS3IfK6RgEIUOWdOeZk0dBcfGAWEpma 1Nqn8QDHQKURyzO/p68b6H4YmN8lZacGb5CEK7SMYA2mqHvd/J4fvJ/Bc5LN3OUAe+F0 c3iQScszL7NA9GmsRy3OEI/8/UQOmZXGvQRyE6y2eUe6Qf89TV2FgSqWE/jHyoj66m5a fdoQ== 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=NH6j4jAu312zqXoHXlQxtMZ1NsDj9qENW9b7Rf5Z3vE=; b=pUQTvHQqiBSLSpiRuDcDRtyPrAG0G5JZ0QiXEKsRwckki85acFxyFfYCtzu8JA5T/9 X/1Q3kwyWs5egyGC14syio4PIUAAZEVTFdf0IQ3yR6OtgBswimcKrsjVy+kaMhtYDaNr SQhI4SMF5EeS/BtcE+6Nfi2xNCEsVgbVxPmmm7ta/f7tSLpqsTy4wrZIq6UgBKGOEHRy rMM65y5Nruo/EfdB34GMmgJ7EOBmOTHRQnRTr5KPTVhkquhU39qVDm/qwhXhVrbESlUt FY0QXFDlMFsVTi36REDauYzzFzkT67SRoJiswQN4hScbcI34Nz98plM7WeMHfwzUPr0H DgRw== X-Gm-Message-State: AKGB3mKJbLkfYNI9OMIio85dH04aolySPl4W79X7hE4LADhwbOpp3cGT 8CWW4Bum5jY1tsPDzSREx2svjvcpK2/c4GixJvE= X-Google-Smtp-Source: ACJfBot0Cv8/fua33XBvi7GJ6HzqMaAjspj9r98X+NhLpgssmpHUBQa74SfyYH8drprR2WFIurLzaI6vAugUerwKYEA= X-Received: by 10.202.48.8 with SMTP id w8mr31440490oiw.284.1514934196485; Tue, 02 Jan 2018 15:03:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.46.182 with HTTP; Tue, 2 Jan 2018 15:03:15 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 3 Jan 2018 10:03:15 +1100 Message-ID: Subject: Re: Removing packet number gaps To: Victor Vasiliev Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jan 2018 23:03:19 -0000 On Wed, Jan 3, 2018 at 1:43 AM, Victor Vasiliev wrote: > Why not just have different gaps for the client and the server? That fixes only that issue, and there have been several other issues identified. They are each on their own relatively minor, but together I'd say that a more principled change is justified. From nobody Wed Jan 3 02:37:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065BE12D864 for ; Wed, 3 Jan 2018 02:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-M5QkLlixgP for ; Wed, 3 Jan 2018 02:37:21 -0800 (PST) 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 084B2126579 for ; Wed, 3 Jan 2018 02:37:20 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-a5-5a4cb25e43b8 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3A.D2.13339.E52BC4A5; Wed, 3 Jan 2018 11:37:18 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 3 Jan 2018 11:37:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q2V7Wn4fPv1e7LIPgZqV7TqIY4rphAoCUj2mhInuMOQ=; b=koJWXfv3IxEMLIMJbD1tZhWyQ0HjqOoUtLQ2ul0JwBygB5hmBFz5eAtjNbQH49CJp0sYVTLNP4ruoAjW7JFL+HwdWaD7iP9BA6O306DBZKrG5kVcwqV0wKVDidWtZls5Ws6WoO3jv2Q3oa1yHh//y/Ke6T24I9y2996ziGRDjj8= Received: from HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) by HE1PR07MB0874.eurprd07.prod.outlook.com (10.162.24.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.4; Wed, 3 Jan 2018 10:37:15 +0000 Received: from HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::3869:27c2:9170:a94]) by HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::3869:27c2:9170:a94%13]) with mapi id 15.20.0386.005; Wed, 3 Jan 2018 10:37:15 +0000 From: Marcus Ihlar To: "roni.even@huawei.com" , "ilubashe@akamai.com" , "martin.thomson@gmail.com" , "quic@ietf.org" Subject: RE: Removing packet number gaps Thread-Topic: Removing packet number gaps Thread-Index: AQHTg20JC35thA3ROUS25Zv3cFsDDaNf2DsAgABCMoCAAduUQA== Date: Wed, 3 Jan 2018 10:37:15 +0000 Message-ID: References: <78d51955754d41f081561ffca6f23dee@usma1ex-dag1mb5.msg.corp.akamai.com> <6E58094ECC8D8344914996DAD28F1CCD85C616@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD85C616@DGGEMM506-MBX.china.huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.95] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB0874; 7:DFRt2SgKDtNv3prMzd0zERLWQWpH5TLQHMz6U9KkPfgPdUzUSVACOevUa4yYZOARvWvTolEU1hbKbkAuaU/5ZFrjVTivZ/NoGRXWYXM+6WswQpLzD0AwxggWfbkzU+8RhOKv4Vqwth8/azgLG1dVklYAypuf+KNIIa3zZZGEawbwxKa6v2DrMmQCg4pYfFhPnkWNO0weVKTXfTjUa18EFQYRAngPo7u/mNsViLZTKPs91m0l1mYzBLlKKFT1s8AR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3dac8737-0579-4561-b9b4-08d55295f513 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(5600026)(4604075)(3008032)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(2017052603307)(7153060); SRVR:HE1PR07MB0874; x-ms-traffictypediagnostic: HE1PR07MB0874: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(944501075)(6041268)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR07MB0874; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:HE1PR07MB0874; x-forefront-prvs: 0541031FF6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(376002)(366004)(346002)(13464003)(51444003)(199004)(189003)(14454004)(6116002)(3660700001)(229853002)(3280700002)(106356001)(6246003)(478600001)(81156014)(105586002)(3480700004)(3846002)(110136005)(97736004)(39060400002)(8936002)(81166006)(25786009)(8676002)(316002)(74316002)(305945005)(5660300001)(55016002)(7736002)(68736007)(2201001)(102836004)(5250100002)(9686003)(6436002)(33656002)(2906002)(66066001)(7696005)(86362001)(59450400001)(99286004)(53546011)(2501003)(6506007)(76176011)(53936002)(2950100002)(2900100001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0874; H:HE1PR07MB3242.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:3; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; x-microsoft-antispam-message-info: 0yQyjKFm+os+Txlwtv2wyNnz+KtmRA8KBNsDuHEhOev6T6dJJnKFgBw6jHmhDCmv6DyPw7C79Scj/b4+WuE2IQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3dac8737-0579-4561-b9b4-08d55295f513 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2018 10:37:15.7796 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0874 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfyyUcRzH+97znHtcXX1dzGekuNXCciqtaamlGldpqVWzm+HkCTnH7pFF E4XhaCMy5xanGdGwxMJslW5MU6YaC+d35mcrs/yKusdzbf33/rxf732+n89nX4oQF/HtqEhV HK1WKZQSCyGpDXh11C2o3k9+8EnHHs8HKc8Iz96uDeSZo9/qudDeTZ4iZfkGPSFrLjYKZGmG eb6svHyF50/KhV5htDIynla7nwwRRmStPiJji5zvvNekEimoYL8GWVKAj8DyolagQUJKjN8h 0E01klzRgeD+UMkmIfFDAjoye/gcKeDBqr6a4IoRBD8XfxNsMwsshS5jtgULrHELgrH6/k2w EzvD/NenSIMoE3CBF+vnWdsan4bM/PzNCIn3QnqLgWAjIhwIfQv2rC3G4wgGX4aw2hJfhdqy KQGrEXaA4aUhktUEtoX+iVIetw+G8tZugtM2MD2+wee0I2S9mTNnHOBTaTZixwTcwIPq2WUz kEJj3jzi9EUoq/hGcqHXCFYW58xdXUFrbBewgwKOgsdDjpx9HKpmfvC5/HMCMtZaBRzYBRlf isyvTfJhVKPnc6vRUFmTjnKRtPi/LYpNfQnTjepa3DnbCQqyRwWsFmEr6NROkHpEViMbhmZC o8MPe0hpdeQNholRSVV0XD0y/Ze3DWv7mtDnOe82hCkk2SY6UeEnF/MV8UxCdBsCipBYi3xu mSxRmCIhkVbHBKtvK2mmDdlTpMRW1HlOJBfjcEUcHUXTsbT6H+VRlnYpKCTEKfJDzc3BXjen yvAdac108pm+3oyzzHp7UO2k+x+jWDcwm1PnnXjhSuF133tdB6aTZN+9tSMGD8X20LSl1t3J /XaLPoG5w0ELHkleH8ergnU9TYWhStsIqVW8y/yWy9dmLhnq8pDvrxHJWMlMlWogv1BXZncs 1faukcfzbwyQkEyE4pAroWYUfwHaHmw7KwMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Jan 2018 10:37:23 -0000 KzENCkNvbnNlY3V0aXZlIHBhY2tldCBudW1iZXJzIGFyZSBpbXBvcnRhbnQgZm9yIHNwaW4gYml0 IG9ic2VydmVycy4NCg0KL01hcmN1cw0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb25pIEV2 ZW4gKEEpDQpTZW50OiBkZW4gMiBqYW51YXJpIDIwMTggMDc6MTINClRvOiBMdWJhc2hldiwgSWdv ciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFJlbW92aW5n IHBhY2tldCBudW1iZXIgZ2Fwcw0KDQorMQ0KUm9uaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEx1YmFzaGV2LCBJZ29yDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDAyLCAyMDE4IDQ6MTUg QU0NClRvOiBNYXJ0aW4gVGhvbXNvbjsgUVVJQyBXRw0KU3ViamVjdDogUkU6IFJlbW92aW5nIHBh Y2tldCBudW1iZXIgZ2Fwcw0KDQpDb3VsZCB3ZSB1c2UgUExVUyBpbnN0ZWFkIG9mIFhPUj8gIE15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGVyZSBpcyBsaXR0bGUgY3J5cHRvZ3JhcGhpYyBkaWZm ZXJlbmNlIGJldHdlZW4gWE9SIGFuZCBQTFVTLCBhbmQgaXQgaXMgbmljZXIgdG8gaGF2ZSBjb25z ZWN1dGl2ZSBwYWNrZXQgbnVtYmVycyBvbiB0aGUgd2lyZS4uLg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBn bWFpbC5jb21dDQpTZW50OiBNb25kYXksIEphbnVhcnkgMDEsIDIwMTggODo1NyBQTQ0KVG86IFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZW1vdmluZyBwYWNrZXQgbnVtYmVyIGdh cHMNCg0KVGhlcmUgYXJlIG51bWJlciBvZiBwcm9ibGVtcyB3aXRoIHBhY2tldCBudW1iZXIgZ2Fw cyB0aGF0IEkgdGhpbmsgd2UgbmVlZCB0byBhZGRyZXNzLiAgTW9zdCBhcmUgbWlub3IuICBGb3Ig aW5zdGFuY2UsIHRoZSBpbml0aWFsIHBhY2tldCBudW1iZXIgaXMgbm90IGNsb3NlIHRvIHplcm8s IHdoaWNoIGluZmxhdGVzIHRoZSBzaXplIG9mIEFDSyBmcmFtZXMgZnJvbSB0aGUgdmVyeSBiZWdp bm5pbmcgb2YgYSBjb25uZWN0aW9uLg0KDQpIb3dldmVyLCBDaHJpc3RpYW4ganVzdCBpZGVudGlm aWVkIG9uZSB0aGF0IEkgdGhpbmsgbWFrZXMgdGhpcyBtb3JlIGltcG9ydGFudCB0byBhZGRyZXNz OiB3aGVuIHVzaW5nIGEgbmV3IGNvbm5lY3Rpb24gSUQsIHRoZSBnYXAgaXMgdGhlIHNhbWUgc2l6 ZSBvbiBib3RoIGNsaWVudCBhbmQgc2VydmVyLiAgVGhpcyBtYWtlcyBmbG93cyBsaW5rYWJsZS4g IFRoZSBnYXBzIGJldHdlZW4gdGhlIGxhc3QgcGFja2V0IG9uIHRoZSBvbGQgZmxvdyBhbmQgdGhl IGZpcnN0IHBhY2tldCBvbiB0aGUgbmV3IGZsb3cgY2FuIGJlIGNhbGN1bGF0ZWQgaW4gYm90aCBk aXJlY3Rpb25zLiAgRmxvd3MgY2FuIGJlIGxpbmtlZCBieSBmaW5kaW5nIGZsb3dzIHdoZXJlIGNs aWVudC10by1zZXJ2ZXIgcGFja2V0cyBoYXZlIHRoZSBzYW1lIChvciB2ZXJ5IGNsb3NlKSBnYXBz IGFzIHNlcnZlci10by1jbGllbnQgcGFja2V0cy4NCg0KV2l0aCBhIGZldyBzbWFsbCB0d2Vha3Mg dG8gdGhlIGN1cnJlbnQgZGVzaWduLCBJIHRoaW5rIHRoYXQgd2UgZ2V0IGEgbXVjaCBiZXR0ZXIg c29sdXRpb24uICBIZXJlIGlzIHdoYXQgSSBwcm9wb3NlOg0KDQpGaXJzdGx5LCBwYWNrZXQgbnVt YmVycyBzdGFydCBhdCB6ZXJvIGFuZCBhbHdheXMgaW5jcmVhc2UgbW9ub3RvbmljYWxseSwgd2l0 aCBubyBnYXBzLiAgQSBzaWRlIGJlbmVmaXQgb2YgdGhpcyBpcyB0aGF0IHRoZSBmaXJzdCBBQ0sg ZnJhbWUgd2lsbCBoYXZlIGEgc21hbGwgZW5jb2RpbmcgZm9yIGxhcmdlc3RfYWNrbm93bGVkZ2Vk ICgxIG9jdGV0IHJhdGhlciB0aGFuIDggaW4gbW9zdCBjYXNlcykuDQoNClBhY2tldCBudW1iZXJz IGFyZSBuZXZlciBlbmNvZGVkIGRpcmVjdGx5IG9udG8gdGhlIHdpcmUsIHRoZXkgYXJlIFhPUmVk IHdpdGggYSBtYXNraW5nIHZhbHVlLiAgVGhpcyB2YWx1ZSB3aWxsIGNoYW5nZSBmb3IgZGlmZmVy ZW50IHBhY2tldCBwcm90ZWN0aW9uIGtleXMsIGFuZCBmb3IgZGlmZmVyZW50IGNvbm5lY3Rpb24g SURzLiAgQ2xpZW50IGFuZCBzZXJ2ZXIgd2lsbCB1c2UgZGlmZmVyZW50IHZhbHVlcyBzbyB0aGF0 IGdhcHMgYXJlIGhhcmQgdG8gZGV0ZWN0Lg0KDQpUaHVzLCB3ZSB3aWxsIGhhdmUgYSB0aGlyZCBr ZXkgZGVyaXZhdGlvbjoNCg0KICAga2V5ID0gUUhLREYtRXhwYW5kKFMsICJrZXkiLCBrZXlfbGVu Z3RoKQ0KICAgaXYgID0gUUhLREYtRXhwYW5kKFMsICJpdiIsIGl2X2xlbmd0aCkNCiAgIHBubWFz ayA9IFFIS0RGLUV4cGFuZChTLCAicG5tYXNrIiwgNCkNCg0KVG8gbWFrZSB0aGlzIHdvcmsgc2Vh bWxlc3NseSwgSSdtIHByb3Bvc2luZyBhIHR3ZWFrIHRvIFFIS0RGLUV4cGFuZCB0aGF0IGluY2x1 ZGVzIHRoZSBjb25uZWN0aW9uIElELiAgRm9yIHRoYXQsIHRoZSAiQ29udGV4dCIgZmllbGQgdGhh dCB3ZSBjdXJyZW50bHkgZG8gbm90IHVzZSBzZWVtcyBsaWtlIGEgZ29vZCBjaG9pY2UuDQoNClRo aXMgd2lsbCBtZWFuIGNoYW5nZXMgdG8gdGhlIG90aGVyIHVzZXMgb2YgUUhLREYtRXhwYW5kOg0K DQoqIHRoZSBoYW5kc2hha2Ugc2VjcmV0IGNhbiBiZSBjaGFuZ2VkIHRvIGJlIGEgZml4ZWQgcmF0 aGVyIHRoYW4gYSBkZXJpdmVkIHZhbHVlLCBzbyB0aGF0IHdlIGRvbid0IG5lZWQgdG8gdXNlIHRo ZSBmdW5jdGlvbiAoY29ubmVjdGlvbiBJRCB3aWxsIGJlIGFkZGVkIGR1cmluZyBleHBhbnNpb24g aW50byB0aGUgc2VwYXJhdGUga2V5cykNCg0KKiBkdXJpbmcgYSBrZXkgdXBkYXRlLCBhIHplcm8t bGVuZ3RoIG9yIGZpeGVkIGNvbm5lY3Rpb24gSUQgd2lsbCBuZWVkIHRvIGJlIHVzZWQgc28gdGhh dCB0aGVyZSBpcyBubyBjb25mdXNpb24gYWJvdXQgd2hpY2ggY29ubmVjdGlvbiBJRCB3YXMgaW4g dXNlIGF0IHRoZSB0aW1lIHRoZSB1cGRhdGUgd2FzIG1hZGUgKGVkaXRvcmlhbGx5LCBJJ20gbm90 IGNlcnRhaW4gaG93IHRvIG1hbmFnZSB0aGlzIG9uZSwgSSBtaWdodCBqdXN0IGdvIGJhY2sgdG8g dXNpbmcgSEtERi1FeHBhbmQtTGFiZWwgZGlyZWN0bHkgZm9yIHRoYXQpDQoNCkZpbmFsbHksIHdl IG5lZWQgdG8gYmUgdmVyeSBjbGVhciB0aGF0IGV2ZW4gaWYgdGhlIGNvbm5lY3Rpb24gSUQgaXMg b21pdHRlZCwgdGhvc2UgcGFja2V0cyBzdGlsbCB1c2UgdGhlIGltcGxpZWQgY29ubmVjdGlvbiBJ RCBpbiBrZXkgZGVyaXZhdGlvbi4gIFdlIHdpbGwgcHJvYmFibHkgd2FudCB0byByZWNvbW1lbmQg dGhhdCBlbmRwb2ludHMgaW5jbHVkZSBhIGNvbm5lY3Rpb24gSUQgaWYgdGhleSBpbnRlbmQgdG8g c3VwcG9ydCBORVdfQ09OTkVDVElPTl9JRCBvciBhbnkgb2YgdGhlIHJlbGF0ZWQgZnVuY3Rpb25z LCBhdCBsZWFzdCBhcm91bmQgdGhlIHRpbWUgd2hlbiBhIGNvbm5lY3Rpb24gSUQgY2hhbmdlIGlz IGluIHBsYWNlIG9yIHRoZSByZWNpcGllbnQgb2YgdGhlaXIgcGFja2V0cyBjb3VsZCBoYXZlIGRp ZmZpY3VsdHkgcGlja2luZyB0aGUgcmlnaHQga2V5cy4gIFRoaXMgaXMgYWxyZWFkeSBhIHByb2Js ZW0gb2YgY291cnNlLCBidXQgdGhpcyBjaGFuZ2Ugd291bGQgbWFrZSBpdCB3b3JzZS4NCg0K From nobody Fri Jan 5 14:38:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5C712D88D for ; Fri, 5 Jan 2018 14:38:56 -0800 (PST) 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 xL5R7rZB9HUe for ; Fri, 5 Jan 2018 14:38:54 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 BE9131205D3 for ; Fri, 5 Jan 2018 14:38:54 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id r78so4978522wme.5 for ; Fri, 05 Jan 2018 14:38:54 -0800 (PST) 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=gq6blhxEHIgj2tO06+MQB7AEBiikKgmMYCPaaHvfnx4=; b=kGPmjATqbu77uX4DdT0UX7YDo6gO6cZ9opPIxhwzu2AhPH1o4KfV+IHzNTNlb7Ni3u tJNmGznzf8tfqHhvUUGQUavBUBql8QEvQ/VEyklFiDW5kH89C9zIXPfgId8cwkX7Fzp4 qI4QbMMQUYCbguVUviJZJV6YfK1fwWbyZ1/ltJo1OoG06eJN00kSYh41KjHY0K0YtwJq E8XweF5IKCmXvplsTaOeV5TsOr2NOwTH0V00wEbWt/fhOpxQjAEZvToG9kqgBF8wOZlE Lf28u4GkJNoLq1nlr5RpvCunEAtAlOwABSSZJHSr90M+4NBBdqGRE/46h1pC+uADMW2L L5uA== 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=gq6blhxEHIgj2tO06+MQB7AEBiikKgmMYCPaaHvfnx4=; b=XZUOH0jGab7cYkUl/Bg2YnBvCT7YHpJBndwod5xAcO7PDF1KJ2uAPrb0DOnIXL18UE rOvG8ZKHzVqdM9n2KNhIql4id2mpQSx0BcdZLIw7vmf5X69N8GfobHbFLif3ZbJ3gF52 Ul8aY7L/zZ+uRbj/AdxdhcEi+YYUmXWqDv2QyCv67krJvoOf0GydGBvIyJmp084c/bkS 8zF6PP2XMPwjEcKV2SSoJSuIjq0kMPgFGt+owZIrVEchpBskGc4Eum+9Nzorvzxas8Sw Zns1QSaxq5ceCjgeSRJq0T7gTpr+frIR2MwCeHW+LsoeSiPW3HHcZkKRRrnbfxzZih9R 2g2Q== X-Gm-Message-State: AKwxytddJ3YDyyp+cjLi52P8+soWWDoPzZKqQJEjUz0QmJoNbfl7Pyrj IrrB8Nirq4+Io4EwqdIa0ctwHvuNpdVlyjXsjdx4tA== X-Google-Smtp-Source: ACJfBoutQclDFVP1UsfdaTzNZ6NzqsOnqURcYHJEafwP3dFMRpfv0v8x5QgTpB9VqQKxePkS4ygurPXmbPGJBuk8NOw= X-Received: by 10.28.214.68 with SMTP id n65mr3052015wmg.18.1515191932877; Fri, 05 Jan 2018 14:38:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Fri, 5 Jan 2018 14:38:52 -0800 (PST) From: Martin Duke Date: Fri, 5 Jan 2018 14:38:52 -0800 Message-ID: Subject: Long Headers and Version Negotiation To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1146f69aed031105620f1c58" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Jan 2018 22:38:57 -0000 --001a1146f69aed031105620f1c58 Content-Type: text/plain; charset="UTF-8" The invariants draft only reserves the 0x80 and 0x40 codepoints in the first byte of the packet. The transport draft suggests that only initial packets should trigger version negotiation. However, the Initial Packet byte (0xff) is not invariant. So for version negotiation to work at all, servers must send VN packets for *any* long header type where the version is unsupported -- otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers would ignore it. On the other hand, in 0RTT cases this might create a storm of VN packets if the version is wrong. I suppose clients are probably not sending 0RTT if they don't know the supported versions. Am I thinking about this correctly? If so, I'm happy to file an issue, and a PR if we agree that the correct solution is to reply with VN to all long headers with unsupported versions. - Martin Duke --001a1146f69aed031105620f1c58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The invariants draft only reserve= s the 0x80 and 0x40 codepoints in the first byte of the packet.
<= br>
The transport draft suggests that only initial packets should= trigger version negotiation. However, the Initial Packet byte (0xff) is no= t invariant. So for version negotiation to work at all, servers must send V= N packets for any=C2=A0long header type where the version is unsuppo= rted -- otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 se= rvers would ignore it.

On the other hand, in 0RTT = cases this might create a storm of VN packets if the version is wrong. I su= ppose clients are probably not sending 0RTT if they don't know the supp= orted versions.

Am I thinking about this correctly= ? If so, I'm happy to file an issue, and a PR if we agree that the corr= ect solution is to reply with VN to all long headers with unsupported versi= ons.

- Martin Duke
--001a1146f69aed031105620f1c58-- From nobody Fri Jan 5 14:46:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A55F12D951 for ; Fri, 5 Jan 2018 14:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 XhMOdD_KDVpt for ; Fri, 5 Jan 2018 14:46:35 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0129.outbound.protection.outlook.com [104.47.36.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEFC812D88D for ; Fri, 5 Jan 2018 14:46:34 -0800 (PST) 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=eF/hyng5v6kSOlOjBkpY0iUwf0GmrqegzCm1fWink8Q=; b=aXyEn8+O7FwqovXHvYmoJHbzjMftKJUSCDTa1twM/zzrffHUevhH8o+UYPS7PeH35wnDkApfrMjlaoQTOPi3oL8Bd86EZV34N/ZiNdYZ11ltwi9hpwJIZCEo4XVqcR9uEYKFVa5s4skGgElv8Lb7vJO2vMIF4bnkMyrKPat8HuE= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0498.namprd21.prod.outlook.com (10.172.112.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.407.2; Fri, 5 Jan 2018 22:46:33 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0407.000; Fri, 5 Jan 2018 22:46:33 +0000 From: Nick Banks To: Martin Duke , IETF QUIC WG Subject: RE: Long Headers and Version Negotiation Thread-Topic: Long Headers and Version Negotiation Thread-Index: AQHThnX+J8BPuJe7nUO6Dw9FXgyXMKNl4JHw Date: Fri, 5 Jan 2018 22:46:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-01-05T22:46:32.0641011Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1::77f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0498; 7:A5MBTGDETBSIS+/XlmbEngQ0qjWOtY/G2YZRjfBtvg+AzLeG7htB1TV4jTDv/4r7a/sit5jEKF9WNwFmwnggpoetO28Xy/ChcTEk7GZiB9AQNncrGAuECyvOoqhMJgtKuOMNHrVASbeCyI1SOVmMe7+8wNOuvJi0S4QC5eY2uGDr5dWUVt88cT1qvxAwCw01m9mFaGgnvFjcEXJPyJ/gJzfi7R3oWFiNi3vBwnjL7zjP7sGzlmzRHhWiq2Bsno/f x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 71cc978e-009b-4930-77e5-08d5548e2b83 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020020)(48565401081)(5600026)(4604075)(3008032)(4534040)(4602075)(4627136)(201703031133081)(201702281549075)(2017052603307); SRVR:BN6PR21MB0498; x-ms-traffictypediagnostic: BN6PR21MB0498: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(3231023)(944501075)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041268)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:BN6PR21MB0498; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR21MB0498; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39380400002)(366004)(39860400002)(189003)(199004)(10090500001)(53546011)(25786009)(6506007)(110136005)(606006)(316002)(6246003)(10290500003)(8990500004)(81166006)(478600001)(53936002)(14454004)(22452003)(76176011)(39060400002)(8676002)(33656002)(790700001)(3660700001)(106356001)(6116002)(97736004)(86362001)(99286004)(19609705001)(77096006)(229853002)(2906002)(236005)(68736007)(7736002)(55016002)(7696005)(81156014)(6436002)(2950100002)(102836004)(8936002)(105586002)(86612001)(3280700002)(9686003)(2900100001)(6306002)(54896002)(5660300001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0498; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: Vc7Ef37+SHLbtkB5stbnRzS9SaooqH8EMjvsH+vGz0cxoIVsy4xLYautLkWWoxGxqstprqofI4P5lhIog1B/kg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB01788D37BFE5700EB00F392AB31C0BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 71cc978e-009b-4930-77e5-08d5548e2b83 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 22:46:33.3817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0498 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Jan 2018 22:46:37 -0000 --_000_BN6PR21MB01788D37BFE5700EB00F392AB31C0BN6PR21MB0178namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGFyZSBzZW5kaW5nIDAtUlRUIHBhY2tldHMgdGhlbiB5b3UgaGF2ZSBjb25uZWN0ZWQg dG8gdGhpcyBzZXJ2ZXIgYmVmb3JlIGFuZCBzaG91bGQgYmUgYWJsZSB0byByZW1lbWJlciB0aGUg dmVyc2lvbiB5b3UgdXNlZC4gVGhlIG9ubHkgaXNzdWUgdGhlbiwgaXMgaWYgdGhlIHNlcnZlciBz dG9wcyBzdXBwb3J0aW5nIGEgcGFydGljdWxhciB2ZXJzaW9uIGFuZCB0aGVuIHlvdSB0cnkgdG8g cmVjb25uZWN0LiBFaXRoZXIgd2F5LCBhIHNlcnZlciBtaWdodCB3YW50IHRvIGhhdmUgc29tZSB0 aHJvdHRsaW5nIGxvZ2ljIGZvciBWTiBwYWNrZXRzIHNlbnQgb3V0OyBidXQgSSBkb27igJl0IHRo aW5rIGl0IHdvdWxkIGJlIHRoZSBlbmQgb2YgdGhlIHdvcmxkIGlmIGl0IGRpZG7igJl0Lg0KDQot IE5pY2sgQmFua3MNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1hcnRpbiBEdWtlDQpTZW50OiBGcmlkYXksIEphbnVhcnkgNSwgMjAxOCAy OjM5IFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogTG9uZyBI ZWFkZXJzIGFuZCBWZXJzaW9uIE5lZ290aWF0aW9uDQoNClRoZSBpbnZhcmlhbnRzIGRyYWZ0PGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtdGhvbXNvbi1xdWljLWludmFyaWFu dHMtMDAmZGF0YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jvc29mdC5jb20lN0NkM2EyNDQ5Yjky Mzk0OTdlODBhNjA4ZDU1NDhkMWVmZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3 JTdDMSU3QzAlN0M2MzY1MDc4ODc0NTYxNzA4OTgmc2RhdGE9bDFnTWZJa3g5UW1KaUp0a0hSQUxQ ZXZhZk5ydTVBNjNJd2lNc25VYWo4NCUzRCZyZXNlcnZlZD0wPiBvbmx5IHJlc2VydmVzIHRoZSAw eDgwIGFuZCAweDQwIGNvZGVwb2ludHMgaW4gdGhlIGZpcnN0IGJ5dGUgb2YgdGhlIHBhY2tldC4N Cg0KVGhlIHRyYW5zcG9ydCBkcmFmdCBzdWdnZXN0cyB0aGF0IG9ubHkgaW5pdGlhbCBwYWNrZXRz IHNob3VsZCB0cmlnZ2VyIHZlcnNpb24gbmVnb3RpYXRpb24uIEhvd2V2ZXIsIHRoZSBJbml0aWFs IFBhY2tldCBieXRlICgweGZmKSBpcyBub3QgaW52YXJpYW50LiBTbyBmb3IgdmVyc2lvbiBuZWdv dGlhdGlvbiB0byB3b3JrIGF0IGFsbCwgc2VydmVycyBtdXN0IHNlbmQgVk4gcGFja2V0cyBmb3Ig YW55IGxvbmcgaGVhZGVyIHR5cGUgd2hlcmUgdGhlIHZlcnNpb24gaXMgdW5zdXBwb3J0ZWQgLS0g b3RoZXJ3aXNlLCBRVUlDdjIgbWlnaHQgc2VsZWN0IDB4ZTMgYXMgdGhlIEluaXRpYWwgUGFja2V0 IGFuZCB2MSBzZXJ2ZXJzIHdvdWxkIGlnbm9yZSBpdC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGlu IDBSVFQgY2FzZXMgdGhpcyBtaWdodCBjcmVhdGUgYSBzdG9ybSBvZiBWTiBwYWNrZXRzIGlmIHRo ZSB2ZXJzaW9uIGlzIHdyb25nLiBJIHN1cHBvc2UgY2xpZW50cyBhcmUgcHJvYmFibHkgbm90IHNl bmRpbmcgMFJUVCBpZiB0aGV5IGRvbid0IGtub3cgdGhlIHN1cHBvcnRlZCB2ZXJzaW9ucy4NCg0K QW0gSSB0aGlua2luZyBhYm91dCB0aGlzIGNvcnJlY3RseT8gSWYgc28sIEknbSBoYXBweSB0byBm aWxlIGFuIGlzc3VlLCBhbmQgYSBQUiBpZiB3ZSBhZ3JlZSB0aGF0IHRoZSBjb3JyZWN0IHNvbHV0 aW9uIGlzIHRvIHJlcGx5IHdpdGggVk4gdG8gYWxsIGxvbmcgaGVhZGVycyB3aXRoIHVuc3VwcG9y dGVkIHZlcnNpb25zLg0KDQotIE1hcnRpbiBEdWtlDQo= --_000_BN6PR21MB01788D37BFE5700EB00F392AB31C0BN6PR21MB0178namp_ 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 ZiB5b3UgYXJlIHNlbmRpbmcgMC1SVFQgcGFja2V0cyB0aGVuIHlvdSBoYXZlIGNvbm5lY3RlZCB0 byB0aGlzIHNlcnZlciBiZWZvcmUgYW5kIHNob3VsZCBiZSBhYmxlIHRvIHJlbWVtYmVyIHRoZSB2 ZXJzaW9uIHlvdSB1c2VkLiBUaGUgb25seSBpc3N1ZSB0aGVuLCBpcyBpZiB0aGUgc2VydmVyIHN0 b3BzIHN1cHBvcnRpbmcgYSBwYXJ0aWN1bGFyIHZlcnNpb24gYW5kIHRoZW4geW91IHRyeSB0byBy ZWNvbm5lY3QuDQogRWl0aGVyIHdheSwgYSBzZXJ2ZXIgbWlnaHQgd2FudCB0byBoYXZlIHNvbWUg dGhyb3R0bGluZyBsb2dpYyBmb3IgVk4gcGFja2V0cyBzZW50IG91dDsgYnV0IEkgZG9u4oCZdCB0 aGluayBpdCB3b3VsZCBiZSB0aGUgZW5kIG9mIHRoZSB3b3JsZCBpZiBpdCBkaWRu4oCZdC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBOaWNrIEJhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YNCjwvYj5NYXJ0aW4gRHVrZTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVh cnkgNSwgMjAxOCAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IExvbmcgSGVhZGVycyBhbmQgVmVyc2lv biBOZWdvdGlhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSA8 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LXRob21zb24tcXVp Yy1pbnZhcmlhbnRzLTAwJmFtcDtkYXRhPTAyJTdDMDElN0NuaWJhbmtzJTQwbWljcm9zb2Z0LmNv bSU3Q2QzYTI0NDliOTIzOTQ5N2U4MGE2MDhkNTU0OGQxZWZmJTdDNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjUwNzg4NzQ1NjE3MDg5OCZhbXA7c2RhdGE9bDFn TWZJa3g5UW1KaUp0a0hSQUxQZXZhZk5ydTVBNjNJd2lNc25VYWo4NCUzRCZhbXA7cmVzZXJ2ZWQ9 MCIgdGFyZ2V0PSJfYmxhbmsiPg0KaW52YXJpYW50cyBkcmFmdDwvYT4gb25seSByZXNlcnZlcyB0 aGUgMHg4MCBhbmQgMHg0MCBjb2RlcG9pbnRzIGluIHRoZSBmaXJzdCBieXRlIG9mIHRoZSBwYWNr ZXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSB0cmFuc3BvcnQgZHJhZnQgc3VnZ2VzdHMgdGhhdCBvbmx5IGluaXRpYWwgcGFja2V0cyBz aG91bGQgdHJpZ2dlciB2ZXJzaW9uIG5lZ290aWF0aW9uLiBIb3dldmVyLCB0aGUgSW5pdGlhbCBQ YWNrZXQgYnl0ZSAoMHhmZikgaXMgbm90IGludmFyaWFudC4gU28gZm9yIHZlcnNpb24gbmVnb3Rp YXRpb24gdG8gd29yayBhdCBhbGwsIHNlcnZlcnMgbXVzdCBzZW5kIFZOIHBhY2tldHMgZm9yDQo8 Yj5hbnk8L2I+Jm5ic3A7bG9uZyBoZWFkZXIgdHlwZSB3aGVyZSB0aGUgdmVyc2lvbiBpcyB1bnN1 cHBvcnRlZCAtLSBvdGhlcndpc2UsIFFVSUN2MiBtaWdodCBzZWxlY3QgMHhlMyBhcyB0aGUgSW5p dGlhbCBQYWNrZXQgYW5kIHYxIHNlcnZlcnMgd291bGQgaWdub3JlIGl0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgb3RoZXIgaGFu ZCwgaW4gMFJUVCBjYXNlcyB0aGlzIG1pZ2h0IGNyZWF0ZSBhIHN0b3JtIG9mIFZOIHBhY2tldHMg aWYgdGhlIHZlcnNpb24gaXMgd3JvbmcuIEkgc3VwcG9zZSBjbGllbnRzIGFyZSBwcm9iYWJseSBu b3Qgc2VuZGluZyAwUlRUIGlmIHRoZXkgZG9uJ3Qga25vdyB0aGUgc3VwcG9ydGVkIHZlcnNpb25z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bSBJIHRoaW5raW5nIGFib3V0IHRoaXMgY29ycmVjdGx5PyBJZiBzbywgSSdtIGhhcHB5IHRvIGZp bGUgYW4gaXNzdWUsIGFuZCBhIFBSIGlmIHdlIGFncmVlIHRoYXQgdGhlIGNvcnJlY3Qgc29sdXRp b24gaXMgdG8gcmVwbHkgd2l0aCBWTiB0byBhbGwgbG9uZyBoZWFkZXJzIHdpdGggdW5zdXBwb3J0 ZWQgdmVyc2lvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0gTWFydGluIER1a2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR21MB01788D37BFE5700EB00F392AB31C0BN6PR21MB0178namp_-- From nobody Fri Jan 5 14:51:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D3812D88D for ; Fri, 5 Jan 2018 14:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3lcSGcKLNmD for ; Fri, 5 Jan 2018 14:51:47 -0800 (PST) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F4E120726 for ; Fri, 5 Jan 2018 14:51:46 -0800 (PST) Received: by mail-wr0-x22e.google.com with SMTP id w107so5528865wrb.9 for ; Fri, 05 Jan 2018 14:51:46 -0800 (PST) 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=h/V0XNYZBXjWub6uXTXXQsbkEPy4hVNHYjPA2Mvui1s=; b=vhKlTYnP5nP6GoAyAdwpEEIkxPvx6rLwSZQQc9Uc4AuNgL2uhgIbTe6Bgmy753uEUR kVDwiD3nTOSO27E1cPR/+w1An/ZdLSZD8+l5r63Xzk1q6CpAzMpwPsMz6HmEg7M4brzv XNW3/tTqHDZki7j/2crrh2M3hhaR0ywcooizm3uezEZpjr75ObnavXhi8+366cuyNjCb FROfni4gtoxwkq8XJdrGI1ofpdeSdiWhXIZgEmsfJpHfwk+boNsBZ/150mmJnnn5FtbL XUwiUR7xqkK5VQ/dn4l5DdpIUAN4kZz8iBee94BO0kL8KywTdMXE03qb3r8DVRXFhic3 f35Q== 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=h/V0XNYZBXjWub6uXTXXQsbkEPy4hVNHYjPA2Mvui1s=; b=QcRvG9RfnAM360Fn/yHi4lEIBxRRIa6FzaKhxm5J6Ymn4JgMru74urT2UMMPqbsRtQ tOt1m7UZ8tIgb1eHP2SNiYU8Bmqn5uiPDeIcBA95UmCdFPnm/PChFRwn1O+oV2sHpT92 0cLi2V39gW+QYZakDdFpvjoh5mHM3fiDMTa7Qkax/vHClnb1WEY1Fiu0KDxjRQYPgEzL 5IX3r3GjOaiw5TxT/od3hXwRM0pg5pWKjvXooWPc1XefuaY6Fqa3iRXjDkFezr947NXL NnXyhKUrfmXDhb9aMsJLjmid/IzVC/5QLetVv5SOjgoAX1AgJXR6+EQDtr2kRvtzD0Hu ZFEg== X-Gm-Message-State: AKGB3mJXVbLRLp7uVopGPGxn4NGD+aVjFrYQskql0eQbeS3a4HIZTxG9 o8c1SSFii6IYHaQGbIIXHyM+Rfc25ehWYUsprN8= X-Google-Smtp-Source: ACJfBot9ee8+r/ZLuRIzSETGxTz8lv26BUAQiA5oZLJZH8phCN5hh8Pqb7U3C5c9sBYYywnmkR9A6JNDslt7TeerAP4= X-Received: by 10.223.208.206 with SMTP id z14mr4185882wrh.109.1515192705491; Fri, 05 Jan 2018 14:51:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Fri, 5 Jan 2018 14:51:45 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Fri, 5 Jan 2018 14:51:45 -0800 Message-ID: Subject: Re: Long Headers and Version Negotiation To: Nick Banks Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f4f5e80a2e34fa27a005620f4a0c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Jan 2018 22:51:50 -0000 --f4f5e80a2e34fa27a005620f4a0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree. The only other alternative I can see is to make 0xff an invariant for initial packets. I don't have a strong opinion one way or the other. On Fri, Jan 5, 2018 at 2:46 PM, Nick Banks wrote: > If you are sending 0-RTT packets then you have connected to this server > before and should be able to remember the version you used. The only issu= e > then, is if the server stops supporting a particular version and then you > try to reconnect. Either way, a server might want to have some throttling > logic for VN packets sent out; but I don=E2=80=99t think it would be the = end of the > world if it didn=E2=80=99t. > > > > - Nick Banks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Martin Duke > *Sent:* Friday, January 5, 2018 2:39 PM > *To:* IETF QUIC WG > *Subject:* Long Headers and Version Negotiation > > > > The invariants draft > > only reserves the 0x80 and 0x40 codepoints in the first byte of the packe= t. > > > > The transport draft suggests that only initial packets should trigger > version negotiation. However, the Initial Packet byte (0xff) is not > invariant. So for version negotiation to work at all, servers must send V= N > packets for *any* long header type where the version is unsupported -- > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers > would ignore it. > > > > On the other hand, in 0RTT cases this might create a storm of VN packets > if the version is wrong. I suppose clients are probably not sending 0RTT = if > they don't know the supported versions. > > > > Am I thinking about this correctly? If so, I'm happy to file an issue, an= d > a PR if we agree that the correct solution is to reply with VN to all lon= g > headers with unsupported versions. > > > > - Martin Duke > --f4f5e80a2e34fa27a005620f4a0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree. The only other alternative I can see is to make 0= xff an invariant for initial packets. I don't have a strong opinion one= way or the other.

On Fri, Jan 5, 2018 at 2:46 PM, Nick Banks <nibanks@microsoft.c= om> wrote:

If you are sending 0-RTT packets then you have conne= cted to this server before and should be able to remember the version you u= sed. The only issue then, is if the server stops supporting a particular ve= rsion and then you try to reconnect. Either way, a server might want to have some throttling logic for VN packe= ts sent out; but I don=E2=80=99t think it would be the end of the world if = it didn=E2=80=99t.

=C2=A0

- Nick Banks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Friday, January 5, 2018 2:39 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: Long Headers and Version Negotiation

=

=C2=A0

The invariants draft only reserves the 0x80 and 0x40 codepoints in the firs= t byte of the packet.

=C2=A0

The transport draft suggests that only initial packe= ts should trigger version negotiation. However, the Initial Packet byte (0x= ff) is not invariant. So for version negotiation to work at all, servers mu= st send VN packets for any=C2=A0long header type where the version is unsupported -- otherw= ise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers would ig= nore it.

=C2=A0

On the other hand, in 0RTT cases this might create a= storm of VN packets if the version is wrong. I suppose clients are probabl= y not sending 0RTT if they don't know the supported versions.=

=C2=A0

Am I thinking about this correctly? If so, I'm h= appy to file an issue, and a PR if we agree that the correct solution is to= reply with VN to all long headers with unsupported versions.=

=C2=A0

- Martin Duke


--f4f5e80a2e34fa27a005620f4a0c-- From nobody Fri Jan 5 14:58:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E98A12D833 for ; Fri, 5 Jan 2018 14:58:02 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 MmZhzbagH_Xs for ; Fri, 5 Jan 2018 14:57:59 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B58126BF6 for ; Fri, 5 Jan 2018 14:57:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=36ch1Lx0WU5G7KN66TgOLbXqFx5QruH1n6m8WsJdMuk=; b=RE7KrnIyLh2nmbsksPx04fdqES0v4MIqThs2CqQDdIdc/ywUIU35UMFdD45TGClz0XiK/7MYa0rUO1D3/9/zGLc1TPodh4eY9bdd8RCIQbjFXZHpoWKKhiUWzcmvJdWiSussML0SoOnRkzsTL1QTgOfIjmgIJTFYHwYodYoJiz4= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2431.namprd08.prod.outlook.com (10.169.203.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 5 Jan 2018 22:57:55 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0386.006; Fri, 5 Jan 2018 22:57:55 +0000 From: Mike Bishop To: Martin Duke , Nick Banks CC: IETF QUIC WG Subject: RE: Long Headers and Version Negotiation Thread-Topic: Long Headers and Version Negotiation Thread-Index: AQHThnX9L2LzHEWFXk+2QU3wPj2mn6Nl4SWAgAABdICAAAFbQA== Date: Fri, 5 Jan 2018 22:57:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2431; 7:cWLfmjLUMxFDuxPeNviVInI6MxtDBhtplcKwAOKeZ7RnS1fD+eO0cAhysSLqEY6edTBxdj5/PVSKCSoOOFlv2HJOnj+fhzFvpkj4qdNUa813cyG42LvjoZVmSbjeblMVNB74RDGKHMcG5R6PgkGnmIDsUWqO+CwWj0T+XzWDCv7cFFdIaQSKQn7MvxlcVLnvxLGxKHiXbD2xveEyBprQxx540l54bjvs89fWYZHYtwSQSlb1mJgo8ExKHo2JTzQf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: be4476cf-2c07-4157-68bf-08d5548fc1ce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060); SRVR:MWHPR08MB2431; x-ms-traffictypediagnostic: MWHPR08MB2431: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(189930954265078)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6041268)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2431; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR08MB2431; x-forefront-prvs: 05437568AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(39830400003)(39380400002)(189003)(24454002)(199004)(14454004)(2906002)(86362001)(8676002)(19609705001)(25786009)(478600001)(606006)(81156014)(7696005)(229853002)(81166006)(53936002)(105586002)(790700001)(6116002)(2950100002)(53546011)(97736004)(106356001)(110136005)(6246003)(316002)(45080400002)(8936002)(74482002)(68736007)(102836004)(8666007)(3280700002)(74316002)(77096006)(3660700001)(1511001)(6436002)(7736002)(33656002)(55016002)(54896002)(76176011)(66066001)(6506007)(6306002)(4326008)(5660300001)(3846002)(39060400002)(9686003)(236005)(99286004)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2431; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: /tCpZ/Wa09Cvx4ucTmWoUcv6yWeL7Npomx7hBqRoX6T7fUJGpZmaHJLgmniP4r0Kek7Cnwz/eYiGduWQ8Qs2Tw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432DF994B55055CA2418D97DA1C0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: be4476cf-2c07-4157-68bf-08d5548fc1ce X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2018 22:57:54.9504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2431 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Jan 2018 22:58:03 -0000 --_000_MWHPR08MB2432DF994B55055CA2418D97DA1C0MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhY3R1YWxseSBiZW5lZmljaWFsLCBhbGJlaXQgYSBjb3JuZXIgY2FzZSDigJMgaWYg dGhlIEluaXRpYWwgcGFja2V0IGlzIGxvc3QsIGJ1dCB0aGUgdmVyc2lvbiBpcyB1bmtub3duLCB0 aGVuIHRoZSAwLVJUVCBwYWNrZXRzIHdpbGwgc3RpbGwgcHJvdm9rZSB0aGUgVmVyc2lvbiBOZWdv dGlhdGlvbiBwYWNrZXQgYW5kIHRoZSBsb3NzIGRvZXNu4oCZdCBpbmR1Y2UgYW4gUlRPLg0KDQpG cm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy dGluIER1a2UNClNlbnQ6IEZyaWRheSwgSmFudWFyeSA1LCAyMDE4IDI6NTIgUE0NClRvOiBOaWNr IEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPg0KU3ViamVjdDogUmU6IExvbmcgSGVhZGVycyBhbmQgVmVyc2lvbiBOZWdvdGlhdGlv bg0KDQpJIGFncmVlLiBUaGUgb25seSBvdGhlciBhbHRlcm5hdGl2ZSBJIGNhbiBzZWUgaXMgdG8g bWFrZSAweGZmIGFuIGludmFyaWFudCBmb3IgaW5pdGlhbCBwYWNrZXRzLiBJIGRvbid0IGhhdmUg YSBzdHJvbmcgb3BpbmlvbiBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCg0KT24gRnJpLCBKYW4gNSwg MjAxOCBhdCAyOjQ2IFBNLCBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb208bWFpbHRv Om5pYmFua3NAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSWYgeW91IGFyZSBzZW5kaW5nIDAtUlRU IHBhY2tldHMgdGhlbiB5b3UgaGF2ZSBjb25uZWN0ZWQgdG8gdGhpcyBzZXJ2ZXIgYmVmb3JlIGFu ZCBzaG91bGQgYmUgYWJsZSB0byByZW1lbWJlciB0aGUgdmVyc2lvbiB5b3UgdXNlZC4gVGhlIG9u bHkgaXNzdWUgdGhlbiwgaXMgaWYgdGhlIHNlcnZlciBzdG9wcyBzdXBwb3J0aW5nIGEgcGFydGlj dWxhciB2ZXJzaW9uIGFuZCB0aGVuIHlvdSB0cnkgdG8gcmVjb25uZWN0LiBFaXRoZXIgd2F5LCBh IHNlcnZlciBtaWdodCB3YW50IHRvIGhhdmUgc29tZSB0aHJvdHRsaW5nIGxvZ2ljIGZvciBWTiBw YWNrZXRzIHNlbnQgb3V0OyBidXQgSSBkb27igJl0IHRoaW5rIGl0IHdvdWxkIGJlIHRoZSBlbmQg b2YgdGhlIHdvcmxkIGlmIGl0IGRpZG7igJl0Lg0KDQotIE5pY2sgQmFua3MNCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIE1hcnRpbiBEdWtlDQpTZW50OiBGcmlkYXksIEphbnVhcnkgNSwg MjAxOCAyOjM5IFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPj4NClN1YmplY3Q6IExvbmcgSGVhZGVycyBhbmQgVmVyc2lvbiBOZWdvdGlhdGlv bg0KDQpUaGUgaW52YXJpYW50cyBkcmFmdDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUy RmRyYWZ0LXRob21zb24tcXVpYy1pbnZhcmlhbnRzLTAwJmRhdGE9MDIlN0MwMSU3Q25pYmFua3Ml NDBtaWNyb3NvZnQuY29tJTdDZDNhMjQ0OWI5MjM5NDk3ZTgwYTYwOGQ1NTQ4ZDFlZmYlN0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NTA3ODg3NDU2MTcwODk4 JnNkYXRhPWwxZ01mSWt4OVFtSmlKdGtIUkFMUGV2YWZOcnU1QTYzSXdpTXNuVWFqODQlM0QmcmVz ZXJ2ZWQ9MD4gb25seSByZXNlcnZlcyB0aGUgMHg4MCBhbmQgMHg0MCBjb2RlcG9pbnRzIGluIHRo ZSBmaXJzdCBieXRlIG9mIHRoZSBwYWNrZXQuDQoNClRoZSB0cmFuc3BvcnQgZHJhZnQgc3VnZ2Vz dHMgdGhhdCBvbmx5IGluaXRpYWwgcGFja2V0cyBzaG91bGQgdHJpZ2dlciB2ZXJzaW9uIG5lZ290 aWF0aW9uLiBIb3dldmVyLCB0aGUgSW5pdGlhbCBQYWNrZXQgYnl0ZSAoMHhmZikgaXMgbm90IGlu dmFyaWFudC4gU28gZm9yIHZlcnNpb24gbmVnb3RpYXRpb24gdG8gd29yayBhdCBhbGwsIHNlcnZl cnMgbXVzdCBzZW5kIFZOIHBhY2tldHMgZm9yIGFueSBsb25nIGhlYWRlciB0eXBlIHdoZXJlIHRo ZSB2ZXJzaW9uIGlzIHVuc3VwcG9ydGVkIC0tIG90aGVyd2lzZSwgUVVJQ3YyIG1pZ2h0IHNlbGVj dCAweGUzIGFzIHRoZSBJbml0aWFsIFBhY2tldCBhbmQgdjEgc2VydmVycyB3b3VsZCBpZ25vcmUg aXQuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpbiAwUlRUIGNhc2VzIHRoaXMgbWlnaHQgY3JlYXRl IGEgc3Rvcm0gb2YgVk4gcGFja2V0cyBpZiB0aGUgdmVyc2lvbiBpcyB3cm9uZy4gSSBzdXBwb3Nl IGNsaWVudHMgYXJlIHByb2JhYmx5IG5vdCBzZW5kaW5nIDBSVFQgaWYgdGhleSBkb24ndCBrbm93 IHRoZSBzdXBwb3J0ZWQgdmVyc2lvbnMuDQoNCkFtIEkgdGhpbmtpbmcgYWJvdXQgdGhpcyBjb3Jy ZWN0bHk/IElmIHNvLCBJJ20gaGFwcHkgdG8gZmlsZSBhbiBpc3N1ZSwgYW5kIGEgUFIgaWYgd2Ug YWdyZWUgdGhhdCB0aGUgY29ycmVjdCBzb2x1dGlvbiBpcyB0byByZXBseSB3aXRoIFZOIHRvIGFs bCBsb25nIGhlYWRlcnMgd2l0aCB1bnN1cHBvcnRlZCB2ZXJzaW9ucy4NCg0KLSBNYXJ0aW4gRHVr ZQ0KDQo= --_000_MWHPR08MB2432DF994B55055CA2418D97DA1C0MWHPR08MB2432namp_ 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+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIGlzIGFjdHVhbGx5IGJlbmVmaWNpYWwsIGFsYmVpdCBhIGNvcm5lciBjYXNlIOKAkyBpZiB0 aGUgSW5pdGlhbCBwYWNrZXQgaXMgbG9zdCwgYnV0IHRoZSB2ZXJzaW9uIGlzIHVua25vd24sIHRo ZW4gdGhlIDAtUlRUIHBhY2tldHMgd2lsbCBzdGlsbCBwcm92b2tlIHRoZSBWZXJzaW9uIE5lZ290 aWF0aW9uIHBhY2tldCBhbmQgdGhlIGxvc3MgZG9lc27igJl0IGluZHVjZSBhbiBSVE8uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5NYXJ0aW4gRHVrZTxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEphbnVhcnkgNSwgMjAxOCAyOjUyIFBNPGJyPg0KPGI+VG86PC9iPiBOaWNr IEJhbmtzICZsdDtuaWJhbmtzQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRG IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBM b25nIEhlYWRlcnMgYW5kIFZlcnNpb24gTmVnb3RpYXRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYWdyZWUuIFRoZSBvbmx5IG90aGVyIGFsdGVybmF0aXZlIEkgY2FuIHNlZSBp cyB0byBtYWtlIDB4ZmYgYW4gaW52YXJpYW50IGZvciBpbml0aWFsIHBhY2tldHMuIEkgZG9uJ3Qg aGF2ZSBhIHN0cm9uZyBvcGluaW9uIG9uZSB3YXkgb3IgdGhlIG90aGVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKYW4gNSwgMjAxOCBhdCAy OjQ2IFBNLCBOaWNrIEJhbmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rc0BtaWNyb3NvZnQu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bmliYW5rc0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPklmIHlvdSBhcmUgc2VuZGluZyAwLVJUVCBwYWNrZXRzIHRoZW4geW91IGhhdmUg Y29ubmVjdGVkIHRvIHRoaXMgc2VydmVyIGJlZm9yZSBhbmQgc2hvdWxkIGJlIGFibGUgdG8gcmVt ZW1iZXIgdGhlIHZlcnNpb24geW91IHVzZWQuIFRoZSBvbmx5IGlzc3VlIHRoZW4sIGlzIGlmIHRo ZSBzZXJ2ZXIgc3RvcHMgc3VwcG9ydGluZw0KIGEgcGFydGljdWxhciB2ZXJzaW9uIGFuZCB0aGVu IHlvdSB0cnkgdG8gcmVjb25uZWN0LiBFaXRoZXIgd2F5LCBhIHNlcnZlciBtaWdodCB3YW50IHRv IGhhdmUgc29tZSB0aHJvdHRsaW5nIGxvZ2ljIGZvciBWTiBwYWNrZXRzIHNlbnQgb3V0OyBidXQg SSBkb27igJl0IHRoaW5rIGl0IHdvdWxkIGJlIHRoZSBlbmQgb2YgdGhlIHdvcmxkIGlmIGl0IGRp ZG7igJl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBOaWNrIEJhbmtzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJ0aW4gRHVrZTxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgNSwgMjAxOCAyOjM5IFBNPGJyPg0KPGI+VG86PC9iPiBJ RVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IExvbmcgSGVh ZGVycyBhbmQgVmVyc2lvbiBOZWdvdGlhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZQ0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5p ZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC10aG9tc29uLXF1aWMtaW52YXJpYW50cy0wMCZhbXA7ZGF0 YT0wMiU3QzAxJTdDbmliYW5rcyU0MG1pY3Jvc29mdC5jb20lN0NkM2EyNDQ5YjkyMzk0OTdlODBh NjA4ZDU1NDhkMWVmZiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY1MDc4ODc0NTYxNzA4OTgmYW1wO3NkYXRhPWwxZ01mSWt4OVFtSmlKdGtIUkFMUGV2YWZO cnU1QTYzSXdpTXNuVWFqODQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmlu dmFyaWFudHMgZHJhZnQ8L2E+IG9ubHkgcmVzZXJ2ZXMgdGhlIDB4ODAgYW5kIDB4NDAgY29kZXBv aW50cyBpbiB0aGUgZmlyc3QgYnl0ZSBvZiB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHRyYW5zcG9ydCBkcmFm dCBzdWdnZXN0cyB0aGF0IG9ubHkgaW5pdGlhbCBwYWNrZXRzIHNob3VsZCB0cmlnZ2VyIHZlcnNp b24gbmVnb3RpYXRpb24uIEhvd2V2ZXIsIHRoZSBJbml0aWFsIFBhY2tldCBieXRlICgweGZmKSBp cyBub3QgaW52YXJpYW50LiBTbyBmb3IgdmVyc2lvbiBuZWdvdGlhdGlvbiB0bw0KIHdvcmsgYXQg YWxsLCBzZXJ2ZXJzIG11c3Qgc2VuZCBWTiBwYWNrZXRzIGZvciA8Yj5hbnk8L2I+Jm5ic3A7bG9u ZyBoZWFkZXIgdHlwZSB3aGVyZSB0aGUgdmVyc2lvbiBpcyB1bnN1cHBvcnRlZCAtLSBvdGhlcndp c2UsIFFVSUN2MiBtaWdodCBzZWxlY3QgMHhlMyBhcyB0aGUgSW5pdGlhbCBQYWNrZXQgYW5kIHYx IHNlcnZlcnMgd291bGQgaWdub3JlIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gdGhlIG90aGVyIGhhbmQsIGluIDBSVFQgY2Fz ZXMgdGhpcyBtaWdodCBjcmVhdGUgYSBzdG9ybSBvZiBWTiBwYWNrZXRzIGlmIHRoZSB2ZXJzaW9u IGlzIHdyb25nLiBJIHN1cHBvc2UgY2xpZW50cyBhcmUgcHJvYmFibHkgbm90IHNlbmRpbmcgMFJU VCBpZiB0aGV5IGRvbid0IGtub3cgdGhlIHN1cHBvcnRlZA0KIHZlcnNpb25zLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QW0gSSB0aGlu a2luZyBhYm91dCB0aGlzIGNvcnJlY3RseT8gSWYgc28sIEknbSBoYXBweSB0byBmaWxlIGFuIGlz c3VlLCBhbmQgYSBQUiBpZiB3ZSBhZ3JlZSB0aGF0IHRoZSBjb3JyZWN0IHNvbHV0aW9uIGlzIHRv IHJlcGx5IHdpdGggVk4gdG8gYWxsIGxvbmcgaGVhZGVycyB3aXRoIHVuc3VwcG9ydGVkIHZlcnNp b25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+LSBNYXJ0aW4gRHVrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MWHPR08MB2432DF994B55055CA2418D97DA1C0MWHPR08MB2432namp_-- From nobody Sun Jan 7 15:19:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED284124BE8 for ; Sun, 7 Jan 2018 15:19:06 -0800 (PST) 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 VHkRj8iBMP_5 for ; Sun, 7 Jan 2018 15:19:05 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 85675124B17 for ; Sun, 7 Jan 2018 15:19:05 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id q39so7948377otb.8 for ; Sun, 07 Jan 2018 15:19:05 -0800 (PST) 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=fjpMdD8GwQROokqlKG1FKOxGYNmJ8J6osfdGjZE8ldI=; b=CwFlNTCvtdvsXLvTZw0DUBm2uyramo3exluRNjN0ddxyBHVxfIhd/hTdrKO4fAcPCh JEJttv8VD//mbwkyZ9LCvNbObYiX2pKYQfdUw4kPHYVJ7/vjXZXjQH7aSRLUzQcAjatl Bk23smjsZY5T8y+XPnzXu2SmlGvYeiVR+qcQiOiBRR+pOUtzkXk1ldrqs0BQiom8+Vj9 Qiwv9pzp7Dc6xBXehSRPzygNyXX+KFoQcW/lDQM3T052ow5+ZH7HFuEKbm/sGsfi9wbm FCBMVe28y4XzfNx4WT1/RhUMI1hsm5/Lvb/SwXERnPENB+r5pDlHx//d7zvG9F5I2/jP wP3w== 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=fjpMdD8GwQROokqlKG1FKOxGYNmJ8J6osfdGjZE8ldI=; b=gK55H6UhPT5YFoet/TltvIqr5WC4ElnzyDDmiBaMBbNLLUPyMnhBhZqK0n1+Smkyj1 HpmGsv4G0tRDIJHGXbz1VsHLBnIFT0RcEP96dQs/B5fMiemsqFHFvYvfbzNtjPCn/O+D UHnMcEOo9Wg3wVryc/stX4TvqquahQqYP37JfQQJEUPu7qWibcWeIYK922JIHda8aWCV HFoVmLNG/Ed8ynT6Zst+/azci06kzPQGPysOWH5JhpzcI182f6O4VOE85H8DnupQ5FP7 qW9tXqZ8pVgRf0SuItdf22T4a5KqbtJiZvBenUZ4eAtShAvaSYDYa6nLzVBIyUhNllO4 MF6Q== X-Gm-Message-State: AKwxytc89sCyDn+72HBNxY2imbN+xVIoMmqg+ksgzGIGEL4lGWrr5+X3 9dLUE4QGciRZD3pqTMnk3wugAQW1huBn3fgCUvA= X-Google-Smtp-Source: ACJfBou/P6RNZJeZKQhpcBahFeF1Si0vzX97KYwjsTTblxRED6vSXVwHTC58svXXi5y75ZPfs3GO2pTvVhlFOaxocuk= X-Received: by 10.157.40.134 with SMTP id s6mr6008768ota.133.1515367144778; Sun, 07 Jan 2018 15:19:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Sun, 7 Jan 2018 15:19:04 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 8 Jan 2018 10:19:04 +1100 Message-ID: Subject: Re: Long Headers and Version Negotiation To: Nick Banks Cc: Martin Duke , 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: Sun, 07 Jan 2018 23:19:07 -0000 We had a similar concern with TLS, in that a server that advertises 0-RTT support could later decide to disable TLS 1.3. That leads to a similar sort of issue: 0-RTT data hitting a server that doesn't know how to handle it. We concluded that advertising 0-RTT was a commitment to support that configuration until the 0-RTT ticket expired (at least to the extent that the server wouldn't choke on 0-RTT). Mike's right in saying that QUIC is somewhat better able to cope. Not using ordered delivery means that this turns into a flood of version negotiation packets rather than anything immediately fatal. That said, we could recommend that servers treat 0-RTT-enabled tickets as a commitment to support a given version. That effectively means disabling 0-RTT on versions that you plan to decommission. Maybe that's a manageability consideration more than a protocol one. On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks wrote: > If you are sending 0-RTT packets then you have connected to this server > before and should be able to remember the version you used. The only issu= e > then, is if the server stops supporting a particular version and then you > try to reconnect. Either way, a server might want to have some throttling > logic for VN packets sent out; but I don=E2=80=99t think it would be the = end of the > world if it didn=E2=80=99t. > > > > - Nick Banks > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke > Sent: Friday, January 5, 2018 2:39 PM > To: IETF QUIC WG > Subject: Long Headers and Version Negotiation > > > > The invariants draft only reserves the 0x80 and 0x40 codepoints in the fi= rst > byte of the packet. > > > > The transport draft suggests that only initial packets should trigger > version negotiation. However, the Initial Packet byte (0xff) is not > invariant. So for version negotiation to work at all, servers must send V= N > packets for any long header type where the version is unsupported -- > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 servers > would ignore it. > > > > On the other hand, in 0RTT cases this might create a storm of VN packets = if > the version is wrong. I suppose clients are probably not sending 0RTT if > they don't know the supported versions. > > > > Am I thinking about this correctly? If so, I'm happy to file an issue, an= d a > PR if we agree that the correct solution is to reply with VN to all long > headers with unsupported versions. > > > > - Martin Duke From nobody Sun Jan 7 18:58:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545F2126CF9 for ; Sun, 7 Jan 2018 18:58:45 -0800 (PST) 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 xakqshXg6QdQ for ; Sun, 7 Jan 2018 18:58:43 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 BDAE61200C1 for ; Sun, 7 Jan 2018 18:58:42 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id p17so9293527wre.7 for ; Sun, 07 Jan 2018 18:58:42 -0800 (PST) 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=p0JcbxHcNtRyZ9jvVqUE77mC8xhPtYyi2Ow+p+jNXHc=; b=bAntdkYYFQs5DKYBAb/4c4JT9CmJjMkFe77uaQlrY3ZYE/YPYsy1id6hyNNxWoIElj Fa6PYAgyM5nuoP+TJFAyRdku/QPEK77JlhHmOkGWzQhhXGwQq3fm/GKQdwW8s5O6WVRF 06tqputUide2G+2fQ4KoFNxU3WJgd5Uw2DGFa2txNq5vmB/oMlI/uWpZPZ09NLarEwmU E+RhAmpIMBOHly22M2Lz1ER8zBT0viudrJW9pQsnTFK5uSaDpjjxn224xt9aOP8rRxY5 oc/l5gWv/n2sMLC09aJw2Lkcv89gm5cCvIelGxL4JDSNSB8kV3NgeZl4AoBfiswdzoGU unXg== 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=p0JcbxHcNtRyZ9jvVqUE77mC8xhPtYyi2Ow+p+jNXHc=; b=VxRYiMze9FJHsEkMsWJoCsIw3dP2znbFKtS+hh9sFBbZrBB0/WF5CtKGsILoReelSa OjqBmR6bWf3PR+m3nIHOTQmOkIrbJTOonOCalIr7OOz3+XtuB7eifw2ptmRP8JibPnqv 4xYN9e1IlErp7riOpRoSnXKHpoi5zEnxFpYj4bbcY82/POKVf7aIz6vFRlhUuaHCAg7e lM9fK6wxqQKEDcP2gxmMLx7mmrx/e8X/y8L0gG+G0282CaXE6Aw5q2J5hv2OjUMdOLnc /dKnjKjRzMHj2WQxKMuw1lLI97SGNZuOzqQ7ffznyXFwHFe65FHICsKlxzHe/LcfyGYB 0PkA== X-Gm-Message-State: AKGB3mI+1ijSdlvmUtAmFzW5eDcuclb6b9WoMOhMzllc6mo7FGHC6M9I yb4KSV6jgBY5GU+ATNq1dULLprca/dWjiPHhNPU= X-Google-Smtp-Source: ACJfBotjKihrs/Co8uJKKDhAws7TXpD9Z4z14b92a7icoiJPWl5Jng+uZiwHboJs9KyDliUZDjcP25fA6evM2vyQZ+I= X-Received: by 10.223.150.213 with SMTP id u79mr2180554wrb.137.1515380321246; Sun, 07 Jan 2018 18:58:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Sun, 7 Jan 2018 18:58:40 -0800 (PST) Received: by 10.223.128.1 with HTTP; Sun, 7 Jan 2018 18:58:40 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Sun, 7 Jan 2018 18:58:40 -0800 Message-ID: Subject: Re: Long Headers and Version Negotiation To: Martin Thomson Cc: Nick Banks , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045f54d2bf654c05623af96c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Jan 2018 02:58:45 -0000 --f403045f54d2bf654c05623af96c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not all that concerned about the VN storm. I'll file an issue, and would like input on "treat all long headers as initials" vs. "Make 0xff invariant". On Jan 7, 2018 3:19 PM, "Martin Thomson" wrote: > We had a similar concern with TLS, in that a server that advertises > 0-RTT support could later decide to disable TLS 1.3. That leads to a > similar sort of issue: 0-RTT data hitting a server that doesn't know > how to handle it. We concluded that advertising 0-RTT was a > commitment to support that configuration until the 0-RTT ticket > expired (at least to the extent that the server wouldn't choke on > 0-RTT). > > Mike's right in saying that QUIC is somewhat better able to cope. Not > using ordered delivery means that this turns into a flood of version > negotiation packets rather than anything immediately fatal. That > said, we could recommend that servers treat 0-RTT-enabled tickets as a > commitment to support a given version. That effectively means > disabling 0-RTT on versions that you plan to decommission. Maybe > that's a manageability consideration more than a protocol one. > > On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks wrote: > > If you are sending 0-RTT packets then you have connected to this server > > before and should be able to remember the version you used. The only > issue > > then, is if the server stops supporting a particular version and then y= ou > > try to reconnect. Either way, a server might want to have some throttli= ng > > logic for VN packets sent out; but I don=E2=80=99t think it would be th= e end of > the > > world if it didn=E2=80=99t. > > > > > > > > - Nick Banks > > > > > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke > > Sent: Friday, January 5, 2018 2:39 PM > > To: IETF QUIC WG > > Subject: Long Headers and Version Negotiation > > > > > > > > The invariants draft only reserves the 0x80 and 0x40 codepoints in the > first > > byte of the packet. > > > > > > > > The transport draft suggests that only initial packets should trigger > > version negotiation. However, the Initial Packet byte (0xff) is not > > invariant. So for version negotiation to work at all, servers must send > VN > > packets for any long header type where the version is unsupported -- > > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 server= s > > would ignore it. > > > > > > > > On the other hand, in 0RTT cases this might create a storm of VN packet= s > if > > the version is wrong. I suppose clients are probably not sending 0RTT i= f > > they don't know the supported versions. > > > > > > > > Am I thinking about this correctly? If so, I'm happy to file an issue, > and a > > PR if we agree that the correct solution is to reply with VN to all lon= g > > headers with unsupported versions. > > > > > > > > - Martin Duke > --f403045f54d2bf654c05623af96c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not all that concerned about the VN storm. I'll = file an issue, and would like input on "treat all long headers as init= ials" vs. "Make 0xff invariant".

On Jan 7, 2018 3:19 PM, "Martin Th= omson" <martin.thomson@= gmail.com> wrote:
We had a similar concern with TLS, in that a server that advertises 0-RTT support could later decide to disable TLS 1.3.=C2=A0 That leads to a<= br> similar sort of issue: 0-RTT data hitting a server that doesn't know how to handle it.=C2=A0 We concluded that advertising 0-RTT was a
commitment to support that configuration until the 0-RTT ticket
expired (at least to the extent that the server wouldn't choke on
0-RTT).

Mike's right in saying that QUIC is somewhat better able to cope.=C2=A0= Not
using ordered delivery means that this turns into a flood of version
negotiation packets rather than anything immediately fatal.=C2=A0 That
said, we could recommend that servers treat 0-RTT-enabled tickets as a
commitment to support a given version.=C2=A0 That effectively means
disabling 0-RTT on versions that you plan to decommission.=C2=A0 Maybe
that's a manageability consideration more than a protocol one.

On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks <nibanks@microsoft.com> wrote:
> If you are sending 0-RTT packets then you have connected to this serve= r
> before and should be able to remember the version you used. The only i= ssue
> then, is if the server stops supporting a particular version and then = you
> try to reconnect. Either way, a server might want to have some throttl= ing
> logic for VN packets sent out; but I don=E2=80=99t think it would be t= he end of the
> world if it didn=E2=80=99t.
>
>
>
> - Nick Banks
>
>
>
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Martin Duke
> Sent: Friday, January 5, 2018 2:39 PM
> To: IETF QUIC WG <quic@ietf.org>
> Subject: Long Headers and Version Negotiation
>
>
>
> The invariants draft only reserves the 0x80 and 0x40 codepoints in the= first
> byte of the packet.
>
>
>
> The transport draft suggests that only initial packets should trigger<= br> > version negotiation. However, the Initial Packet byte (0xff) is not > invariant. So for version negotiation to work at all, servers must sen= d VN
> packets for any long header type where the version is unsupported -- > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 serve= rs
> would ignore it.
>
>
>
> On the other hand, in 0RTT cases this might create a storm of VN packe= ts if
> the version is wrong. I suppose clients are probably not sending 0RTT = if
> they don't know the supported versions.
>
>
>
> Am I thinking about this correctly? If so, I'm happy to file an is= sue, and a
> PR if we agree that the correct solution is to reply with VN to all lo= ng
> headers with unsupported versions.
>
>
>
> - Martin Duke
--f403045f54d2bf654c05623af96c-- From nobody Sun Jan 7 19:12:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841E9126C83 for ; Sun, 7 Jan 2018 19:12:21 -0800 (PST) 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, MIME_QP_LONG_LINE=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 hUkI7uUJ5KAz for ; Sun, 7 Jan 2018 19:12:19 -0800 (PST) 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 EBDAB1200C1 for ; Sun, 7 Jan 2018 19:12:18 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eYNrE-00031f-WA for quic@ietf.org; Mon, 08 Jan 2018 04:12:17 +0100 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 1eYNr7-00073K-6n for quic@ietf.org; Sun, 07 Jan 2018 22:12:13 -0500 Received: (qmail 3459 invoked from network); 8 Jan 2018 03:12:06 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jan 2018 03:12:06 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-3B06F8BB-06AE-4698-BDB3-C84CD1ABC77D Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sun, 7 Jan 2018 17:12:02 -1000 Cc: Martin Thomson , Nick Banks , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: References: To: Martin Duke Subject: Re: Long Headers and Version Negotiation X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ktM4Bl8WbbX1qK5NOS07wUXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fstaMFyb7j8NwtrhJTPSNsRB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b tyezQf64yyfdoQUaciQGLMoHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFCFnwGKkv+DIQGXVP+Qhqh8ibYT4C2qF2lnc18bVJn66D gV2QUMK+k1EjVCaSYktzReNB51/o9aOmbBfZE6T1DDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTcmOtKpb1oAulsHm1CrhdOljI1dRH6f16eQCtvwPkeoyl2uO1aNahU3xgdP6yeyunl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 03:12:21 -0000 --Apple-Mail-3B06F8BB-06AE-4698-BDB3-C84CD1ABC77D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable About 0xFF invariant -- that was one of the issues we found during the Decem= ber 18 interop. The first byte in the VN packet is unspecified so picoquic w= as setting it to 0xFF. Legit, but somewhat unexpected. Another point about VN storms. Servers can of course implement some kind of p= acing. They should also only send VN in response to packets that are at leas= t 1200 bytes, since CI must be at least that. -- Christian Huitema=20 > On Jan 7, 2018, at 4:58 PM, Martin Duke wrote: >=20 > I am not all that concerned about the VN storm. I'll file an issue, and wo= uld like input on "treat all long headers as initials" vs. "Make 0xff invari= ant". >=20 >> On Jan 7, 2018 3:19 PM, "Martin Thomson" wrote= : >> We had a similar concern with TLS, in that a server that advertises >> 0-RTT support could later decide to disable TLS 1.3. That leads to a >> similar sort of issue: 0-RTT data hitting a server that doesn't know >> how to handle it. We concluded that advertising 0-RTT was a >> commitment to support that configuration until the 0-RTT ticket >> expired (at least to the extent that the server wouldn't choke on >> 0-RTT). >>=20 >> Mike's right in saying that QUIC is somewhat better able to cope. Not >> using ordered delivery means that this turns into a flood of version >> negotiation packets rather than anything immediately fatal. That >> said, we could recommend that servers treat 0-RTT-enabled tickets as a >> commitment to support a given version. That effectively means >> disabling 0-RTT on versions that you plan to decommission. Maybe >> that's a manageability consideration more than a protocol one. >>=20 >> On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks wrote:= >> > If you are sending 0-RTT packets then you have connected to this server= >> > before and should be able to remember the version you used. The only is= sue >> > then, is if the server stops supporting a particular version and then y= ou >> > try to reconnect. Either way, a server might want to have some throttli= ng >> > logic for VN packets sent out; but I don=E2=80=99t think it would be th= e end of the >> > world if it didn=E2=80=99t. >> > >> > >> > >> > - Nick Banks >> > >> > >> > >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke >> > Sent: Friday, January 5, 2018 2:39 PM >> > To: IETF QUIC WG >> > Subject: Long Headers and Version Negotiation >> > >> > >> > >> > The invariants draft only reserves the 0x80 and 0x40 codepoints in the f= irst >> > byte of the packet. >> > >> > >> > >> > The transport draft suggests that only initial packets should trigger >> > version negotiation. However, the Initial Packet byte (0xff) is not >> > invariant. So for version negotiation to work at all, servers must send= VN >> > packets for any long header type where the version is unsupported -- >> > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 server= s >> > would ignore it. >> > >> > >> > >> > On the other hand, in 0RTT cases this might create a storm of VN packet= s if >> > the version is wrong. I suppose clients are probably not sending 0RTT i= f >> > they don't know the supported versions. >> > >> > >> > >> > Am I thinking about this correctly? If so, I'm happy to file an issue, a= nd a >> > PR if we agree that the correct solution is to reply with VN to all lon= g >> > headers with unsupported versions. >> > >> > >> > >> > - Martin Duke --Apple-Mail-3B06F8BB-06AE-4698-BDB3-C84CD1ABC77D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable About 0xFF invariant -- that was one of the= issues we found during the December 18 interop. The first byte in the VN pa= cket is unspecified so picoquic was setting it to 0xFF. Legit, but somewhat u= nexpected.

Another point about VN storms. Servers can of c= ourse implement some kind of pacing. They should also only send VN in respon= se to packets that are at least 1200 bytes, since CI must be at least that.<= br>
-- Christian Huitema 
I am not all that concerned about the= VN storm. I'll file an issue, and would like input on "treat all long heade= rs as initials" vs. "Make 0xff invariant".
<= br>
On Jan 7, 2018 3:19 PM, "Martin Thomson" <<= a href=3D"mailto:martin.thomson@gmail.com">martin.thomson@gmail.com> w= rote:
We had a similar= concern with TLS, in that a server that advertises
0-RTT support could later decide to disable TLS 1.3.  That leads to a similar sort of issue: 0-RTT data hitting a server that doesn't know
how to handle it.  We concluded that advertising 0-RTT was a
commitment to support that configuration until the 0-RTT ticket
expired (at least to the extent that the server wouldn't choke on
0-RTT).

Mike's right in saying that QUIC is somewhat better able to cope.  Not<= br> using ordered delivery means that this turns into a flood of version
negotiation packets rather than anything immediately fatal.  That
said, we could recommend that servers treat 0-RTT-enabled tickets as a
commitment to support a given version.  That effectively means
disabling 0-RTT on versions that you plan to decommission.  Maybe
that's a manageability consideration more than a protocol one.

On Sat, Jan 6, 2018 at 9:46 AM, Nick Banks <nibanks@microsoft.com> wrote:
> If you are sending 0-RTT packets then you have connected to this server=
> before and should be able to remember the version you used. The only is= sue
> then, is if the server stops supporting a particular version and then y= ou
> try to reconnect. Either way, a server might want to have some throttli= ng
> logic for VN packets sent out; but I don=E2=80=99t think it would be th= e end of the
> world if it didn=E2=80=99t.
>
>
>
> - Nick Banks
>
>
>
> From: QUIC [mailto:quic-bounce= s@ietf.org] On Behalf Of Martin Duke
> Sent: Friday, January 5, 2018 2:39 PM
> To: IETF QUIC WG <quic@ietf.org= >
> Subject: Long Headers and Version Negotiation
>
>
>
> The invariants draft only reserves the 0x80 and 0x40 codepoints in the f= irst
> byte of the packet.
>
>
>
> The transport draft suggests that only initial packets should trigger > version negotiation. However, the Initial Packet byte (0xff) is not
= > invariant. So for version negotiation to work at all, servers must send= VN
> packets for any long header type where the version is unsupported -- > otherwise, QUICv2 might select 0xe3 as the Initial Packet and v1 server= s
> would ignore it.
>
>
>
> On the other hand, in 0RTT cases this might create a storm of VN packet= s if
> the version is wrong. I suppose clients are probably not sending 0RTT i= f
> they don't know the supported versions.
>
>
>
> Am I thinking about this correctly? If so, I'm happy to file an issue, a= nd a
> PR if we agree that the correct solution is to reply with VN to all lon= g
> headers with unsupported versions.
>
>
>
> - Martin Duke
= --Apple-Mail-3B06F8BB-06AE-4698-BDB3-C84CD1ABC77D-- From nobody Sun Jan 7 19:33:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37BF126DC2 for ; Sun, 7 Jan 2018 19:33:02 -0800 (PST) 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 6E31-i6pd4ll for ; Sun, 7 Jan 2018 19:33:01 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 145141201FA for ; Sun, 7 Jan 2018 19:33:01 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id y141so163579oia.0 for ; Sun, 07 Jan 2018 19:33:01 -0800 (PST) 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=YO+neVuDnwSPMEe2pS8l8xH2nDKVCD01SvT6wlRlYIo=; b=ekBpAcyB4BZU1KrvBm8cWjBNITq484r88c36X6+pR4QXyl6JV9Dn1UCr/ZDKJx8mSE Z6JDm/aG+Kw+pp4GR6YDpG/W4+yT0czP4X+I3fbR08dWjBwGCRCAgA+KsZmap9hBtXls 96tIz2evpoO052Iq1CfuQw6G/9r/IQThC7Q90dHexCJD8yjRDyNORs6mAlZlFajpsyqq 2r8kivyYWq2Zv8je3m2gh3GqGDJ3gsizggagZ0fQOKtxTGiGfjih3eAQdVLjYwyZCg68 jhJwvJ3V/sJld93RCHIyCFENiHs67wpC45MFETE4xUJI3uewcpjZIXnoe9QU3oTPpre1 YXWw== 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=YO+neVuDnwSPMEe2pS8l8xH2nDKVCD01SvT6wlRlYIo=; b=jurEMkm1S7XQcywYnNP5HKYlNiVfoEVftNHBPs9akpmsX4pY6eAqQiPo9IqAVFA9pt FqVbEo+wwJ1/vh2d38PeTS0nvFTZ7KJBebh8wnLMltCGseYyxf7b2+RiEP97i+rNb71j qQxGp3UJBCSq1Co8lDH28WR6nZSp7Jt2+Ay97Mn14mz4GHNKGYc/vhLBXcN8ndhaMAy7 SjJhRLOuqbLrdpqZjr8VLl1qrI9+6fmFeVGRNRevUbIXxbvf/FzU3KM+Skqqcm0YKYrw rXQ/UEZtQiwDfZ1SOE73xLJQZRUdSFBX1E6Q9MDFb8WyYHkeq80wC3H1aexHQNnSZ3/Y bZow== X-Gm-Message-State: AKGB3mIV+NwvCaSZhWts2/yak1V7VZMW/8LfLH+91x+5Y7FIUNi0NvoO JUL3fhO/+rQrZB8VKXN4uNTeahjxd4X/dmJUShc= X-Google-Smtp-Source: ACJfBouhuEL733IWI/iH3oWy85BXoFzujB+zhWhZRQodLZPEwCPids1Mf2JQ3HlrTx5oe+SPc1MqWIy1jXPQMfbHlIg= X-Received: by 10.202.234.214 with SMTP id i205mr5581725oih.84.1515382380329; Sun, 07 Jan 2018 19:33:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Sun, 7 Jan 2018 19:32:59 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 8 Jan 2018 14:32:59 +1100 Message-ID: Subject: Re: Long Headers and Version Negotiation To: Christian Huitema Cc: Martin Duke , Nick Banks , 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: Mon, 08 Jan 2018 03:33:02 -0000 On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema wro= te: > About 0xFF invariant -- that was one of the issues we found during the > December 18 interop. The first byte in the VN packet is unspecified so > picoquic was setting it to 0xFF. Legit, but somewhat unexpected. That's why we have these interop things. The question is whether it is surprising enough to warrant a change. > Another point about VN storms. Servers can of course implement some kind = of > pacing. They should also only send VN in response to packets that are at > least 1200 bytes, since CI must be at least that. >From Section 7.1: For servers, packets that aren=E2=80=99t associated with a connection potentially create a new connection. However, only packets that use the long packet header and that are at least the minimum size defined for the protocol version can be initial packets. From nobody Sun Jan 7 19:50:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E07126D74 for ; Sun, 7 Jan 2018 19:50:04 -0800 (PST) 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 bTrJfMwugcGt for ; Sun, 7 Jan 2018 19:50:02 -0800 (PST) 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 3EB541200C1 for ; Sun, 7 Jan 2018 19:50:02 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eYORk-0002e7-3P for quic@ietf.org; Mon, 08 Jan 2018 04:50:00 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eYORc-0007F2-3V for quic@ietf.org; Sun, 07 Jan 2018 22:49:56 -0500 Received: (qmail 29015 invoked from network); 8 Jan 2018 03:49:51 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Jan 2018 03:49:51 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: Date: Sun, 7 Jan 2018 17:49:48 -1000 Cc: Martin Duke , Nick Banks , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson Subject: Re: Long Headers and Version Negotiation X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5l7jLt63W30jHr4DCwWF0VYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu9ZH5f4mJwEsL8wCNEtMkDB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31WoCGUWNgo50bBZN3FfqI2VItAPyqRyV95ZNrHd7vkN RtYO6A0DBVvo3Pds5mJVTPXh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GYnRqIO2TPU1F0bSG6T2DJZnHEeB4hpRrmo/duzUUp/JM XkWanlHHapN24HIulP+VM6pft8V9tVB0HhUp891ZxXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+G45OmBNdsUklj47JM2Zh1oj2lB9TLiDMfXuvSrucRXry8B6sEcpHNQcjlAOoToGvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 03:50:05 -0000 > On Jan 7, 2018, at 5:32 PM, Martin Thomson wrot= e: >=20 >> On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema w= rote: >> About 0xFF invariant -- that was one of the issues we found during the >> December 18 interop. The first byte in the VN packet is unspecified so >> picoquic was setting it to 0xFF. Legit, but somewhat unexpected. >=20 > That's why we have these interop things. The question is whether it > is surprising enough to warrant a change. Eh eh... >=20 >> Another point about VN storms. Servers can of course implement some kind o= f >> pacing. They should also only send VN in response to packets that are at >> least 1200 bytes, since CI must be at least that. >=20 > =46rom Section 7.1: >=20 > For servers, packets that aren=E2=80=99t associated with a connection > potentially create a new connection. However, only packets that use > the long packet header and that are at least the minimum size defined > for the protocol version can be initial packets. So if we just suggested that 0-RTT packets should be shorter than the minimu= m size, we would be covered.= From nobody Sun Jan 7 19:57:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880AE126D74 for ; Sun, 7 Jan 2018 19:57:16 -0800 (PST) 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 inxW4qtU6Usl for ; Sun, 7 Jan 2018 19:57:14 -0800 (PST) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A7971200C1 for ; Sun, 7 Jan 2018 19:57:14 -0800 (PST) Received: by mail-wr0-x22b.google.com with SMTP id 36so9350389wrh.1 for ; Sun, 07 Jan 2018 19:57:14 -0800 (PST) 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=Ldj5bJ+c8w9QS99pgYE4SBEQKvU1aw29qWzXKfHdZQQ=; b=igt4ZUr905BqQNmknTqICjEU93RL0FjA772GSCXv1Tk76XN8VG+Tc4cdAVQzSSbynY g0a2crS3yExA3QEqeDIQJJTdZdbQH2ZGbDwy/8++2joBNc4uG3U4A7vfQd4kX4vkgF1T jGih4d217zUc9/bzK6UN6K7djZi9gGpnj0P8xSH4PAxu2ltsdUdRRLyh9zc2jmCrJTor SQd5PtXxWGV2nEUfZwPN23xPhdMSeyHVS4Ubi2uwtAGzbA969zvipzqNmXCFcXhQPdHl GdMXKkvcD6dGhvFbHzFG6jnKa9b1SH6SEsF/U2RAH9smoS7lUyy1W+KLlxAy3bZrshJW /Hgg== 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=Ldj5bJ+c8w9QS99pgYE4SBEQKvU1aw29qWzXKfHdZQQ=; b=sJg4xC2+OteNxO+DBubCtOYs7QFvfBMfn8SIOU8CcS3OgYSMpRbDSHiWPGk6A5vwoW Z2I5oRqIJzDBytxaIkLf5stQONYQ5j/NIadgee7oLc2Z/hr8oAbAKHmCvzA4W3R+7JIT l0J3fzJmy4AoUKZl2fuCUvOs3Oqiv6OhPs3UuOfGildKIudD1Fi6Vi3Z2f2aIwhxKOpZ 7roHVRKMjWYn3fyLYrRHZwD4sDLfXm1i56d7aQKWUBHxHyteGx1vDd/FkrMAOzS+xZPh Tf7PX58/FZx2UpLlilbo8rH6+f6ob04MtvkQmNlUip6wswLUKOTTvOF4ZpuNhY2ZNxEz ll1Q== X-Gm-Message-State: AKGB3mKzQj8A+m2xU0UFw8QvwxBytrYbLaCJPXmXycYGa6xIMIPJX4jM SYB1HMZsgbg0rW//Cgyhhjz5JqAXIUQSKbrFWUE= X-Google-Smtp-Source: ACJfBovj8PRCbgmo9GklkXl14G+p9qYXS+C/5YRukEx3hbLb7VoCzjM++tRo9yTEK+TnuJEJFPQo8rD6GFUs8bQi/u8= X-Received: by 10.223.147.71 with SMTP id 65mr10088168wro.155.1515383832751; Sun, 07 Jan 2018 19:57:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Sun, 7 Jan 2018 19:57:12 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Sun, 7 Jan 2018 19:57:12 -0800 Message-ID: Subject: Re: Long Headers and Version Negotiation To: Christian Huitema Cc: Martin Thomson , Nick Banks , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0d29100cb30105623bcb50" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Jan 2018 03:57:16 -0000 --94eb2c0d29100cb30105623bcb50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I filed issue 1038 https://github.com/quicwg/base-drafts/issues/1038 On Sun, Jan 7, 2018 at 7:49 PM, Christian Huitema wrote: > > > > On Jan 7, 2018, at 5:32 PM, Martin Thomson > wrote: > > > >> On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema > wrote: > >> About 0xFF invariant -- that was one of the issues we found during the > >> December 18 interop. The first byte in the VN packet is unspecified so > >> picoquic was setting it to 0xFF. Legit, but somewhat unexpected. > > > > That's why we have these interop things. The question is whether it > > is surprising enough to warrant a change. > > Eh eh... > > > >> Another point about VN storms. Servers can of course implement some > kind of > >> pacing. They should also only send VN in response to packets that are = at > >> least 1200 bytes, since CI must be at least that. > > > > From Section 7.1: > > > > For servers, packets that aren=E2=80=99t associated with a connection > > potentially create a new connection. However, only packets that use > > the long packet header and that are at least the minimum size defined > > for the protocol version can be initial packets. > > So if we just suggested that 0-RTT packets should be shorter than the > minimum size, we would be covered. > --94eb2c0d29100cb30105623bcb50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= div class=3D"gmail_quote">On Sun, Jan 7, 2018 at 7:49 PM, Christian Huitema= <huitema@huitema.net> wrote:


> On Jan 7, 2018, at 5:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On Mon, Jan 8, 2018 at 2:12 PM, Christian Huitema <huitema@huitema.net> wrote:
>> About 0xFF invariant -- that was one of the issues we found during= the
>> December 18 interop. The first byte in the VN packet is unspecifie= d so
>> picoquic was setting it to 0xFF. Legit, but somewhat unexpected. >
> That's why we have these interop things.=C2=A0 The question is whe= ther it
> is surprising enough to warrant a change.

Eh eh...
>
>> Another point about VN storms. Servers can of course implement som= e kind of
>> pacing. They should also only send VN in response to packets that = are at
>> least 1200 bytes, since CI must be at least that.
>
> From Section 7.1:
>
> For servers, packets that aren=E2=80=99t associated with a connection<= br> > potentially create a new connection. However, only packets that use > the long packet header and that are at least the minimum size defined<= br> > for the protocol version can be initial packets.

So if we just suggested that 0-RTT packets should be shorter than th= e minimum size, we would be covered.

--94eb2c0d29100cb30105623bcb50-- From nobody Mon Jan 8 11:20:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF87A124B18; Mon, 8 Jan 2018 11:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 RQhFAaK9X3yM; Mon, 8 Jan 2018 11:20:24 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3FE126D46; Mon, 8 Jan 2018 11:20:24 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 3A2571CAE41; Mon, 8 Jan 2018 11:19:49 -0800 (PST) Received: from mail-it0-f49.google.com (mail-it0-f49.google.com [209.85.214.49]) by c8a.amsl.com (Postfix) with ESMTPSA id 188011CAE31; Mon, 8 Jan 2018 11:19:49 -0800 (PST) Received: by mail-it0-f49.google.com with SMTP id c16so8720082itc.5; Mon, 08 Jan 2018 11:20:24 -0800 (PST) X-Gm-Message-State: AKGB3mLXDdlyVNUkXHLzouNeUgjG3tL0fmFdMzGK9u/Jy7+vmiLc89QE x1O351Ql87YYuHPVZrjdDuN6Edi9Swe+cTS1msY= X-Google-Smtp-Source: ACJfBovKDudIQNyR3pc6czZ6Do+PrVSFJEzRbHmr4nqb/slUpnbL3yoqR4SK/bKdpIEdFSOVUG12LIc8bnn1gc5VjKw= X-Received: by 10.36.172.76 with SMTP id m12mr12421849iti.110.1515439224089; Mon, 08 Jan 2018 11:20:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.111.24 with HTTP; Mon, 8 Jan 2018 11:20:03 -0800 (PST) From: Glen Date: Mon, 8 Jan 2018 11:20:03 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: The QUIC list is not broken To: quic@ietf.org, tools-discuss@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1fcb40a1735c056248b05e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Jan 2018 19:20:26 -0000 --94eb2c1fcb40a1735c056248b05e Content-Type: text/plain; charset="UTF-8" Dear QUIC subscribers - The tools team and I are working on some improvements to the mail systems on the IETF servers. During the course of testing some improvements, an old email message accidentally got replayed through the list, and was sent to many of you. We apologize for the noise, the list is not broken, mail is not delayed, this was simply something working much more quickly than we expected it to. Thank you for your patience as we continue to work on improvements to the system. We hope no more messages will go out... but if another does, there is no need to panic! As always, any questions, let me know. Glen Glen Barney IT Director AMS (IETF Secretariat) --94eb2c1fcb40a1735c056248b05e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear QUIC subscrib= ers -

The tools team and I are working on some improvements to= the mail systems on the IETF servers.=C2=A0 During the course of testing s= ome improvements, an old email message accidentally got replayed through th= e list, and was sent to many of you.

We apologize for the nois= e, the list is not broken, mail is not delayed, this was simply something w= orking much more quickly than we expected it to.

Thank you for= your patience as we continue to work on improvements to the system.=C2=A0 = We hope no more messages will go out... but if another does, there is no ne= ed to panic!

As always, any questions, let me know.

Glen
Glen Barney
IT Director
AMS (IETF Secret= ariat)
--94eb2c1fcb40a1735c056248b05e-- From nobody Mon Jan 8 22:36:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE7F12025C for ; Mon, 8 Jan 2018 22:36:26 -0800 (PST) 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 QOnWv-hOKpXn for ; Mon, 8 Jan 2018 22:36:24 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 89F9A126C22 for ; Mon, 8 Jan 2018 22:36:24 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id p16so7868376otf.1 for ; Mon, 08 Jan 2018 22:36:24 -0800 (PST) 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=7qiYTbOupvzAXRiKqoxrKu10JfkKTbYgMmhidGMUb6g=; b=of2F+DQOgY4T6TLuQ/9g1PeGbz91OBgqvCnghwW4yFZczNSJHBK5KrSh148kbnZMOz vUGoCaUhoyitpdpb2NSnsOV+zAd+vvbCbH37t0aj9Zcexl8JcXR3tViA/nmhgv9eY7tH e1oaoEoMfY7ZHg/8dq8YT7gzxvCqfT/wNqHV27LQ4rlOh3aY2+umt2vCW+xZOAuclRI7 na0a1NjLBW1qAV341ioBjCjcsDPIIeEv2yICWwTP/4AqYW0d1YZJR+9zYhD8WFQqd9Ct qEZrXkkoj1HUMtl2LakbKJejF13eS7j7NO2EbOLRy52DKoLusNCgcDqgAbh9S0GvEwy4 lqpw== 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=7qiYTbOupvzAXRiKqoxrKu10JfkKTbYgMmhidGMUb6g=; b=FYPi/UBxWDFij2Age17o1V4U4dxn7AQj4GQ2MymVnU8dfoj3/6gEtlqMi+OQXKKgQl Mv34TmL9wQVr50uCIXYWzfJMGVeamCB0DHs44o4svr5K0F3ksaFPa4mTz7HehxzeQoZq GkLfahndmrPDCu93KdT8apLqcsT37NyBoJBF5vpGLcXvyInAayHt1akX0CNzQhCFv+PT CIf1yO6BiuA2gb33Nkw94rACXYXr15VU3DYGzOt1BCABtHpye9m/5p862xOvzJWUtJMv iLNnGciE9N/zUJagkXemVBHn9xp91jg/tL+/X0s58l5tgRPDmRfvJoZSAr9A6GkBPGVK rSbQ== X-Gm-Message-State: AKwxytdzKKMtqXA1duRYdEmRW80CyC5NQkGfHvQV1UZ7fj0rzKz5+RjH RrbFOSSeNZMkxINNYwWCc2rZ/c2i7ZsbaK5O3cCRr+RX X-Google-Smtp-Source: ACJfBov6YgCzKcu/EZRm0pR0GJDcmfaaYYIuqFSGFeuAh86rkBDCQXcGXNFiPhuzE5knxW3h89FPx+LrfkUNh/h7mJA= X-Received: by 10.157.85.233 with SMTP id z38mr8550559oti.16.1515479783589; Mon, 08 Jan 2018 22:36:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Mon, 8 Jan 2018 22:36:21 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 Jan 2018 17:36:21 +1100 Message-ID: Subject: Re: Removing packet number gaps 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, 09 Jan 2018 06:36:26 -0000 PR here: https://github.com/quicwg/base-drafts/pull/1043 On Tue, Jan 2, 2018 at 12:57 PM, Martin Thomson wrote: > There are number of problems with packet number gaps that I think we > need to address. Most are minor. For instance, the initial packet > number is not close to zero, which inflates the size of ACK frames > from the very beginning of a connection. > > However, Christian just identified one that I think makes this more > important to address: when using a new connection ID, the gap is the > same size on both client and server. This makes flows linkable. The > gaps between the last packet on the old flow and the first packet on > the new flow can be calculated in both directions. Flows can be > linked by finding flows where client-to-server packets have the same > (or very close) gaps as server-to-client packets. > > With a few small tweaks to the current design, I think that we get a > much better solution. Here is what I propose: > > Firstly, packet numbers start at zero and always increase > monotonically, with no gaps. A side benefit of this is that the first > ACK frame will have a small encoding for largest_acknowledged (1 octet > rather than 8 in most cases). > > Packet numbers are never encoded directly onto the wire, they are > XORed with a masking value. This value will change for different > packet protection keys, and for different connection IDs. Client and > server will use different values so that gaps are hard to detect. > > Thus, we will have a third key derivation: > > key = QHKDF-Expand(S, "key", key_length) > iv = QHKDF-Expand(S, "iv", iv_length) > pnmask = QHKDF-Expand(S, "pnmask", 4) > > To make this work seamlessly, I'm proposing a tweak to QHKDF-Expand > that includes the connection ID. For that, the "Context" field that > we currently do not use seems like a good choice. > > This will mean changes to the other uses of QHKDF-Expand: > > * the handshake secret can be changed to be a fixed rather than a > derived value, so that we don't need to use the function (connection > ID will be added during expansion into the separate keys) > > * during a key update, a zero-length or fixed connection ID will need > to be used so that there is no confusion about which connection ID was > in use at the time the update was made (editorially, I'm not certain > how to manage this one, I might just go back to using > HKDF-Expand-Label directly for that) > > Finally, we need to be very clear that even if the connection ID is > omitted, those packets still use the implied connection ID in key > derivation. We will probably want to recommend that endpoints include > a connection ID if they intend to support NEW_CONNECTION_ID or any of > the related functions, at least around the time when a connection ID > change is in place or the recipient of their packets could have > difficulty picking the right keys. This is already a problem of > course, but this change would make it worse. From nobody Tue Jan 9 03:11:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06CB126C83; Tue, 9 Jan 2018 03:11:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GvDZObjPW2Og; Tue, 9 Jan 2018 03:11:39 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF2E1250B8; Tue, 9 Jan 2018 03:11:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,335,1511856000"; d="asc'?scan'208,217";a="235566614" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx144-out.netapp.com with ESMTP; 09 Jan 2018 03:11:37 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 9 Jan 2018 03:11:37 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 9 Jan 2018 03:11:37 -0800 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=WltuNfnOLppHJLSHd58+VJ2PeZvkmJcTo4ML+pdP7qU=; b=Z1iUJHIpN2/eqVyeXPzKr99Ql1oZaEptjMYT9t319JuhQmp2fXd+Stm1bGsRmjWbz1meWaNWfMpMs+y+dVbEKJvuwoHZDXimNQFIMs+N2QnTt1tGfOunr0MDwhs1aLEzk18DbCwVjeXI3inJ4spDGOrGBhxlA8ORCsAQ8SfneRA= 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_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 11:11:35 +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.20.0386.008; Tue, 9 Jan 2018 11:11:35 +0000 From: "Eggert, Lars" To: "Black, David" CC: "tsvwg@ietf.org" , QUIC WG Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Thread-Topic: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Thread-Index: AdN1GcwEk8+6wIkTQ1++dedJ90kdDwUIM6oA Date: Tue, 9 Jan 2018 11:11:35 +0000 Message-ID: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> References: 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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [203.168.52.212] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 7:A7gwB3kbWWJiOrjcsz2crcDIOOb3oEpdip4rJavhVpJ0d68qGNJavXSAH2CXTuieydTdtF9WAFBqmbUr27quUN+ViqE/w0PSngfAUG67cLK8vtG/Lcgg3WNWFxVwnBXLj0jaPedernELKVRqWCpaeL+VbP44lwgTxUyjAOGAnvcJOPjzZGegHXTWAqgfRhhLtO8ZaRmMIQuOmO5k5adW5R1R/uW2zcnhA8OBEHPp3AAbAJzlLahaeZ4BtsLCmt6i x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 73fc2416-1d53-42b2-d2e4-08d55751bf20 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(56004941905204); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231023)(944501075)(6055026)(6041268)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1762; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(366004)(346002)(396003)(39860400002)(24454002)(377424004)(199004)(189003)(54906003)(3660700001)(5660300001)(8936002)(53546011)(106356001)(66066001)(6436002)(50226002)(33656002)(105586002)(229853002)(478600001)(102836004)(14454004)(4001150100001)(68736007)(76176011)(3280700002)(77096006)(6486002)(53936002)(97736004)(6506007)(8676002)(8666007)(81156014)(81166006)(99286004)(7736002)(36756003)(236005)(6246003)(54896002)(6512007)(3846002)(230783001)(6116002)(2950100002)(99936001)(86362001)(2900100001)(2906002)(316002)(25786009)(83716003)(6916009)(57306001)(82746002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: rRIlvmGT2Uzx64nf5bzeQoWUjKdG8g+0K4dpP/685PsF9ANVy7HyzMDF0QgjNURscm1++PNolTourmQykUnwqQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 73fc2416-1d53-42b2-d2e4-08d55751bf20 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 11:11:35.1016 (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, 09 Jan 2018 11:11:41 -0000 --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC Content-Type: multipart/alternative; boundary="Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F" --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, would someone clarify what the intended relationship of the mechanism = described in the document and QUIC is? For example, is the intention = here that QUIC should implement this, is this unrelated, or anything in = between? Asking, because if there is an intended relationship, it would be good = to discuss this sooner rather than later. Thanks, Lars > On 2017-12-15, at 7:27, Black, David wrote: >=20 > I=E2=80=99m tardy in getting to this action item from the TSVWG = meeting in Singapore =E2=80=A6 >=20 > The TSVWG chairs are considering adoption of the draft > "Packetization Layer Path MTU Discovery for Datagram Transports". >=20 > This draft has been discussed at the previous IETF meeting and on the = list, and the chairs are now looking for input from the group to help = inform whether TSVWG should adopt this draft. >=20 > * Please send an email to this list if you would like to see this work = adopted in TSVWG, or you have comments on the suitability for adoption. >=20 > * Please indicate if you are willing to REVIEW such a document during = its development. >=20 > Please send all notes of support/comments to the TSVWG list or the WG = chairs by the date above. >=20 > Best wishes, >=20 > David and Wes. > (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he = is an author of this draft.] > [The time period for this adoption call is longer than usual to allow = for the winter holidays =E2=80=93 may yours be joyous!] >=20 > Abstract >=20 > This document describes a robust method for Path MTU Discovery > (PMTUD) for datagram Packetization layers. The method allows a > Packetization layer (or a datagram application that uses it) to = probe > an network path with progressively larger packets to determine a > maximum packet size. The document describes as an extension to RFC > 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for > IPv4 and IPv6. This provides functionally for datagram transports > that is equivalent to the Packetization layer PMTUD specification = for > TCP, specified in RFC4821. --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

would = someone clarify what the intended relationship of the mechanism = described in the document and QUIC is? For example, is the intention = here that QUIC should implement this,  is this unrelated, or = anything in between?

Asking, because if there is an intended relationship, it = would be good to discuss this sooner rather than later.

Thanks,
Lars

On 2017-12-15, at 7:27, Black, = David <David.Black@dell.com> wrote:

I=E2=80=99m tardy in getting to this action item from the = TSVWG meeting in Singapore =E2=80=A6
 
The TSVWG chairs are considering = adoption of the draft
"Packetization Layer Path MTU Discovery for Datagram = Transports".
 
This draft has been discussed at the previous IETF meeting = and on the list, and the chairs are now looking for input from the group = to help inform whether TSVWG should adopt this draft.
 
* Please = send an email to this list if you would like to see this work adopted in = TSVWG, or you have comments on the suitability for adoption.
 
* Please = indicate if you are willing to REVIEW such a document during its = development.
 
Please send all notes of support/comments to the TSVWG list = or the WG chairs by the date above.
 
Best wishes,
 
David and = Wes.
(TSVWG = Co-Chairs) [Gorry is recused from this adoption decision, as he is an = author of this draft.]
[The time period for this adoption call is longer than usual = to allow for the winter holidays =E2=80=93 may yours be joyous!]
 
Abstract
 
   This document describes a robust method for Path = MTU Discovery
   (PMTUD) for datagram Packetization layers.  = The method allows a
   Packetization layer (or a datagram application = that uses it) to probe
   an network path with progressively larger = packets to determine a
   maximum packet size.  The document = describes as an extension to RFC
   1191 and RFC 8201, which = specify ICMP-based Path MTU Discovery for
   IPv4 and IPv6.  This = provides functionally for datagram transports
   that is equivalent to the Packetization layer = PMTUD specification for
   TCP, specified in = RFC4821.

= --Apple-Mail=_BFBC3FC4-4013-4FC1-8340-348D3832225F-- --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlpUo2QACgkQVLXDCb9w wVeUxxAA02NV4VwI7tM4IDmss3y6653u2FT/Td5Ca48NDDyASzkHKAeWbpTKtgdG slfDKfdMDmNfIg/p6RX5jo1CFxeKmzmDblxFSOQOCLSdxfsHYsSid/a709OJ+Ls6 lTwh7WxvPQBnQjxtaC2aRPHcoykGZfj6UX0kgolLTTbSSQpOQ1dZWDklsRcVfRGs gFSlip63b487xq3/ymL3/ChgfD5g2AmKho+Bfg+0fi3PMPQq5iXPGGMquwKww91h 4BRH39ShddiPALyfQ3SKjxXaDdG/EiaB/5sUgVBmV0LJpU/k/uKITb+hLNE0Qtp/ sD1srnOcICXpgYFgMGn0HP0OmsAMm0GYcZewtL1ewqVyRMOdKUXu4DHkBDvJBH0J l+ZFXQJW1v4IpnliRhgH7YgJH8lgkhQMbmuDxjh7jsW/3K9L5+QashTPJARVvWZJ T6rw5xu2v1GOT317cUqQ65whI1x8Iwr5c6NcBLoc6Vo+A/s9SfcdpAJw5UgQJ1/z ooG4XJgTHw44RMqnmvLRNa1BYhOv/C5U3y9mkTaS3A4noyMexZXig/QkqmhfPyup UXfB9b8HUOMZ+s/9cIHrQeR/kFtgk4ts1hLZMhue+Fw/t5UduHVK4Y3ATVA9K/zu 11hwE6BGWYMBqx3OhlXyJp/KAZ3V3IkjBaeUWZvVlWItdBb8t2s= =ulGh -----END PGP SIGNATURE----- --Apple-Mail=_28AA2C8F-9ABF-434C-9A82-878B6E4A2EBC-- From nobody Tue Jan 9 08:59:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D112D880 for ; Tue, 9 Jan 2018 08:59:23 -0800 (PST) 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 b44whIKd7ZVe for ; Tue, 9 Jan 2018 08:59:22 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 27B0012D87F for ; Tue, 9 Jan 2018 08:59:22 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id p6so14817254wrd.0 for ; Tue, 09 Jan 2018 08:59:22 -0800 (PST) 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=6g2LtmNmgVl1waeDTqVhROr+vNIGMzmE+u2x9mFlzRc=; b=eObFkE6z1XYXGVqK2t0Gv0lAVQpxgbfYl640PEdg4pLgfrCf+wMTpgoaRTBF6dXjaJ WF01Zjg7dumNPSS8Ao+uy9gxuZ/ElLDZHotCCzi9xb2QawNVMgio7Mz7lRNEXMUolorm Jmr+UxRFTXa5GUQQR8UaSFJByt/WvB37EE7EsIDCQiuAoJUxFNa1SpBwJnTsH9S9SpiN m3IGkFotzDVjNmFc6gajJ3dTKz9zQYhu/4Xs1/C7nu+ZMkNGSTWSRNCnP3TEJ3Np+bVI gWYDdpkf1BsaT8YaRLLo3iEJUaFZ+HSSJtBVZXg5d60CehxeZaQ3abKtx/rGGA/qmM8m wQ0Q== 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=6g2LtmNmgVl1waeDTqVhROr+vNIGMzmE+u2x9mFlzRc=; b=jw0giVQJJySjfB5qqokZIOttsfLVIVoovlal+GequiH8vdeuY1iDt8xvRjTVfjD9v4 gLJ/GfzFALZe7g5B9q5rDbJ5lhsppf+NA9zHWPXyHQYlu4JZcsgdm5apBIkxoikatRxq H1JMXDeVcNlKb0FkFcPj7EVYBvhheVnsvgSKbuOaMTKtsjJu+xWU3TRzprWFDPHGcgGe RNRoREGk+TPfWCkHXEKsiQRdDsaYN2zugBOQLqjiHNOMKd4pQD8i/VVGVbLv/vx/TVhf dFHt9ULV3N2VdAHxhMgB0le4a2PJrtmjM3dpwc5RUJdEzsL69zoNNFYVer1Tx/y5cpu/ hJCQ== X-Gm-Message-State: AKGB3mKvvvPtxRtNCJRJhYHtnnfqkbo3XansYOgZ+BMHRObJaPh/jWLT dwZvjxydCtUl+xGonVqLX33ZBmqb/l2FOw8JhrFWjA== X-Google-Smtp-Source: ACJfBotrCoZHD9xvQU6clm3rWLdsob4QsekzNh3DybabhU2nICiA6fKwUqA1U9BZoCGxAZj99YEotNSmCFooPGBuhjc= X-Received: by 10.223.151.142 with SMTP id s14mr13406115wrb.256.1515517160479; Tue, 09 Jan 2018 08:59:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Tue, 9 Jan 2018 08:59:19 -0800 (PST) From: Martin Duke Date: Tue, 9 Jan 2018 08:59:19 -0800 Message-ID: Subject: RST_STREAM for send-only stream To: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c1b5622005e9c05625ad61f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Jan 2018 16:59:23 -0000 --94eb2c1b5622005e9c05625ad61f Content-Type: text/plain; charset="UTF-8" Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or stream-level? or should I drop the packet? drop the frame? --94eb2c1b5622005e9c05625ad61f Content-Type: text/html; charset="UTF-8"
Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or stream-level? or should I drop the packet? drop the frame?
--94eb2c1b5622005e9c05625ad61f-- From nobody Tue Jan 9 10:59:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5F412D77A for ; Tue, 9 Jan 2018 10:59:19 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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=evequefou.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 1YXHOqtyShbC for ; Tue, 9 Jan 2018 10:59:16 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0096.outbound.protection.outlook.com [104.47.41.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F9A8127876 for ; Tue, 9 Jan 2018 10:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sRWAAEF84sP3j8ibCm3P0g4YHUQ6sNdVvpWxgAxLN3k=; b=Zdr+Uhx+pwkdI9wNpzv2UoxjwdvkY3rlrq15db44NdoayU16phd/QUjBpc26GGWwdXJnEq1SeBLM5EewSS7RjPfeK/SddFqnVE/6xb+hkDJcfZcxPGQ/Re1N4nVY0dsrfQqCxGa1KoaeluSnrBkNwv61dFm7OeI/wJxETrLL75s= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2430.namprd08.prod.outlook.com (10.169.203.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Tue, 9 Jan 2018 18:59:13 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0386.008; Tue, 9 Jan 2018 18:59:13 +0000 From: Mike Bishop To: Martin Duke , IETF QUIC WG Subject: RE: RST_STREAM for send-only stream Thread-Topic: RST_STREAM for send-only stream Thread-Index: AQHTiWs3DZICjLaK4U6UKKGYd2e0dKNr5KQA Date: Tue, 9 Jan 2018 18:59:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2430; 7:X0ukEIqM8H+46D6RmGXNKxYUjC5S4LEO0YT9+JBzW6lwRdakWA5Zc0qECTWE+C4lw9IswIIX7f8p6vHoX7h7coo/D4GrieWEFXk7UfeQx3RbDqcJOYYpocIpzzpweYyvLKjwMqW5F2h3yUWLx0dj9tPPJxGUTsBxnjFfBcMKkOg6OqPiAGWLf2NLfLV7vovitdER4dM9DMz2fxyanUgxxTFm2b2yiYn1xv+DM6N/W681j27+1n8WVTOVlVSD9L/w x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0a138eca-67c8-451d-e399-08d557931318 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2430; x-ms-traffictypediagnostic: MWHPR08MB2430: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231023)(944501075)(6041268)(201703131423095)(20161123555045)(201703061421075)(20161123560045)(20161123558120)(20161123564045)(2016111802025)(20161123562045)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2430; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR08MB2430; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39380400002)(366004)(346002)(199004)(189003)(33656002)(6436002)(229853002)(2900100001)(7736002)(102836004)(14454004)(8936002)(81166006)(3280700002)(3660700001)(81156014)(508600001)(2906002)(66066001)(5660300001)(790700001)(6116002)(74482002)(110136005)(3846002)(97736004)(6246003)(106356001)(53936002)(7696005)(8676002)(2950100002)(86362001)(99286004)(76176011)(105586002)(39060400002)(68736007)(6306002)(55016002)(6506007)(53546011)(54896002)(74316002)(77096006)(25786009)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2430; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: enPHMAFnjncmX41gzVh41ZsWB488GcODx/mB1+3pxjDhDwigUDi/HaA+gAoNdhwONpjRqUw+vEe0ha40zHqlPg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432D80D2167110601413BFEDA100MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 0a138eca-67c8-451d-e399-08d557931318 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 18:59:13.3594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2430 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Jan 2018 18:59:19 -0000 --_000_MWHPR08MB2432D80D2167110601413BFEDA100MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb3VsZCByZWFzb25hYmx5IHNlZSBpdCBnb2luZyBlaXRoZXIgd2F5LiAgSWYgeW91IGNvbmNl aXZlIG9mIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXMgc3RhcnRpbmcgd2l0aCBvbmUgZGlyZWN0 aW9uIGFscmVhZHkgY2xvc2VkLCByZS1jbG9zaW5nIHRoZSBjbG9zZWQgc2lkZSBpcyBhIG5vLW9w LiAgSWYgeW91IGNvbmNlaXZlIG9mIHRoZSByZXZlcnNlIGRpcmVjdGlvbiBzaW1wbHkgbm90IGV4 aXN0aW5nLCB0aGVuIHRoZSBmcmFtZSBpcyBpbnZhbGlkLg0KDQpFaXRoZXIgd2F5LCB3ZSBzaG91 bGQgZGVjaWRlIGFuZCB3cml0ZSBpdCBkb3duLiAgSSBoYXZlIG5vIHN0cm9uZyBwcmVmZXJlbmNl Lg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWFydGluIER1a2UNClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgOSwgMjAxOCA4OjU5IEFNDQpU bzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUlNUX1NUUkVBTSBmb3Ig c2VuZC1vbmx5IHN0cmVhbQ0KDQpJcyBpdCBhIGZhdGFsIGVycm9yIGlmIEkgcmVjZWl2ZSBhIFJT VF9TVFJFQU0gZm9yIG15IHNlbmQtb25seSBzdHJlYW0/IElzIGl0IFBST1RPQ09MX1ZJT0xBVElP TiBvciBTVFJFQU1fU1RBVEVfRVJST1I/IGNvbm5lY3Rpb24tbGV2ZWwgb3Igc3RyZWFtLWxldmVs PyBvciBzaG91bGQgSSBkcm9wIHRoZSBwYWNrZXQ/IGRyb3AgdGhlIGZyYW1lPw0K --_000_MWHPR08MB2432D80D2167110601413BFEDA100MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgY291bGQgcmVhc29uYWJseSBzZWUgaXQgZ29pbmcgZWl0aGVyIHdheS4mbmJzcDsg SWYgeW91IGNvbmNlaXZlIG9mIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXMgc3RhcnRpbmcgd2l0 aCBvbmUgZGlyZWN0aW9uIGFscmVhZHkgY2xvc2VkLCByZS1jbG9zaW5nIHRoZSBjbG9zZWQgc2lk ZSBpcyBhIG5vLW9wLiZuYnNwOyBJZiB5b3UgY29uY2VpdmUgb2YgdGhlIHJldmVyc2UgZGlyZWN0 aW9uIHNpbXBseSBub3QgZXhpc3RpbmcsDQogdGhlbiB0aGUgZnJhbWUgaXMgaW52YWxpZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RWl0aGVyIHdheSwgd2Ugc2hvdWxkIGRlY2lkZSBhbmQgd3Jp dGUgaXQgZG93bi4mbmJzcDsgSSBoYXZlIG5vIHN0cm9uZyBwcmVmZXJlbmNlLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+TWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4g VHVlc2RheSwgSmFudWFyeSA5LCAyMDE4IDg6NTkgQU08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJ QyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUlNUX1NUUkVB TSBmb3Igc2VuZC1vbmx5IHN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXMg aXQgYSBmYXRhbCBlcnJvciBpZiBJIHJlY2VpdmUgYSBSU1RfU1RSRUFNIGZvciBteSBzZW5kLW9u bHkgc3RyZWFtPyBJcyBpdCBQUk9UT0NPTF9WSU9MQVRJT04gb3IgU1RSRUFNX1NUQVRFX0VSUk9S PyBjb25uZWN0aW9uLWxldmVsIG9yIHN0cmVhbS1sZXZlbD8gb3Igc2hvdWxkIEkgZHJvcCB0aGUg cGFja2V0PyBkcm9wIHRoZSBmcmFtZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR08MB2432D80D2167110601413BFEDA100MWHPR08MB2432namp_-- From nobody Tue Jan 9 11:11:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B5C129C56 for ; Tue, 9 Jan 2018 11:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 8Pl9WKkexkPf for ; Tue, 9 Jan 2018 11:11:34 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B9ED120725 for ; Tue, 9 Jan 2018 11:11:34 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id m11so14201088iti.1 for ; Tue, 09 Jan 2018 11:11:34 -0800 (PST) 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=E0ZwAPKZ2Kyxm4XfM1Fp4Cv+pcSCtFVxDvErHF8quqo=; b=dG1G7wSpLrecMFk1/fm+RQ+7mpSNdQmwx2zyZO6JoU/+aL3UoYuGPV8e3/o6l7UC1c mt19gH8pi7s80iNPFaJLh7TNkhmsJoCMLYjLk/5dcbg4WeBaIW9Nwxl66muiz7b/ZB7s uy8PkEUNPJF1zMQeKkYuhmHIGlLAxATA/Pko14NOcTmQ1ZoZZ/WEcKLz9Wlj+08xzSLs 9VXfvgJNp+RoCYINsGo+r1CZz/stOfmE9AVu5L2tNS7UAD2q/ZfeKp2gL/4VFSmXSr2F cspFJ1cho8/SGYLtXFldHajEV3XROA+DP3HIZ/1rVvYlLH5LJaSzsBKcejGQrv88jWPk EMQg== 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=E0ZwAPKZ2Kyxm4XfM1Fp4Cv+pcSCtFVxDvErHF8quqo=; b=ZQY/1nQxJP7u62+CpoFI8Sz02dK25r9IllDcwcHuUzYRmfZCb2quhpHmskNfElLWYq 59/yM858Keo/hRz/JPgPAKTEx5Q2mzFTlBe/EO4vhq3WfS/7yLZpjj+Lgb9lXS+o0Klz wPfNXMA1TFw7Bhmp1A3ZEvmUoPN2KCHW32MOonuAaD9HRjkdZ9nSDh9R2yaKlGjbWFi+ HVVnWnfxr1uSqzSlxr4ylgsVY0c/uiTu7lvERR8mazVcDeDQIx9j+tSkUOkfTntQOYPl jnpshDL77opcthmStdLrX6BxK8PEL9va9JeMK8Oh1DW/Ox1CPnKLRhh65GzFxvGN3p1x 5j3g== X-Gm-Message-State: AKGB3mIMwe+3tKTr0S3IVCI5wvpZIKlhWIO/yRJBa3yYcil296H4aL/Q QK2ZZ75K1RWzGy7bcl8C6fSTWo5kBX4jHkrDMEsXQQ== X-Google-Smtp-Source: ACJfBovrPS21yexoWi789tMh9XryuNz7kyohnerH8Ra8j7DDovu7Fy9YLg4X6ZRv9Ke65dRIwstzJdWbPeTQL7SwJt0= X-Received: by 10.36.73.102 with SMTP id z99mr17419638ita.72.1515525093739; Tue, 09 Jan 2018 11:11:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.82.17 with HTTP; Tue, 9 Jan 2018 11:11:12 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 9 Jan 2018 14:11:12 -0500 Message-ID: Subject: Re: RST_STREAM for send-only stream To: Mike Bishop Cc: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c14e5edd084b05625cae1e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Jan 2018 19:11:36 -0000 --001a11c14e5edd084b05625cae1e Content-Type: text/plain; charset="UTF-8" I would think it's a fatal error, but if we allow it, 0 would be the only valid offset, correct? Agreed, it should be documented. On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop wrote: > I could reasonably see it going either way. If you conceive of > unidirectional streams as starting with one direction already closed, > re-closing the closed side is a no-op. If you conceive of the reverse > direction simply not existing, then the frame is invalid. > > > > Either way, we should decide and write it down. I have no strong > preference. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Martin Duke > *Sent:* Tuesday, January 9, 2018 8:59 AM > *To:* IETF QUIC WG > *Subject:* RST_STREAM for send-only stream > > > > Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is > it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or > stream-level? or should I drop the packet? drop the frame? > --001a11c14e5edd084b05625cae1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would think it's a fatal error, but if we allow it, = 0 would be the only valid offset, correct?

Agreed, it sh= ould be documented.

On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop <mbishop@eveq= uefou.be> wrote:

I could reasonably see it going either way.=C2=A0 If= you conceive of unidirectional streams as starting with one direction alre= ady closed, re-closing the closed side is a no-op.=C2=A0 If you conceive of= the reverse direction simply not existing, then the frame is invalid.

=C2=A0

Either way, we should decide and write it down.=C2= =A0 I have no strong preference.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Duke
Sent: Tuesday, January 9, 2018 8:59 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: RST_STREAM for send-only stream

=C2=A0

Is it a fatal error if I receive a RST_STREAM for my= send-only stream? Is it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connecti= on-level or stream-level? or should I drop the packet? drop the frame?


--001a11c14e5edd084b05625cae1e-- From nobody Tue Jan 9 11:46:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2DD7129C6C for ; Tue, 9 Jan 2018 11:46:34 -0800 (PST) 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 zBozVBa4qiMb for ; Tue, 9 Jan 2018 11:46:32 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 4B444120725 for ; Tue, 9 Jan 2018 11:46:32 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id p124so5994770ite.1 for ; Tue, 09 Jan 2018 11:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yMBEcJM3Pe2CPpcfr8xxpuVKnwJEENXlYTSxZT7YXrk=; b=HC6SmrgpY14ctH84N2+Y9PjNINvUPo6U9+ot70V9b3haAsuNy6txcy6NdggeZlioXp e2k+VcJpk5pmzaIXTjZh/EdCjv9+AaV9tUvzOISnl5+6/kZ93dxcG73gEDUe/fgOxU/6 Z7w4GhSOSNYIO36HbPtun9Qrh/pnQZORgcCAL9oQ+OfwfET2PLB+iYmW42wbwD2FCvP0 tPztuN3MBU22qUoW/ulieTMpghqrqjyUAOppCg0b+HCr5lg5Tt+biv5MwD7sx7+d3gFG wGpfXzUIFUZcWSm5juYVLQF2BB4Lg0qp6/no3yuPVkm1xLpexhdMdaukxUP9jG5iT9Gq d+eA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yMBEcJM3Pe2CPpcfr8xxpuVKnwJEENXlYTSxZT7YXrk=; b=bhS77rJlNGvxLjaVf9jRfFMk/mBQCUp4z8uJwu6vrx1PGUA7f4FG9ubBpyVbWuUbZ2 ZMEqzDmucGOF6bSOTw4RCuRbYc6sypsaiGWWydQjB0c3TlWGekpNZzX6u0kTDdTTZFSA DnmzkKUoOtuEDZufxjpPBONGwQxCHh1/lp4hiZH6plwhPvg4d4xVDJJX5yI4awcme5OD 87oJZRnUlvo130LHt5dzX+PxXsni85fkfP8ooh+zVo8eJeZ0kG+4lya1buEC63ut3ilt i6Nje4ZSH3yavYKwVNxXVvOmCqGkRDQ+RrUscZFlh1eQB/HotYueXljwAcREGuRjgliI pgPA== X-Gm-Message-State: AKGB3mKMlwEqCj0Ylf9cZgY4ptlmDIFQKFaa8ChXe3sG9q8spGT/RlLZ ZeVrN60aqnVk9ElLpuIH9kKU7X1f80ltVZ6+Wfc= X-Google-Smtp-Source: ACJfBosn++SJsCtv88uNT7m25Fy8KxCaa+KBH7HhW2l9IejeoBUAh0DVh0n0R+4xTDl3/QYFnaMeRW/ciUS2Acp06FA= X-Received: by 10.36.20.73 with SMTP id 70mr16328477itg.55.1515527191678; Tue, 09 Jan 2018 11:46:31 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 9 Jan 2018 14:46:30 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 9 Jan 2018 14:46:30 -0500 Message-ID: Subject: Re: RST_STREAM for send-only stream To: Mike Bishop , Ian Swett Cc: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1143ea2ce8520205625d2b54" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Jan 2018 19:46:35 -0000 --001a1143ea2ce8520205625d2b54 Content-Type: text/plain; charset="UTF-8" Fatal error, otherwise uni-directional streams starts to have to understand and behave and like bi-directional streams. On 9 January 2018 at 20.11.40, Ian Swett (ianswett@google.com) wrote: I would think it's a fatal error, but if we allow it, 0 would be the only valid offset, correct? Agreed, it should be documented. On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop wrote: > I could reasonably see it going either way. If you conceive of > unidirectional streams as starting with one direction already closed, > re-closing the closed side is a no-op. If you conceive of the reverse > direction simply not existing, then the frame is invalid. > > > > Either way, we should decide and write it down. I have no strong > preference. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Martin Duke > *Sent:* Tuesday, January 9, 2018 8:59 AM > *To:* IETF QUIC WG > *Subject:* RST_STREAM for send-only stream > > > > Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is > it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or > stream-level? or should I drop the packet? drop the frame? > --001a1143ea2ce8520205625d2b54 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Fatal error, otherwi= se uni-directional streams starts to have to understand and behave and like= bi-directional streams.

On 9 January 2018 at 20.11.40, I= an Swett (ianswett@google.com) w= rote:

I would think it's a fatal error, but if we allow it, 0 would be the only valid offset, correct?

Agreed, it should be documented.

On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop <mbishop@evequefou.be> wrote:

I could reasonably see it going either way.=C2=A0 If you conceive of unidirectional streams as starting with one direction already closed, re-closing the closed side is a no-op.=C2=A0 If you conceive of the reverse direction simply not existing, then the frame is invalid.

=C2=A0

Either way, we should decide and write it down.=C2=A0 I have no strong preference.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Martin Duke
Sent: Tuesday, January 9, 2018 8:59 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: RST_STREAM for send-only stream

=C2=A0

Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or stream-level? or should I drop the packet? drop the frame?


--001a1143ea2ce8520205625d2b54-- From nobody Tue Jan 9 12:39:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A2712D871 for ; Tue, 9 Jan 2018 12:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 jfInYp64OuUW for ; Tue, 9 Jan 2018 12:39:45 -0800 (PST) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::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 25DDB12708C for ; Tue, 9 Jan 2018 12:39:45 -0800 (PST) Received: by mail-wr0-x22a.google.com with SMTP id s13so13021099wra.10 for ; Tue, 09 Jan 2018 12:39:45 -0800 (PST) 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=XQGpxILJKb7u8AH1ExnLZcLeRtNm5w4qEqSPv0Pk+30=; b=Q6GMo6ccn6mESssy396zK5eO2iUUUu7AEJPYL3joQwqfQ+nk23PAOH1szDmEfOnkOr EJANJQNKYBwMp5KpqOMjnpmHdQhkFXk7TkyVO2ed7F083vWuCYxTekcnEQS2TZidsFIc m2B+theZwiXdYuONwBH/yJCKVFDD3wKKlrf6udLGQh83pJDH1DXhKClz3Mwt+PPbUlXw +nR5UNVhW/yaMGeVQbFbUN//ytuh4zJP5jzBLfKYxxqrXkcXdHW48IsmmHRn/WvpSgPM gvvP8suDL6EN914J1N9poLUhuo7UGuaGvhUYuCUzUVa/lpGvhxKPJvVW/dPhwp9FiIDM pnRw== 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=XQGpxILJKb7u8AH1ExnLZcLeRtNm5w4qEqSPv0Pk+30=; b=tyLSEq29ysKse19C3Y7dV9Lq26U9Q/PBBOR1UKLVEGRPpV1MnxzHby3LoJZN2ixy0A SaRfoK3XqtCuFr/FCYzd/WwR0foTKQ2PEEyeDWNsSzDqWdWMVUAFhp6j5kE22w6GTqzp G+X0upTHxIcY5/gEZcUF2JUw2WCAuBWIA0xiWdehlV/4vnfSuA5tf8BT8oK7178nCCNr Uuq92DxLPvmktgq1c9mBVoAn9E5tT5+iVxyyptGgFMpHshWE6h0XmAC2DBlc3EjPMzz/ pMla7/gRroW8OQ1LuIyRg4KbSToVCjAskSsfBYzfxwi2GYffojEJqLE7+VjJdK5sb6d8 ZNyw== X-Gm-Message-State: AKGB3mJ2jSo4pmCDmMonoBBLmrk6LZE+pHrlfjhTed4y7wpAy1/Bhh80 b+fRKFdkpl1YWAu6VxrKPI8pjFnD5TDvtZ92C3I= X-Google-Smtp-Source: ACJfBovusgtlUt+NcU6nho2KshqDVpAgHuDOs2XQ+8YbupzI7Dr06ilrJCV3yM9Zu/eBKILN2T4gjymq7LSdE2HQvj4= X-Received: by 10.223.208.206 with SMTP id z14mr15129994wrh.109.1515530383644; Tue, 09 Jan 2018 12:39:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.128.1 with HTTP; Tue, 9 Jan 2018 12:39:43 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Tue, 9 Jan 2018 12:39:43 -0800 Message-ID: Subject: Re: RST_STREAM for send-only stream To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Mike Bishop , Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="f4f5e80a2e3429dd9a05625dea77" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Jan 2018 20:39:47 -0000 --f4f5e80a2e3429dd9a05625dea77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable issue opened: https://github.com/quicwg/base-drafts/issues/1047 On Tue, Jan 9, 2018 at 11:46 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Fatal error, otherwise uni-directional streams starts to have to > understand and behave and like bi-directional streams. > > On 9 January 2018 at 20.11.40, Ian Swett (ianswett@google.com) wrote: > > I would think it's a fatal error, but if we allow it, 0 would be the only > valid offset, correct? > > Agreed, it should be documented. > > On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop wrote: > >> I could reasonably see it going either way. If you conceive of >> unidirectional streams as starting with one direction already closed, >> re-closing the closed side is a no-op. If you conceive of the reverse >> direction simply not existing, then the frame is invalid. >> >> >> >> Either way, we should decide and write it down. I have no strong >> preference. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of* Martin Duke >> *Sent:* Tuesday, January 9, 2018 8:59 AM >> *To:* IETF QUIC WG >> *Subject:* RST_STREAM for send-only stream >> >> >> >> Is it a fatal error if I receive a RST_STREAM for my send-only stream? I= s >> it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or >> stream-level? or should I drop the packet? drop the frame? >> > > --f4f5e80a2e3429dd9a05625dea77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

O= n Tue, Jan 9, 2018 at 11:46 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkel= fj@gmail.com> wrote:
Fatal error, = otherwise uni-directional streams starts to have to understand and behave a= nd like bi-directional streams.
=

On 9 January 2= 018 at 20.11.40, Ian Swett (ianswett@google.com) wrote:

I would think it's a fatal error, but if we allow it, 0 would be the only valid offset, correct?

Agreed, it should be documented.

On Tue, Jan 9, 2018 at 1:59 PM, Mike Bishop <mbishop@evequefou.be> wrote:

I could reasonably see it going either way.=C2=A0 If you conceive of unidirectional streams as starting with one direction already closed, re-closing the closed side is a no-op.=C2=A0 If you conceive of the reverse direction simply not existing, then the frame is invalid.

=C2=A0

Either way, we should decide and write it down.=C2=A0 I have no strong preference.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Martin Duke
Sent: Tuesday, January 9, 2018 8:59 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: RST_STREAM for send-only stream

=C2=A0

Is it a fatal error if I receive a RST_STREAM for my send-only stream? Is it PROTOCOL_VIOLATION or STREAM_STATE_ERROR? connection-level or stream-level? or should I drop the packet? drop the frame?



--f4f5e80a2e3429dd9a05625dea77-- From nobody Tue Jan 9 22:17:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30AB126DC2 for ; Tue, 9 Jan 2018 22:17:21 -0800 (PST) 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 w8SP7HNRF2cR for ; Tue, 9 Jan 2018 22:17:20 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 6B302126DFE for ; Tue, 9 Jan 2018 22:17:16 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id g59so13422227otg.11 for ; Tue, 09 Jan 2018 22:17:16 -0800 (PST) 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=dMVY3GBNDWiYW1NrjJmWwxWZLZy1/yH+I+yjY9iiMgs=; b=UO9F7hkJgjxdQlk+UJUg31G9eGcosZpjeCt4I0FiRU6Ei6s6ok6srIQHguJcokqEOS 4g7P+EgpObN8q6to0610S2oQAeuObmx2XGGwL/Mvm7hwPc9XJUyWFOYK52iZNLRmjcND /TXzs1bsp3n1nT6HiFA8R9nzaaG0DChE2mJuk9Uimi6ZwmGNLJDgixcaUn8AEkJ6e0wf lQcdipkdTUvRalAKKjURSaSDJl1FabnN9yzIt6dTLgzITOmE2GZrzDbGhEZqhS9ydrAN DUTQIhhNuggFyGvYbp+hrzAwwQc/8Ztq072eLVHo/66fxLN4UgYHKGL0xzja6dpY+wgR 908w== 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=dMVY3GBNDWiYW1NrjJmWwxWZLZy1/yH+I+yjY9iiMgs=; b=rGkVrvyxznhkD/RXBXlRVcKNdfga2tfM4fWSRddjP5URXZaA4z19kh+OeSXtylLl6X roY0QLhNwKUWCHWSV91FYp8aoiZrk2ZrU3tdSKWCfzEOWw6A913MOlOSpjUk7XNwjyc+ k1jQwdlfk/i6lPxyo7hANv+ggWjC5caWVuvwGJJiao5+NDienWISn7hxB3q5S56uE4Wr DpL6qSg+hkwQJsPNGoNfnyZVPqOafX7Sk6z1g2jp3JZwFzpgvIBTcNBZPKN38NCS84Zq ai9GTreG2lqWauH9gkoH1/hdmbEmRVNYJ0cHvjTkj60M7Wc6E5NeD3YMPwSOuyhptiBL ZL9w== X-Gm-Message-State: AKwxytc4N9eiMKbC73Ccdn3bE2+mGq+soZeFVd4lSAhDn8f4QLUb7czq o25fU5bjoKaBQffrYGfT2MwVoxRxuUhg6WRnwiEP0A== X-Google-Smtp-Source: ACJfBosmDPbDhQIs6ffRxhjlkmXVEtFuaHjObIeI8/NE8A/PZ4XYy1f89i1HT96WB4ZmgU/1fL3yPne9wYnARmNpE4o= X-Received: by 10.157.0.102 with SMTP id 93mr3688361ota.175.1515565035252; Tue, 09 Jan 2018 22:17:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Tue, 9 Jan 2018 22:17:14 -0800 (PST) From: Martin Thomson Date: Wed, 10 Jan 2018 17:17:14 +1100 Message-ID: Subject: Deadlocking in the transport 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, 10 Jan 2018 06:17:22 -0000 Building a complex application protocol on top of QUIC continues to produce surprises. Today in the header compression design team meeting we discussed a deadlocking issue that I think warrants sharing with the larger group. This has implications for how people build a QUIC transport layer. It might need changes to the API that is exposed by that layer. This isn't really that new, but I don't think we've properly addressed the problem. ## The Basic Problem If a protocol creates a dependency between streams, there is a potential for flow control to deadlock. Say that I send X on stream 3 and Y on stream 7. Processing Y requires that X is processed first. X cannot be sent due to flow control but Y is sent. This is always possible even if X is appropriately prioritized. The receiver then leaves Y in its receive buffer until X is received. The receiver cannot give flow control credit for consuming Y because it can't consume Y until X is sent. But the sender needs flow control credit to send X. We are deadlocked. It doesn't matter whether the stream or connection flow control is causing the problem, either produces the same result. (To give some background on this, we were considering a preface to header blocks that identified the header table state that was necessary to process the header block. This would allow for concurrent population of the header table and sending message that depended on the header table state that is under construction. A receiver would read the identifier and then leave the remainder of the header block in the receive buffer until the header table was ready.) ## Options It seems like there are a few decent options for managing this. These are what occurred to me (there are almost certainly more options): 1. Don't do that. We might concede in this case that seeking the incremental improvement to compression efficiency isn't worth the risk. That is, we might make a general statement that this sort of inter-stream blocking is a bad idea. 2. Force receivers to consume data or reset streams in the case of unfulfilled dependencies. The former seems like it might be too much like magical thinking, in the sense that it requires that receivers conjure more memory up, but if the receiver were required to read Y and release the flow control credit, then all would be fine. For instance, we could require that the receiver reset a stream if it couldn't read and handle data. It seems like a bad arrangement though: you either have to allocate more memory than you would like or suffer the time and opportunity cost of having to do Y over. 3. Create an exception for flow control. This is what Google QUIC does for its headers stream. Roberto observed that we could alternatively create a frame type that was excluded from flow control. If this were used for data that had dependencies, then it would be impossible to deadlock. It would be similarly difficult to account for memory allocation, though if it were possible to process on receipt, then this *might* work. We'd have to do something to address out-of-order delivery though. It's possible that the stream abstraction is not appropriate in this case. 4. Block the problem at the source. It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for. Writes to the transport would consume flow control credit immediately. That way applications would only be able to write X if there was a chance that it would be delivered. Applications that have ordering requirements can ensure that Y is written after X is accepted by the transport and thereby avoid the deadlock. Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O thing. The transport might still have to buffer X for other reasons, like congestion control, but it can guarantee that flow control isn't going to block delivery. ## My Preference Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint. Protocols create this sort of inter-dependency naturally. There's a certain purity in having the flow control exert back pressure all the way to the next layer up. Not being able to build a transport with unconstrained writes is potentially creating undesirable externalities on transport users. Now they have to worry about flow control as well. Personally, I'm inclined to say that this is something that application protocols and their users should be exposed to. We've seen with the JS streams API that it's valuable to have back pressure available at the application layer and also how it is possible to do that relatively elegantly. I'm almost certain that I haven't thought about all the potential alternatives. I wonder if there isn't some experience with this problem in SCTP that might lend some insights. From nobody Tue Jan 9 22:48:30 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B257126CC4 for ; Tue, 9 Jan 2018 22:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2inkeOQv09Rf for ; Tue, 9 Jan 2018 22:48:27 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id BFC3F126D46 for ; Tue, 9 Jan 2018 22:48:26 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0A6mKKL013934; Wed, 10 Jan 2018 07:48:20 +0100 Date: Wed, 10 Jan 2018 07:48:20 +0100 From: Willy Tarreau To: Martin Thomson Cc: QUIC WG Subject: Re: Deadlocking in the transport Message-ID: <20180110064820.GA13923@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 06:48:29 -0000 Hi Martin, On Wed, Jan 10, 2018 at 05:17:14PM +1100, Martin Thomson wrote: > 4. Block the problem at the source. It was suggested that in cases > where there is a potential dependency, then it can't be a problem if > the transport refused to accept data that it didn't have flow control > credit for. Writes to the transport would consume flow control credit > immediately. That way applications would only be able to write X if > there was a chance that it would be delivered. Applications that have > ordering requirements can ensure that Y is written after X is accepted > by the transport and thereby avoid the deadlock. Writes might block > rather than fail, if the API wasn't into the whole non-blocking I/O > thing. The transport might still have to buffer X for other reasons, > like congestion control, but it can guarantee that flow control isn't > going to block delivery. > > > ## My Preference > > Right now, I'm inclined toward option 4. Well, I'm lagging a bit too much to have a valuable opinion, but all I can say is that from a protocol design perspective, this option totally makes sense. Starting to send when you depend on something which is blocked doesn't make real sense. In fact it could even be argued that in such dependencies cases, the flow control could be shared, i.e. Y could offer some of its budget to X to ensure it can make progress resulting in the two ultimately being unblocked. I know it would imply a number of painful changes though and I'm just talking about threory here. Regards, Willy From nobody Tue Jan 9 22:49:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA3B126FDC for ; Tue, 9 Jan 2018 22:49:33 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 zoetmx3otA8j for ; Tue, 9 Jan 2018 22:49:30 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 39F06126D46 for ; Tue, 9 Jan 2018 22:49:30 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id b132so3827307yba.5 for ; Tue, 09 Jan 2018 22:49:30 -0800 (PST) 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=yZgFMnA+bG6hI7Y0DdS1yfoOqKEO3awx+1YYD+GzLW8=; b=TbGXdccYvJ9k63Ljp4GaxoxXMNahsu4RYEWJ9CJWT0Ihp0ub5ewdRxyih05hIaDcEI fjFuW07idx0TGexwhYSHXF9l9r6F70bW0kM/BPPjOR5tpF2NNGJgfeJqC+avXEpSnrpy fFMPkBz/pq1n0CrsU4y11FlJQu7v4lqOE/RF1TQ+EZTJ5I9AO12Z+pkruuCj/lsAAyUH C2Bgzjhrc2CxigEIDR7RccyPTlcvYVG1UsynAgHvEtSvjSOXDNBsSl8Ih5h6CJZx/Xb/ OFgH1mfD+OxybS3vwnsqyMpj1vCiRRrjXYCLzyU48CuYU19wlxLyk/KZHk2cg3rshr9o uZzg== 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=yZgFMnA+bG6hI7Y0DdS1yfoOqKEO3awx+1YYD+GzLW8=; b=gKZi9OLCyFEs7y7k0N9S9J3cUgaFcocJAU/V/L/GJicmRj8CBCJR3R54M9nX+t3vGp Ylj+XayCuu5rUbmkaG+GIXGVtaezL3X3RbGYJKbWrezjVcRJSh9UGsm2GwicT1mNr5H8 BQ+H4GQay75pRQGwFzVMzsN4ceSwTgWYyYnvQh3ISJT2ZuXrz+jOc8MhIk4VaoQyKnQY Qhag4+p6f4kubzcXl2kEZElzv2CcaDdyeKf0WjdRF5N7m2xxqO+qeZfB9Q9u5XJfWy7d XHQPtzWepQDd0xBBnBtanYvNwK88wtx0x1IDv0n7nrsRvSLpyyJbwfbUreVBcmfQSbKI xVjQ== X-Gm-Message-State: AKGB3mL4ZGmqXSsb2PsYbNOnzXfXi9irrAf7QeVTdnVuaJlp4r+9EWp6 6r9Pz9v6A/FwfyB0B7g63BkiTgx/Z+Cei0FZHeEeXw== X-Google-Smtp-Source: ACJfBoudA9xVx+yPd263TnFZDvwyvwKIaqpFbWnsb69FlS24+MC0qBLxje0aNKQnjqM21IQFzATK+1RdLtOJKz9p2K0= X-Received: by 10.37.232.8 with SMTP id k8mr11730011ybd.398.1515566968915; Tue, 09 Jan 2018 22:49:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Tue, 9 Jan 2018 22:49:28 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 9 Jan 2018 22:49:28 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="089e08269314d199f50562666e7e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 06:49:33 -0000 --089e08269314d199f50562666e7e Content-Type: text/plain; charset="UTF-8" Martin, You are right that this isn't a new concern, and that this is worth noting somewhere, perhaps in the applicability/API doc. The crux of this issue is that there's structure in application data that the transport is unaware of. Specifically, there are dependencies among application data units that is opaque to the transport. Using the transport buffers as a part of handling these dependencies seems like a bad idea, especially since the transport is likely to make decisions about flow window updates based on rate at which data is consumed out of the receive buffer(s). GQUIC does this, and so does every respectable TCP receiver implementation. The SCTP API avoids this problem by not allowing the application to read specific stream data out of the socket buffers. The receiving app receives data that could belong to any stream and has to demux after reading out of the socket. (Note that SCTP does not have per-stream flow control, so the receive side here is more like SPDY/TCP, modulo HoL blocking at the transport.) Protocols that create inter-stream dependency should be able to express that in priorities down to the transport, which I believe is expected to be part of the API. I believe that handles this issue, doesn't it? - jana On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson wrote: > Building a complex application protocol on top of QUIC continues to > produce surprises. > > Today in the header compression design team meeting we discussed a > deadlocking issue that I think warrants sharing with the larger group. > This has implications for how people build a QUIC transport layer. It > might need changes to the API that is exposed by that layer. > > This isn't really that new, but I don't think we've properly addressed > the problem. > > > ## The Basic Problem > > If a protocol creates a dependency between streams, there is a > potential for flow control to deadlock. > > Say that I send X on stream 3 and Y on stream 7. Processing Y > requires that X is processed first. > > X cannot be sent due to flow control but Y is sent. This is always > possible even if X is appropriately prioritized. The receiver then > leaves Y in its receive buffer until X is received. > > The receiver cannot give flow control credit for consuming Y because > it can't consume Y until X is sent. But the sender needs flow control > credit to send X. We are deadlocked. > > It doesn't matter whether the stream or connection flow control is > causing the problem, either produces the same result. > > (To give some background on this, we were considering a preface to > header blocks that identified the header table state that was > necessary to process the header block. This would allow for > concurrent population of the header table and sending message that > depended on the header table state that is under construction. A > receiver would read the identifier and then leave the remainder of the > header block in the receive buffer until the header table was ready.) > > > ## Options > > It seems like there are a few decent options for managing this. These > are what occurred to me (there are almost certainly more options): > > 1. Don't do that. We might concede in this case that seeking the > incremental improvement to compression efficiency isn't worth the > risk. That is, we might make a general statement that this sort of > inter-stream blocking is a bad idea. > > 2. Force receivers to consume data or reset streams in the case of > unfulfilled dependencies. The former seems like it might be too much > like magical thinking, in the sense that it requires that receivers > conjure more memory up, but if the receiver were required to read Y > and release the flow control credit, then all would be fine. For > instance, we could require that the receiver reset a stream if it > couldn't read and handle data. It seems like a bad arrangement > though: you either have to allocate more memory than you would like or > suffer the time and opportunity cost of having to do Y over. > > 3. Create an exception for flow control. This is what Google QUIC > does for its headers stream. Roberto observed that we could > alternatively create a frame type that was excluded from flow control. > If this were used for data that had dependencies, then it would be > impossible to deadlock. It would be similarly difficult to account > for memory allocation, though if it were possible to process on > receipt, then this *might* work. We'd have to do something to address > out-of-order delivery though. It's possible that the stream > abstraction is not appropriate in this case. > > 4. Block the problem at the source. It was suggested that in cases > where there is a potential dependency, then it can't be a problem if > the transport refused to accept data that it didn't have flow control > credit for. Writes to the transport would consume flow control credit > immediately. That way applications would only be able to write X if > there was a chance that it would be delivered. Applications that have > ordering requirements can ensure that Y is written after X is accepted > by the transport and thereby avoid the deadlock. Writes might block > rather than fail, if the API wasn't into the whole non-blocking I/O > thing. The transport might still have to buffer X for other reasons, > like congestion control, but it can guarantee that flow control isn't > going to block delivery. > > > ## My Preference > > Right now, I'm inclined toward option 4. Option 1 seems a little too > much of a constraint. Protocols create this sort of inter-dependency > naturally. > > There's a certain purity in having the flow control exert back > pressure all the way to the next layer up. Not being able to build a > transport with unconstrained writes is potentially creating > undesirable externalities on transport users. Now they have to worry > about flow control as well. Personally, I'm inclined to say that this > is something that application protocols and their users should be > exposed to. We've seen with the JS streams API that it's valuable to > have back pressure available at the application layer and also how it > is possible to do that relatively elegantly. > > I'm almost certain that I haven't thought about all the potential > alternatives. I wonder if there isn't some experience with this > problem in SCTP that might lend some insights. > > --089e08269314d199f50562666e7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Martin,

You are right that this isn'= ;t a new concern, and that this is worth noting somewhere, perhaps in the a= pplicability/API doc.

The crux of this issue is th= at there's structure in application data that the transport is unaware = of. Specifically, there are dependencies among application data units that = is opaque to the transport. Using the transport buffers as a part of handli= ng these dependencies seems like a bad idea, especially since the transport= is likely to make decisions about flow window updates based on rate at whi= ch data is consumed out of the receive buffer(s). GQUIC does this, and so d= oes every respectable TCP receiver implementation.

The SCTP API avoids this problem by not allowing the application to read s= pecific stream data out of the socket buffers. The receiving app receives d= ata that could belong to any stream and has to demux after reading out of t= he socket. (Note that SCTP does not have per-stream flow control, so the re= ceive side here is more like SPDY/TCP, modulo HoL blocking at the transport= .)

Protocols that create inter-stream dependency s= hould be able to express that in priorities down to the transport, which I = believe is expected to be part of the API. I believe that handles this issu= e, doesn't it?

- jana

On Tue, Jan 9, 2018 at 10:17 P= M, Martin Thomson <martin.thomson@gmail.com> wrote:
Building a complex application protocol on= top of QUIC continues to
produce surprises.

Today in the header compression design team meeting we discussed a
deadlocking issue that I think warrants sharing with the larger group.
This has implications for how people build a QUIC transport layer.=C2=A0 It=
might need changes to the API that is exposed by that layer.

This isn't really that new, but I don't think we've properly ad= dressed
the problem.


## The Basic Problem

If a protocol creates a dependency between streams, there is a
potential for flow control to deadlock.

Say that I send X on stream 3 and Y on stream 7.=C2=A0 Processing Y
requires that X is processed first.

X cannot be sent due to flow control but Y is sent.=C2=A0 This is always possible even if X is appropriately prioritized.=C2=A0 The receiver then leaves Y in its receive buffer until X is received.

The receiver cannot give flow control credit for consuming Y because
it can't consume Y until X is sent.=C2=A0 But the sender needs flow con= trol
credit to send X.=C2=A0 We are deadlocked.

It doesn't matter whether the stream or connection flow control is
causing the problem, either produces the same result.

(To give some background on this, we were considering a preface to
header blocks that identified the header table state that was
necessary to process the header block.=C2=A0 This would allow for
concurrent population of the header table and sending message that
depended on the header table state that is under construction.=C2=A0 A
receiver would read the identifier and then leave the remainder of the
header block in the receive buffer until the header table was ready.)


## Options

It seems like there are a few decent options for managing this.=C2=A0 These=
are what occurred to me (there are almost certainly more options):

1. Don't do that.=C2=A0 We might concede in this case that seeking the<= br> incremental improvement to compression efficiency isn't worth the
risk.=C2=A0 That is, we might make a general statement that this sort of inter-stream blocking is a bad idea.

2. Force receivers to consume data or reset streams in the case of
unfulfilled dependencies.=C2=A0 The former seems like it might be too much<= br> like magical thinking, in the sense that it requires that receivers
conjure more memory up, but if the receiver were required to read Y
and release the flow control credit, then all would be fine.=C2=A0 For
instance, we could require that the receiver reset a stream if it
couldn't read and handle data.=C2=A0 It seems like a bad arrangement though: you either have to allocate more memory than you would like or
suffer the time and opportunity cost of having to do Y over.

3. Create an exception for flow control.=C2=A0 This is what Google QUIC
does for its headers stream.=C2=A0 Roberto observed that we could
alternatively create a frame type that was excluded from flow control.
If this were used for data that had dependencies, then it would be
impossible to deadlock.=C2=A0 It would be similarly difficult to account for memory allocation, though if it were possible to process on
receipt, then this *might* work.=C2=A0 We'd have to do something to add= ress
out-of-order delivery though.=C2=A0 It's possible that the stream
abstraction is not appropriate in this case.

4. Block the problem at the source.=C2=A0 It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for.=C2=A0 Writes to the transport would consume flow control credit=
immediately.=C2=A0 That way applications would only be able to write X if there was a chance that it would be delivered.=C2=A0 Applications that have=
ordering requirements can ensure that Y is written after X is accepted
by the transport and thereby avoid the deadlock.=C2=A0 Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O
thing.=C2=A0 The transport might still have to buffer X for other reasons,<= br> like congestion control, but it can guarantee that flow control isn't going to block delivery.


## My Preference

Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint.=C2=A0 Protocols create this sort of inter-dependency<= br> naturally.

There's a certain purity in having the flow control exert back
pressure all the way to the next layer up.=C2=A0 Not being able to build a<= br> transport with unconstrained writes is potentially creating
undesirable externalities on transport users.=C2=A0 Now they have to worry<= br> about flow control as well.=C2=A0 Personally, I'm inclined to say that = this
is something that application protocols and their users should be
exposed to.=C2=A0 We've seen with the JS streams API that it's valu= able to
have back pressure available at the application layer and also how it
is possible to do that relatively elegantly.

I'm almost certain that I haven't thought about all the potential alternatives.=C2=A0 I wonder if there isn't some experience with this problem in SCTP that might lend some insights.


--089e08269314d199f50562666e7e-- From nobody Tue Jan 9 22:55:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB604126D46 for ; Tue, 9 Jan 2018 22:55:11 -0800 (PST) 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=JN96xNWy; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=XXmrZswZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrfMbB2kkJ1Z for ; Tue, 9 Jan 2018 22:55:08 -0800 (PST) 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 94C631200C1 for ; Tue, 9 Jan 2018 22:55:08 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0A6sUse002815; Tue, 9 Jan 2018 22:55:05 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=DktV9kBgTfCBgpmz/JrxOycVK6QF0azl4Q3MMwMWIAU=; b=JN96xNWyuCIQM7G4vkxqER9Iwd/YucT+xHtf7BfsIAumNqQ2MLQHukDQrYLcvTqABnrF /V05yvSYzYogUl9olevbSDZ7L/QBDyNIdjwoFoKReoWUqM06xjGfESS9guSTGrCcJawz aQeInquZhktxzi1erJAzJ93liAW9WGqYdhE= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fdb91r980-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 09 Jan 2018 22:55:05 -0800 Received: from NAM02-BL2-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.361.1; Wed, 10 Jan 2018 01:55:02 -0500 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=DktV9kBgTfCBgpmz/JrxOycVK6QF0azl4Q3MMwMWIAU=; b=XXmrZswZ+tcbzuMr/TwU5+Fc8hRTWnp5mgTwcSAaSFDu+yPWaeht1ZP1fv5gkN1QKa41aglUB1Hx4AX7+0NNtJEf1K3LTlkOKGH6YTMoZbL65uMYiU1qMOZl+NvuTWuvHHMbCl6jHSwOtPkyJxA5mboUxLGp7yvxiAEijWroo+8= 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_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 10 Jan 2018 06:55:01 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0386.008; Wed, 10 Jan 2018 06:55:01 +0000 From: Subodh Iyengar To: Jana Iyengar , Martin Thomson CC: QUIC WG Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/a4cBdzPDRUarOmEVeSeK1qNsqpwAgAAA0Rw= Date: Wed, 10 Jan 2018 06:55:01 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::fd76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 7:PtQ/mJ75ztnkaCsVnePj8WiEWR2FHMZMCLT3Rf9PPOa1kkGAacxlKEzK8OP9a8UVpM8K2CmWIfgdBWCxPjBzJjOE+LvbpMg/gD54ufbq3Yrt5xmuhQBJOSmNKzVxckt5ubFCnz4IQYNHU05Og5eDX/DeAfMCD2sN6FdsWpUidCZeeYK2kDCsai62dDDU9P+f/v9oe2TOVC5viU1/gphwzm8+E0FbuiHGxF9bkY5+e0VAboocWLDJY1RVRPEj0bgv; 20:6wIL98iK7iGPKeijpKPGmcOnrA6+1qD6feZBuyzdYLbE2Wtvma+9Ot/iJRRCk95bW1TQB+s60cDJmxkdBt2q0ajoHhsnpWv8dWVR1bcaxWWejhoS+NjpJPHjtrdG1fDY6Dt4BrPSx998JMzZ13bG/y67NPt9pIhupKstR/CCDP4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fc946f95-31e6-4f8a-4315-08d557f71215 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020047)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1453; x-ms-traffictypediagnostic: MWHPR15MB1453: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(85827821059158)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(944501119)(10201501046)(3002001)(6041268)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR15MB1453; x-forefront-prvs: 0548586081 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(366004)(346002)(39860400002)(396003)(376002)(39380400002)(24454002)(54094003)(199004)(189003)(6246003)(53936002)(478600001)(25786009)(86362001)(7736002)(39060400002)(4326008)(2900100001)(7696005)(236005)(99286004)(33656002)(19627405001)(9686003)(6436002)(81156014)(105586002)(8676002)(77096006)(54896002)(55016002)(53546011)(74316002)(81166006)(102836004)(6506007)(106356001)(229853002)(97736004)(76176011)(59450400001)(68736007)(6606003)(2950100002)(3660700001)(5660300001)(14454004)(8936002)(3480700004)(6116002)(110136005)(316002)(3280700002)(2906002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1453; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: V4NPxsRPBRzKG6QnBn5wvP/sxO8/8aMzNruPNW1JHso5Y78/Bu1nHYYjh1/81+ZM9I+rku6B7Sg2ewCvO/n1FQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14551E79F98123F466AB2235B6110MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fc946f95-31e6-4f8a-4315-08d557f71215 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 06:55:01.3465 (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-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-10_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 06:55:11 -0000 --_000_MWHPR15MB14551E79F98123F466AB2235B6110MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nice catch. Option 4. is possible without protocol support I believe and this coinciden= tally is also the API that mvfst implements, i.e. our API counts buffered d= ata as well towards the flow control for API writes. Although even with this it seems very gotcha behavior which is not super ob= vious which people will definitely be burned by. I'm in favor of something = like 3 which could potentially allow the receiver to signal to the sender t= o create an exception to the connection flow control for some streams when = it gets into deadlocked states. There are some races with this, but it coul= d be designed to work. Subodh ________________________________ From: QUIC on behalf of Jana Iyengar Sent: Tuesday, January 9, 2018 10:49:28 PM To: Martin Thomson Cc: QUIC WG Subject: Re: Deadlocking in the transport Martin, You are right that this isn't a new concern, and that this is worth noting = somewhere, perhaps in the applicability/API doc. The crux of this issue is that there's structure in application data that t= he transport is unaware of. Specifically, there are dependencies among appl= ication data units that is opaque to the transport. Using the transport buf= fers as a part of handling these dependencies seems like a bad idea, especi= ally since the transport is likely to make decisions about flow window upda= tes based on rate at which data is consumed out of the receive buffer(s). G= QUIC does this, and so does every respectable TCP receiver implementation. The SCTP API avoids this problem by not allowing the application to read sp= ecific stream data out of the socket buffers. The receiving app receives da= ta that could belong to any stream and has to demux after reading out of th= e socket. (Note that SCTP does not have per-stream flow control, so the rec= eive side here is more like SPDY/TCP, modulo HoL blocking at the transport.= ) Protocols that create inter-stream dependency should be able to express tha= t in priorities down to the transport, which I believe is expected to be pa= rt of the API. I believe that handles this issue, doesn't it? - jana On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson > wrote: Building a complex application protocol on top of QUIC continues to produce surprises. Today in the header compression design team meeting we discussed a deadlocking issue that I think warrants sharing with the larger group. This has implications for how people build a QUIC transport layer. It might need changes to the API that is exposed by that layer. This isn't really that new, but I don't think we've properly addressed the problem. ## The Basic Problem If a protocol creates a dependency between streams, there is a potential for flow control to deadlock. Say that I send X on stream 3 and Y on stream 7. Processing Y requires that X is processed first. X cannot be sent due to flow control but Y is sent. This is always possible even if X is appropriately prioritized. The receiver then leaves Y in its receive buffer until X is received. The receiver cannot give flow control credit for consuming Y because it can't consume Y until X is sent. But the sender needs flow control credit to send X. We are deadlocked. It doesn't matter whether the stream or connection flow control is causing the problem, either produces the same result. (To give some background on this, we were considering a preface to header blocks that identified the header table state that was necessary to process the header block. This would allow for concurrent population of the header table and sending message that depended on the header table state that is under construction. A receiver would read the identifier and then leave the remainder of the header block in the receive buffer until the header table was ready.) ## Options It seems like there are a few decent options for managing this. These are what occurred to me (there are almost certainly more options): 1. Don't do that. We might concede in this case that seeking the incremental improvement to compression efficiency isn't worth the risk. That is, we might make a general statement that this sort of inter-stream blocking is a bad idea. 2. Force receivers to consume data or reset streams in the case of unfulfilled dependencies. The former seems like it might be too much like magical thinking, in the sense that it requires that receivers conjure more memory up, but if the receiver were required to read Y and release the flow control credit, then all would be fine. For instance, we could require that the receiver reset a stream if it couldn't read and handle data. It seems like a bad arrangement though: you either have to allocate more memory than you would like or suffer the time and opportunity cost of having to do Y over. 3. Create an exception for flow control. This is what Google QUIC does for its headers stream. Roberto observed that we could alternatively create a frame type that was excluded from flow control. If this were used for data that had dependencies, then it would be impossible to deadlock. It would be similarly difficult to account for memory allocation, though if it were possible to process on receipt, then this *might* work. We'd have to do something to address out-of-order delivery though. It's possible that the stream abstraction is not appropriate in this case. 4. Block the problem at the source. It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for. Writes to the transport would consume flow control credit immediately. That way applications would only be able to write X if there was a chance that it would be delivered. Applications that have ordering requirements can ensure that Y is written after X is accepted by the transport and thereby avoid the deadlock. Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O thing. The transport might still have to buffer X for other reasons, like congestion control, but it can guarantee that flow control isn't going to block delivery. ## My Preference Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint. Protocols create this sort of inter-dependency naturally. There's a certain purity in having the flow control exert back pressure all the way to the next layer up. Not being able to build a transport with unconstrained writes is potentially creating undesirable externalities on transport users. Now they have to worry about flow control as well. Personally, I'm inclined to say that this is something that application protocols and their users should be exposed to. We've seen with the JS streams API that it's valuable to have back pressure available at the application layer and also how it is possible to do that relatively elegantly. I'm almost certain that I haven't thought about all the potential alternatives. I wonder if there isn't some experience with this problem in SCTP that might lend some insights. --_000_MWHPR15MB14551E79F98123F466AB2235B6110MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nice catch.


Option 4. is possible without pro= tocol support I believe and this coincidentally is also the API that mvfst = implements, i.e. our API counts buffered data as well towards the flow cont= rol for API writes.


Although even with this it seems = very gotcha behavior which is not super obvious which people will definitel= y be burned by. I'm in favor of something like 3 which could potentially al= low the receiver to signal to the sender to create an exception to the connection flow control for some stre= ams when it gets into deadlocked states. There are some races with this, bu= t it could be designed to work.

Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Jana Iyengar <jri@google.com>
Sent: Tuesday, January 9, 2018 10:49:28 PM
To: Martin Thomson
Cc: QUIC WG
Subject: Re: Deadlocking in the transport
 
Martin,

You are right that this isn't a new concern, and that this is worth no= ting somewhere, perhaps in the applicability/API doc.

The crux of this issue is that there's structure in application data t= hat the transport is unaware of. Specifically, there are dependencies among= application data units that is opaque to the transport. Using the transpor= t buffers as a part of handling these dependencies seems like a bad idea, especially since the transport i= s likely to make decisions about flow window updates based on rate at which= data is consumed out of the receive buffer(s). GQUIC does this, and so doe= s every respectable TCP receiver implementation.

The SCTP API avoids this problem by not allowing the application to re= ad specific stream data out of the socket buffers. The receiving app receiv= es data that could belong to any stream and has to demux after reading out = of the socket. (Note that SCTP does not have per-stream flow control, so the receive side here is more like SP= DY/TCP, modulo HoL blocking at the transport.)

Protocols that create inter-stream dependency should be able to expres= s that in priorities down to the transport, which I believe is expected to = be part of the API. I believe that handles this issue, doesn't it?

- jana

On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomso= n <martin.th= omson@gmail.com> wrote:
Building a complex application protocol on top of QUIC continues to
produce surprises.

Today in the header compression design team meeting we discussed a
deadlocking issue that I think warrants sharing with the larger group.
This has implications for how people build a QUIC transport layer.  It=
might need changes to the API that is exposed by that layer.

This isn't really that new, but I don't think we've properly addressed
the problem.


## The Basic Problem

If a protocol creates a dependency between streams, there is a
potential for flow control to deadlock.

Say that I send X on stream 3 and Y on stream 7.  Processing Y
requires that X is processed first.

X cannot be sent due to flow control but Y is sent.  This is always possible even if X is appropriately prioritized.  The receiver then leaves Y in its receive buffer until X is received.

The receiver cannot give flow control credit for consuming Y because
it can't consume Y until X is sent.  But the sender needs flow control=
credit to send X.  We are deadlocked.

It doesn't matter whether the stream or connection flow control is
causing the problem, either produces the same result.

(To give some background on this, we were considering a preface to
header blocks that identified the header table state that was
necessary to process the header block.  This would allow for
concurrent population of the header table and sending message that
depended on the header table state that is under construction.  A
receiver would read the identifier and then leave the remainder of the
header block in the receive buffer until the header table was ready.)


## Options

It seems like there are a few decent options for managing this.  These=
are what occurred to me (there are almost certainly more options):

1. Don't do that.  We might concede in this case that seeking the
incremental improvement to compression efficiency isn't worth the
risk.  That is, we might make a general statement that this sort of inter-stream blocking is a bad idea.

2. Force receivers to consume data or reset streams in the case of
unfulfilled dependencies.  The former seems like it might be too much<= br> like magical thinking, in the sense that it requires that receivers
conjure more memory up, but if the receiver were required to read Y
and release the flow control credit, then all would be fine.  For
instance, we could require that the receiver reset a stream if it
couldn't read and handle data.  It seems like a bad arrangement
though: you either have to allocate more memory than you would like or
suffer the time and opportunity cost of having to do Y over.

3. Create an exception for flow control.  This is what Google QUIC
does for its headers stream.  Roberto observed that we could
alternatively create a frame type that was excluded from flow control.
If this were used for data that had dependencies, then it would be
impossible to deadlock.  It would be similarly difficult to account for memory allocation, though if it were possible to process on
receipt, then this *might* work.  We'd have to do something to address=
out-of-order delivery though.  It's possible that the stream
abstraction is not appropriate in this case.

4. Block the problem at the source.  It was suggested that in cases where there is a potential dependency, then it can't be a problem if
the transport refused to accept data that it didn't have flow control
credit for.  Writes to the transport would consume flow control credit=
immediately.  That way applications would only be able to write X if there was a chance that it would be delivered.  Applications that have=
ordering requirements can ensure that Y is written after X is accepted
by the transport and thereby avoid the deadlock.  Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O
thing.  The transport might still have to buffer X for other reasons,<= br> like congestion control, but it can guarantee that flow control isn't
going to block delivery.


## My Preference

Right now, I'm inclined toward option 4. Option 1 seems a little too
much of a constraint.  Protocols create this sort of inter-dependency<= br> naturally.

There's a certain purity in having the flow control exert back
pressure all the way to the next layer up.  Not being able to build a<= br> transport with unconstrained writes is potentially creating
undesirable externalities on transport users.  Now they have to worry<= br> about flow control as well.  Personally, I'm inclined to say that this=
is something that application protocols and their users should be
exposed to.  We've seen with the JS streams API that it's valuable to<= br> have back pressure available at the application layer and also how it
is possible to do that relatively elegantly.

I'm almost certain that I haven't thought about all the potential
alternatives.  I wonder if there isn't some experience with this
problem in SCTP that might lend some insights.


--_000_MWHPR15MB14551E79F98123F466AB2235B6110MWHPR15MB1455namp_-- From nobody Tue Jan 9 23:05:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E3C126D46 for ; Tue, 9 Jan 2018 23:05:01 -0800 (PST) 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 2mNfbYmcov6I for ; Tue, 9 Jan 2018 23:04:58 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D8B12704A for ; Tue, 9 Jan 2018 23:04:58 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AF50F3402A0; Wed, 10 Jan 2018 08:04:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.12186); Wed, 10 Jan 2018 08:04:53 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 10 Jan 2018 08:04:53 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 41652013; Wed, 10 Jan 2018 08:04:53 +0100 From: "Brian Trammell (IETF)" Message-Id: <65EBA092-9DEF-4C9E-9DB8-AA490CA60598@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_F6232BD4-D1B9-4872-B19C-E5202C5D9B03"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deadlocking in the transport Date: Wed, 10 Jan 2018 08:04:52 +0100 In-Reply-To: Cc: QUIC WG To: Martin Thomson 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, 10 Jan 2018 07:05:02 -0000 --Apple-Mail=_F6232BD4-D1B9-4872-B19C-E5202C5D9B03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all, > On 10 Jan 2018, at 07:17, Martin Thomson = wrote: >=20 > Building a complex application protocol on top of QUIC continues to > produce surprises. >=20 > Today in the header compression design team meeting we discussed a > deadlocking issue that I think warrants sharing with the larger group. > This has implications for how people build a QUIC transport layer. It > might need changes to the API that is exposed by that layer. >=20 > This isn't really that new, but I don't think we've properly addressed > the problem. Indeed, we ran into a closely related problem with IPFIX. IPFIX itself = had no flow control, so reordering and unreliable transport of dependent = information (in this case, templates and the data they describe) was a = matter of ambiguous interpretation, not deadlock. But most of the = substantive changes between the Proposed Standard (RFC 5101) and = Internet Standard (RFC 7011) versions of the protocol had to do with = fixing how collectors handled potentially unordered or missing template = information (see section 8 of 7011 if you're interested in details). The IPFIX case is further complicated because it runs over TCP (in = order, reliable, single stream, so template ambiguity is not a problem), = SCTP (where there can be stream dependencies; 5101 allowed anything on = any stream at any time, 6526 suggested a refinement where every template = ID got its own stream, thereby ordering template change messages, and = 7011 specified generalized ordering), and UDP (where template ID reuse = is only permitted after a long delay). > ## The Basic Problem >=20 > If a protocol creates a dependency between streams, there is a > potential for flow control to deadlock. >=20 > Say that I send X on stream 3 and Y on stream 7. Processing Y > requires that X is processed first. >=20 > X cannot be sent due to flow control but Y is sent. This is always > possible even if X is appropriately prioritized. The receiver then > leaves Y in its receive buffer until X is received. >=20 > The receiver cannot give flow control credit for consuming Y because > it can't consume Y until X is sent. But the sender needs flow control > credit to send X. We are deadlocked. >=20 > It doesn't matter whether the stream or connection flow control is > causing the problem, either produces the same result. >=20 > (To give some background on this, we were considering a preface to > header blocks that identified the header table state that was > necessary to process the header block. This would allow for > concurrent population of the header table and sending message that > depended on the header table state that is under construction. A > receiver would read the identifier and then leave the remainder of the > header block in the receive buffer until the header table was ready.) >=20 >=20 > ## Options >=20 > It seems like there are a few decent options for managing this. These > are what occurred to me (there are almost certainly more options): >=20 > 1. Don't do that. We might concede in this case that seeking the > incremental improvement to compression efficiency isn't worth the > risk. That is, we might make a general statement that this sort of > inter-stream blocking is a bad idea. As I noted in the chat during the Vancouver interim, both for the = specific case of header compression, as well as in general, I am an = emphatic and enthusiastic supporter of "don't do that". Introducing = stream dependencies takes a trivially implementable dictionary-transfer = protocol and turns it into something that is very, very difficult to get = right, and "implementability by people outside the QUIC Interop Slack = channel" is a primary technical requirement of the protocol spec. > 2. Force receivers to consume data or reset streams in the case of > unfulfilled dependencies. The former seems like it might be too much > like magical thinking, in the sense that it requires that receivers > conjure more memory up, but if the receiver were required to read Y > and release the flow control credit, then all would be fine. For > instance, we could require that the receiver reset a stream if it > couldn't read and handle data. It seems like a bad arrangement > though: you either have to allocate more memory than you would like or > suffer the time and opportunity cost of having to do Y over. This is the approach we used in IPFIX, with varying success. We have the = advantage that every IPFIX message can be ordered by its export = timestamp and sequence number, so we basically tell collectors to use a = buffer of unspecified size to reorder messages, to consider them in the = order they should have been sent in, and to freak out if that still = leads to detectable ambiguity. AFAIK, nobody successfully uses template deletion and ID reuse in = practice unless there are relatively long delays between them. > 3. Create an exception for flow control. This is what Google QUIC > does for its headers stream. Roberto observed that we could > alternatively create a frame type that was excluded from flow control. > If this were used for data that had dependencies, then it would be > impossible to deadlock. It would be similarly difficult to account > for memory allocation, though if it were possible to process on > receipt, then this *might* work. We'd have to do something to address > out-of-order delivery though. It's possible that the stream > abstraction is not appropriate in this case. This seems to me to be inexcusably ugly. In any case, this would need to be generalized to be an = "application-layer control information frame", and there would need to = be big red stickers all over it, because it would be so tempting to = abuse, because such abuse would almost always work in test. > 4. Block the problem at the source. It was suggested that in cases > where there is a potential dependency, then it can't be a problem if > the transport refused to accept data that it didn't have flow control > credit for. Writes to the transport would consume flow control credit > immediately. That way applications would only be able to write X if > there was a chance that it would be delivered. Applications that have > ordering requirements can ensure that Y is written after X is accepted > by the transport and thereby avoid the deadlock. Writes might block > rather than fail, if the API wasn't into the whole non-blocking I/O > thing. The transport might still have to buffer X for other reasons, > like congestion control, but it can guarantee that flow control isn't > going to block delivery. I'm not sure how I see this is fundamentally different from "don't do = that" from the transport protocol's point of view. > ## My Preference >=20 > Right now, I'm inclined toward option 4. Option 1 seems a little too > much of a constraint. Protocols create this sort of inter-dependency > naturally. Do we have any actual numbers on how much efficiency can actually be = squeezed out of allowing compression dictionaries to create unbounded = dependencies between streams on common, non-pathological workloads? Cheers, Brian > There's a certain purity in having the flow control exert back > pressure all the way to the next layer up. Not being able to build a > transport with unconstrained writes is potentially creating > undesirable externalities on transport users. Now they have to worry > about flow control as well. Personally, I'm inclined to say that this > is something that application protocols and their users should be > exposed to. We've seen with the JS streams API that it's valuable to > have back pressure available at the application layer and also how it > is possible to do that relatively elegantly. >=20 > I'm almost certain that I haven't thought about all the potential > alternatives. I wonder if there isn't some experience with this > problem in SCTP that might lend some insights. --Apple-Mail=_F6232BD4-D1B9-4872-B19C-E5202C5D9B03 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpVuxQACgkQihK3vwvq RqPlTg//fxCx/P3sxYCL9eYJUU/qARLt7NC03alouPmgChb2Ya3P45qXlQDdh7AY aeMGuVxUqPVaVvJc2WKemb2zTebbHZcAZbE4MEoLi005ZlNnKeUrsp6J8QKYr5Zw 4mfY8m3zYoTUCapdhCkd8gmeNBcR5S4TgaRyfa/BS5NTbiAbVX3qq58OiBQTMJx/ 0kgC65HmwcDJapDvp8ZyA2/nVZEZB/GROJibD18VUp8qTLOSdHazdys4q81QPWh1 5Yrg7mJuGiCAF49MbwM20GBwMNJvxt/X4rfjXM5GPHEkJXSgRmMl78evh8aBm+Yo Zi+6FVqyVch8LeOQ6BOX57zW3qykefl4n8KE5kNGwnn/wm54kQK6WkqgoQhC6tzW jVeBogEyrPCJUcjQD1G22yEI1s8NYGiwIyd8WmL6DhVVBcyrS5Y5bSDbmpihpDvK nibWU6UbbzxsEllKNKEjbtn+5WO5a1LGp/pb91JNzfOp2kEjjZvC//JKgvNvDsK1 JDcZu2pgNSjFdxmqHauxDr5kGshKcrjJFGc0fIjSCRuntDzHOxHSNAPQmnWBG3f/ C8r8r65RMiHkpwNAR+SyMa0rGeNqS4GHWsJox6RMjZIV4KauOCAq2cmJn9qBiLDd Joqz10Oyjha7hx+5RvgL6+8MxP9fx2D62qsM3wqgVKD8dZoDlww= =SiqW -----END PGP SIGNATURE----- --Apple-Mail=_F6232BD4-D1B9-4872-B19C-E5202C5D9B03-- From nobody Tue Jan 9 23:05:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54FB0127078 for ; Tue, 9 Jan 2018 23:05:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPHTM5x6TrY1 for ; Tue, 9 Jan 2018 23:05:50 -0800 (PST) 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 8D7AC126D46 for ; Tue, 9 Jan 2018 23:05:50 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id u10so20869203qtg.2 for ; Tue, 09 Jan 2018 23:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=7GlQ3D6XyX5SelmArTdhUb85j1PyRcWp22xJN7yaGEQ=; b=mZP1j2WVZ9WWMP5ceh87Abs6v5wnTHoqRXOH3isW5pwtC9WXkPZhn4HuS9CzMCh7Wt 9PN7ucvoKdQU1zlfQWJ0JVlnJXhyVdO2R6KYVv0vGvh9h9NlrZaHTAZYX8mhxPnJp8Wq yu8wEp63Pa7iBUGd2bT3dTwutRkDytobAYdzJjX4KsMx/8TArvHZ0+zwFYz7nkVPs6bB i/VCyhpISCpL2r2VqwDuU3Bs3OSoMR/kNjpibjI7RiDvV5axdT/3X1Zl7F0Y8UDiIZ9S v+fePINuiiEuRSTuab0AaqZ9oJQibvHSHN/FfDc69NyY2uadqOYf0f3Toru2uxBz/rcW Vc7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=7GlQ3D6XyX5SelmArTdhUb85j1PyRcWp22xJN7yaGEQ=; b=WqPfTMWm4t/bj9QLR/o+bM7tKVWdnfXPLp88Bk8eE7tmxaHePISxSBy0EH8fc469fq r0OiGeDZVgSrcGmwv/r8hcWtFZdo3aIFdmrIRbg+j9ujLt/vWaOJjssI9Eds/zsyuPUZ +DPjQN43En8MnZkfV3Zokk6rPz1wR1NTW+6yufR4ka01RAFL4PHrt179ptkLi05sEwYd 1LtJ8qeOcayXtAs5+sb2ltZ0ifRFAP6bKjSd0ksegd5jwzPZmOGniYP98Mze/D2VAVJk AO0ESwiOArNRQLWS3Tvgbpj8bkRkWY7ij6nISZYKkL7C702ClI4YTU4SFV5xJPunMCoj 69Sw== X-Gm-Message-State: AKwxytcj7d+p6qKofvvBVVBmS68fggq8wNI84YNcG/Hdcigo+nbp5bgV Ov1jIXWlPJoxJCq6lyI6t9a1rA== X-Google-Smtp-Source: ACJfBosmVDAqyCGqmu4H568Bgn9x2bidMhhwiR73/Hh92sCJ7BWU9GplFcoAddmPKcWZrQWs5LdgHw== X-Received: by 10.237.47.228 with SMTP id m91mr25470769qtd.297.1515567949642; Tue, 09 Jan 2018 23:05:49 -0800 (PST) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id e63sm10433227qkb.46.2018.01.09.23.05.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2018 23:05:49 -0800 (PST) Date: Wed, 10 Jan 2018 02:05:43 -0500 From: Dmitri Tikhonov To: Jana Iyengar Cc: Martin Thomson , QUIC WG Subject: Re: Deadlocking in the transport Message-ID: <20180110070542.GA27331@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , Martin Thomson , QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 07:05:52 -0000 On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote: > Protocols that create inter-stream dependency should be able to express > that in priorities down to the transport, which I believe is expected to be > part of the API. I believe that handles this issue, doesn't it? When it comes to priorities, the QUIC I-D gives implementations some leeway [1]. One cannot guarantee that a conforming implementation will not deadlock. - Dmitri. 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6 From nobody Wed Jan 10 05:46:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80550127419 for ; Wed, 10 Jan 2018 05:46:30 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 aVokSJQHYdQp for ; Wed, 10 Jan 2018 05:46:28 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577DB12420B for ; Wed, 10 Jan 2018 05:46:28 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id f6so22475254ioh.8 for ; Wed, 10 Jan 2018 05:46:28 -0800 (PST) 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; bh=gxh9CNWPv2wiippUriu4/b8htj8+mrwo/YOrF8H9bCo=; b=iJiYsYemUvn05mvnnK3vYa8tInMRslJuJOdwfEu5ra7CsVrmw9sPYrWL4SVGuiZHfQ uwbpQGLs6XHdPC3T3xYPq+j6ZnpuFxMMa90iqt1XEBJ5MAf/jQvjeyDkJleNcir7Jzrr El+YCEYgAxtMs3byuXbORGkatoo2xLr7ap0IbAUACrKsh+o4W4/u9pA+XU1NQ7sjC36Y +IGqY8qCBGRvkjNlZK42wtvxxUUNoXKXjJMB2luFB9n3tdE6dRAgp5RHsvZ9TZeZuYfS /83+XMvi2MLHW26tvu+mkgzPz59F7+rCKsj1CU3xt9n2LsdH5TpHTL9bb06BPlcZA9rz gZ4Q== 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=gxh9CNWPv2wiippUriu4/b8htj8+mrwo/YOrF8H9bCo=; b=IUyEjaVBpIe3SxPiDOdOJe0q5v64Nu/wjp6FjEqy6iNI9mn8+6205OX0p7D2156/3+ eTWMoDWEOoc6eSWp2Ud+szenaBTeiqYt/IWd5rdjdF69rXnxSuL/6WYxLCTGNq9UBQ9X YiELiiKfKlVReME8wCWecmN6Q/AyJQ1BZwogzeFMKzqGytMg7JwcYuuwe0uuWD3CUSen xsKxs46GK9uaZJLuxp2bSiC20QKbJks/vlEW7FZB5Wu08SXIENFf/ftg5lDxgA9HPdp4 fn5wl2VMh0d1z4z/VA2BFfP1c4OXztqv8egIvQLGjL7v2UJ0VCRGeULZOGsWajocqFL+ txrw== X-Gm-Message-State: AKwxytenCVg7x1AELVXpCk57MEtAd4ExWJfK41Sg7CmtPwR8SEOSRWJv bPQL9G9PDkxBRuRgPfvs/gASKZc2G/FQ7X4CF14alA== X-Google-Smtp-Source: ACJfBovrAtcplx3XmRZt6tWgFHqolzrYY3X7nZwXv3Np3VG2c76osQyypxExHWG4/8B570nC63vhl4VvD01LksMtLBA= X-Received: by 10.107.132.24 with SMTP id g24mr18599473iod.283.1515591987350; Wed, 10 Jan 2018 05:46:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.82.17 with HTTP; Wed, 10 Jan 2018 05:46:06 -0800 (PST) In-Reply-To: <20180110070542.GA27331@ubuntu-dmitri> References: <20180110070542.GA27331@ubuntu-dmitri> From: Ian Swett Date: Wed, 10 Jan 2018 08:46:06 -0500 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="001a113f28a008772b05626c42b3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 13:46:30 -0000 --001a113f28a008772b05626c42b3 Content-Type: text/plain; charset="UTF-8" I would agree that #4 is the right direction. GQUIC also does #4, because it forces all headers to be written before any requests that may depend upon them are written. If the application knows there is a dependency, it should be the application's responsibility to deal with it, not the transport's, which also points to #4(or maybe #1). I also think there are use cases for data transfer that is not a stream and does not consume flow control, but I don't think they solve every problem and I don't think they should be necessary here. On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote: > > Protocols that create inter-stream dependency should be able to express > > that in priorities down to the transport, which I believe is expected to > be > > part of the API. I believe that handles this issue, doesn't it? > > When it comes to priorities, the QUIC I-D gives implementations > some leeway [1]. One cannot guarantee that a conforming > implementation will not deadlock. > > - Dmitri. > > 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6 > > --001a113f28a008772b05626c42b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would agree that #4 is the right direction.=C2=A0 GQUIC = also does #4, because it forces all headers to be written before any reques= ts that may depend upon them are written.

If the applica= tion knows there is a dependency, it should be the application's respon= sibility to deal with it, not the transport's, which also points to #4(= or maybe #1).

I also think there are use cases for= data transfer that is not a stream and does not consume flow control, but = I don't think they solve every problem and I don't think they shoul= d be necessary here.

On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Tue, Jan 09, 2018 at 10:49:28PM -0800, Ja= na Iyengar wrote:
> Protocols that create inter-stream dependency should be able to expres= s
> that in priorities down to the transport, which I believe is expected = to be
> part of the API. I believe that handles this issue, doesn't it?
When it comes to priorities, the QUIC I-D gives implementations
some leeway [1].=C2=A0 One cannot guarantee that a conforming
implementation will not deadlock.

=C2=A0 - Dmitri.

1. https://tools.ietf.org/html/= draft-ietf-quic-transport-08#section-10.6


--001a113f28a008772b05626c42b3-- From nobody Wed Jan 10 05:51:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 130E41275AB for ; Wed, 10 Jan 2018 05:51:30 -0800 (PST) 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 pX1KPKLo6yd6 for ; Wed, 10 Jan 2018 05:51:28 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 021CE12420B for ; Wed, 10 Jan 2018 05:51:27 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id k18so22485911ioc.11 for ; Wed, 10 Jan 2018 05:51:27 -0800 (PST) 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=Yl3EsbkKLj/+ujy/8DhT/Nc9TinX6YUNTDf4yqOacvk=; b=K3ZqAf/VdK92oiC4fRs69axHNlv1NkwYfLHFoy/zpt/rEnIFOZ/hnusqGTti33JWfO BAYK0hRSrT+6KZwzBI8ZraIAv1GDT1V/zipfq4+eDpIy7821vwXm/myip/Sw9FO7lWfV 27hy1UJAZwnQ9HG2VokYreZyjraTTegtnprhWpytDs9xEOOPi275uZW6slmJ70ObD1MA +OdV5TV5+kiIGJlk2zBQnV/IfktRpmXRxMeam5DoCqKtXVSlt05oUHaR42Dlbn8XFZkZ mYEwhgM1Mz0ueLtXHZDjXu32yi3pcqykec6Kp1w1xoMJq4sFOTgqN/4Z1YFu4bRVC1iP /ovw== 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=Yl3EsbkKLj/+ujy/8DhT/Nc9TinX6YUNTDf4yqOacvk=; b=aNT2IPt/TJedxZj0NiB3eDJ9ppI3F4PjutdAxpPPl5Nw6gffj3wSjZeOOQFzNkCn4q byLLXB+IkZNp0zxPdEiyO/BMcusiWmGDW0qdfTFs+c38R04nh9iIBOR7QcOS1zmi1tQa RuFFjhCTQfO6tCzFkrF2R0mH54tlPTZVNSXCXmy4TPJAWfy+QkS5jFsGcMwcIiNb64mm nrKowujiePzyIIAQFEubwOCXwciDCTbzFxGj+Ujuu9ZFFs9QDP6Dk+7i4I5T/MnrF45Z wHoncga4wb9v3c0WW3sKuM0Z5GbP9yE60FXle0jSZP4cdLtJ2h8yaDSAUSMgbEncRnJo OvEg== X-Gm-Message-State: AKGB3mLqGc8LlUrYkkFUJh0ouQtZWk5780Mnmmf69Hs0SRFcO/lkO2z+ /k9pv9oblQ2FJBYjVgIFrDkzv2o5H5GPYZQX75Y= X-Google-Smtp-Source: ACJfBov98WQnim3cVZjfEyOijX0eonKMJ5FIogVPEJ2dbL6lDGKViQ3xU1B6kWilnm1BFwRpNeIk3eKbPhwjr+hkchI= X-Received: by 10.107.57.3 with SMTP id g3mr19204217ioa.297.1515592287342; Wed, 10 Jan 2018 05:51:27 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 05:51:26 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180110070542.GA27331@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 05:51:26 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , QUIC WG , Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary="001a114ac180e957e805626c538d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 13:51:30 -0000 --001a114ac180e957e805626c538d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Blocking at source is not practical if feeding several very large files via a mmap pointer to the API for deferred round robin transmission so all files get equal opportunity to get through. In this case only small pieces could be delivered at a time before the allocation must check if there is are more transmission credits. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 10 January 2018 at 14.46.36, Ian Swett (ianswett@google.com) wrote: I would agree that #4 is the right direction. GQUIC also does #4, because it forces all headers to be written before any requests that may depend upon them are written. If the application knows there is a dependency, it should be the application's responsibility to deal with it, not the transport's, which also points to #4(or maybe #1). I also think there are use cases for data transfer that is not a stream and does not consume flow control, but I don't think they solve every problem and I don't think they should be necessary here. On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote: > > Protocols that create inter-stream dependency should be able to express > > that in priorities down to the transport, which I believe is expected t= o > be > > part of the API. I believe that handles this issue, doesn't it? > > When it comes to priorities, the QUIC I-D gives implementations > some leeway [1]. One cannot guarantee that a conforming > implementation will not deadlock. > > - Dmitri. > > 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6 > > --001a114ac180e957e805626c538d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Blocking at source i= s not practical if feeding several very large files via a mmap pointer to t= he API for deferred round robin transmission so all files get equal opportu= nity to get through. In this case only small pieces could be delivered at a= time before the allocation must check if there is are more transmission cr= edits.


<= div style=3D"font-family:helvetica,arial;font-size:13px">Kind Regards,
Mikkel Fahn=C3= =B8e J=C3=B8rgensen


On 10 J= anuary 2018 at 14.46.36, Ian Swett (= ianswett@google.com) wrote:

I would agree that #4 is the right direction.=C2=A0 GQUIC also does #4, because it forces all headers to be written before any requests that may depend upon them are written.

If the application knows there is a dependency, it should be the application's responsibility to deal with it, not the transport's, which also points to #4(or maybe #1).

I also think there are use cases for data transfer that is not a stream and does not consume flow control, but I don't think they solve every problem and I don't think they should be necessary here.

On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote:
> Protocols that create inter-stream dependency should be able to express
> that in priorities down to the transport, which I believe is expected to be
> part of the API. I believe that handles this issue, doesn't it?

When it comes to priorities, the QUIC I-D gives implementations
some leeway [1].=C2=A0 One cannot guarantee that a conforming
implementation will not deadlock.

=C2=A0 - Dmitri.

1. https://tools.ietf.org/html/= draft-ietf-quic-transport-08#section-10.6


--001a114ac180e957e805626c538d-- From nobody Wed Jan 10 06:53:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C4312751F for ; Wed, 10 Jan 2018 06:53:33 -0800 (PST) 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 mua9CUy8huqL for ; Wed, 10 Jan 2018 06:53:27 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 DD51E12700F for ; Wed, 10 Jan 2018 06:53:22 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id r6so16469795itr.3 for ; Wed, 10 Jan 2018 06:53:22 -0800 (PST) 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=nXYVc896YUXxJqJ50LJDgAqhkSmjdMFlwj8Xr/lxeUI=; b=p6DxBdgm5B1t5lqZa0DmcmqxOWJJ1BQCnfTeGdoUuktbbyW0wl3C7+5Z1JXZr5wHjK b2wbXigCnez4i/a+zSt8QFx77aFHE1VDLQ814K5tMqG7phf2/vE3nRQPkXpUuRbujlxj AkALDuBC2+AjfiINUUI8ycgb77c2NTkMH/3IGdIKJNwU75XYAiuCREl5YVkM2boKGYR8 vVRZwkM7Cce+p0cc8ODhzd4nJ0t+Vg59FJKReyelZMVF4GA3l+7JC1lfsTU0BaneiG46 hsPzn9KP57UGiygJ/z7Q5WtLtcaUwpBng+jA/9EDhw/gnrG7W+ap6PPt8f3jodM66Vk5 DiBg== 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=nXYVc896YUXxJqJ50LJDgAqhkSmjdMFlwj8Xr/lxeUI=; b=dZ0nnF67CIrdkbitcO8FYelANnssBkvlm34ezMpwA9y7cJb+uNN16359Np3hTDHz9F 4CB+kpp0zhEcpGI/MpRaiS88dUwzxP0kQcWopn+V99Yywj2iP5DP5KqD5XnoBSxZPG5+ MCCdPsi5i4THXHhbhktx7SwMhLxrgyhNn79+Iq0cNfpbUkUuIi2xpuBGeGUFyx+CFEf0 ITqtwZu619PaVjjcSPIMHL6FVz9LvAA2lCxhIElHSofWwQ2HC2+JPb0Ykg6Bn6V6gKvk NSQmvUNcJoI3zRTFNYay7vpvvAf6c7QV80AhcV20b5NybQzzekMyPF0ZwreBkZf8yj0Z u5VQ== X-Gm-Message-State: AKwxytfPblUo0Drq+6q2qB4wHDYDNwjEfEIAKBjF69JkWtDSyq4ypNQC 2TNQ8/bgNU1wcT6sJcrx0zDjRpVtgRpeoeHEOv4= X-Google-Smtp-Source: ACJfBovsVwLo0FbYSfYE78p89GRAHmqlF/oZL2iP4bbS2Z7kROF6VN8IdZG4f1AV/X+IyygJVsO045k6Cc/Oe/mONoA= X-Received: by 10.36.188.198 with SMTP id n189mr12565235ite.91.1515596002254; Wed, 10 Jan 2018 06:53:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 06:53:21 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180110070542.GA27331@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 06:53:21 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , QUIC WG , Martin Thomson , Ian Swett Content-Type: multipart/alternative; boundary="94eb2c11416056698005626d3158" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 14:53:33 -0000 --94eb2c11416056698005626d3158 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For what it is worth, my APACK-02 proposal attempts to solve the problem by blocking at source, but only for this particular use of QUIC. https://github.com/dvidelabs/apack/blob/master/apack-02.md#encoder-blocking If the header compression overall ensures to not use more than certain amount of credits before blocking, and if the other streams make sure to not consume any more that the overall credit minus the header block, then this should suffice from a cursory view. As to my previous example with large files, the api needs to have some sort of resource management to ensure background feeds do not over allocate. An actual complex stream dependency scheme is probably not a good idea, but streams could be divided into resource groups with allotted bandwidth. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 10 January 2018 at 14.51.26, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Blocking at source is not practical if feeding several very large files via a mmap pointer to the API for deferred round robin transmission so all files get equal opportunity to get through. In this case only small pieces could be delivered at a time before the allocation must check if there is are more transmission credits. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 10 January 2018 at 14.46.36, Ian Swett (ianswett@google.com) wrote: I would agree that #4 is the right direction. GQUIC also does #4, because it forces all headers to be written before any requests that may depend upon them are written. If the application knows there is a dependency, it should be the application's responsibility to deal with it, not the transport's, which also points to #4(or maybe #1). I also think there are use cases for data transfer that is not a stream and does not consume flow control, but I don't think they solve every problem and I don't think they should be necessary here. On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote: > > Protocols that create inter-stream dependency should be able to express > > that in priorities down to the transport, which I believe is expected t= o > be > > part of the API. I believe that handles this issue, doesn't it? > > When it comes to priorities, the QUIC I-D gives implementations > some leeway [1]. One cannot guarantee that a conforming > implementation will not deadlock. > > - Dmitri. > > 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6 > > --94eb2c11416056698005626d3158 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = For what it is worth= , my APACK-02 proposal attempts to solve the problem by blocking at source,= but only for this particular use of QUIC.


If the header compression overall ensures to not use mo= re than certain amount of credits before blocking, and if the other streams= make sure to not consume any more that the overall credit minus the header= block, then this should suffice from a cursory view.

As to my previous example with large files= , the api needs to have some sort of resource management to ensure backgrou= nd feeds do not over allocate. An actual complex stream dependency scheme i= s probably not a good idea, but streams could be divided into resource grou= ps with allotted bandwidth.


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


On 10 January 2018 at 14.51.26, Mikkel Fahn=C3=B8e J=C3=B8rgens= en (mikkelfj@gmail.com) wrote:

Blocking at source is not practical if feeding several very large files via a mmap pointer to the API for deferred round robin transmission so all files get equal opportunity to get through. In this case only small pieces could be delivered at a time before the allocation must check if there is are more transmission credits.


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


On 10 January 2018 at 14.46.36, Ian Swett (ianswett@google.com) wrote:

I would agree that #4 is the right direction.=C2=A0 GQUIC also does #4, because it forces all headers to be written before any requests that may depend upon them are written.

If the application knows there is a dependency, it should be the application's responsibility to deal with it, not the transport's, which also points to #4(or maybe #1).

I also think there are use cases for data transfer that is not a stream and does not consume flow control, but I don't think they solve every problem and I don't think they should be necessary here.
On Wed, Jan 10, 2018 at 2:05 AM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Tue, Jan 09, 2018 at 10:49:28PM -0800, Jana Iyengar wrote:
> Protocols that create inter-stream dependency should be able to express
> that in priorities down to the transport, which I believe is expected to be
> part of the API. I believe that handles this issue, doesn't it?

When it comes to priorities, the QUIC I-D gives implementations
some leeway [1].=C2=A0 One cannot guarantee that a conforming
implementation will not deadlock.

=C2=A0 - Dmitri.

1. https://tools.ietf.org/html/= draft-ietf-quic-transport-08#section-10.6


--94eb2c11416056698005626d3158-- From nobody Wed Jan 10 07:39:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 555F212D862; Wed, 10 Jan 2018 07:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 FXp2wHXeUCDN; Wed, 10 Jan 2018 07:39:32 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id BE1C212751F; Wed, 10 Jan 2018 07:39:32 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 43C021B00062; Wed, 10 Jan 2018 15:38:56 +0000 (GMT) Message-ID: <5A563390.8050403@erg.abdn.ac.uk> Date: Wed, 10 Jan 2018 15:38:56 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Eggert, Lars" CC: "Black, David" , QUIC WG , "tsvwg@ietf.org" Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> In-Reply-To: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:39:34 -0000 On 09/01/2018, 11:11, Eggert, Lars wrote: > Hi, > > would someone clarify what the intended relationship of the mechanism > described in the document and QUIC is? For example, is the intention > here that QUIC should implement this, is this unrelated, or anything > in between? > The work originates from updates to the IPv6 base spec, and the need to consider how to do PLPMTUD for transports other than TCP. There's practical code for UDP-Options, and SCTP, and that is presently evolving with the Spec. I suspect someone could use the final method with QUIC - since it's also a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - please get in touch if that is on your radar. > Asking, because if there is an intended relationship, it would be good > to discuss this sooner rather than later. > Thanks, > Lars > Best wishes, Gorry >> On 2017-12-15, at 7:27, Black, David > > wrote: >> >> I’m tardy in getting to this action item from the TSVWG meeting in >> Singapore … >> The TSVWG chairs are considering adoption of the draft >> "Packetization Layer Path MTU Discovery for Datagram Transports". >> This draft has been discussed at the previous IETF meeting and on the >> list, and the chairs are now looking for input from the group to help >> inform whether TSVWG should adopt this draft. >> * Please send an email to this list if you would like to see this >> work adopted in TSVWG, or you have comments on the suitability for >> adoption. >> * Please indicate if you are willing to REVIEW such a document during >> its development. >> Please send all notes of support/comments to the TSVWG list or the WG >> chairs by the date above. >> Best wishes, >> David and Wes. >> (TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as >> he is an author of this draft.] >> [The time period for this adoption call is longer than usual to allow >> for the winter holidays – may yours be joyous!] >> Abstract >> This document describes a robust method for Path MTU Discovery >> (PMTUD) for datagram Packetization layers. The method allows a >> Packetization layer (or a datagram application that uses it) to probe >> an network path with progressively larger packets to determine a >> maximum packet size. The document describes as an extension to RFC >> 1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for >> IPv4 and IPv6. This provides functionally for datagram transports >> that is equivalent to the Packetization layer PMTUD specification for >> TCP, specified in RFC4821. > From nobody Wed Jan 10 09:47:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B4D12DA4E for ; Wed, 10 Jan 2018 09:47:44 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 2RWHqc1JDkwv for ; Wed, 10 Jan 2018 09:47:41 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 7C1B812DA4F for ; Wed, 10 Jan 2018 09:47:25 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id p139so364209itb.1 for ; Wed, 10 Jan 2018 09:47:25 -0800 (PST) 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=mfr6TtVQ3wUbUl4oBvAxHsXqmaS155jjAPOATMMdhtw=; b=O9G7IAQjLBgfzhGcCvSi2RZ/WbLAKhmnZLWLEemRyNkFuHNJAsdgDXip1nKArexKEM YbeWYeHObVVP+g+t4sYqPW7r4wRyZyX56baMGIxf+fhNLO9urP/ZKkl3ZIKcTOItYm/5 O/ybLnQsWCjY/vrzIyAtSpdH2gYn8D84RMC0s03J2bg/KmceGfhy6GGhvHnUUfftfmcp IYztvYypk2i/SYiDn9IVVIC3MDS+X2wD/rxhP1N5vVsnuR3gzvQf3/DgxP31dzgsOJon 304l8Q0wlHSlj1XUuZazF/hl2333Y536uMBcJ7FSnCjSFa6q6CpgdzirsHrAvC4SiOaX 3ldw== 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=mfr6TtVQ3wUbUl4oBvAxHsXqmaS155jjAPOATMMdhtw=; b=eLxLN6zgFJRmXi9BYIqv75MUba8cOtLWX0/Qry1mYe7y+9C9ZTPem0JW5dXejLLFNV 1pbDUL3K0d6iZ7GlWEQ1G6HaGRG3cdel2i5cA9Zu/1f1ktzxZw0GKLGeleOaiSlXSIHG pN5Ena2Cp0r33tZgvzoiK38ZWxJmFxrD02TfsGfUbJH86Ox/T0Nu2WhCRxZCzGCTKg92 ciiUNVQYm4nbFVykshxP4xBlzdA40YinP2EhiGEUJSwKxMZb8t1Td4lm3Y9b+Hil5mKG Iipatm7kHYi+68acD6H96689sFs8oHBcbsc+IP9v5h+fvo0CaqY37YQPAasghcIm0Pv/ vRMQ== X-Gm-Message-State: AKwxytdmy/JGeC2B3W4v15SvMWK5nmHJXK26w/TJyJunF5jv2MMboEfz Mc0Fpu/LASKcjjbzmUaulaJsUzNbwbp1JFcV0ZSTSaFLnA== X-Google-Smtp-Source: ACJfBovSBr8iHHXUhJ3cOdWag9/bJ4iK2gf6vbbHCHn9CYtlKJYRFLBYL2dJoXqp8jdVAbOBArjmIeT4JZUxO7YszFo= X-Received: by 10.36.175.79 with SMTP id l15mr12812905iti.8.1515606444088; Wed, 10 Jan 2018 09:47:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.156.203 with HTTP; Wed, 10 Jan 2018 09:47:03 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Wed, 10 Jan 2018 09:47:03 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="f403045dc016b8eccd05626f9fc1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 17:47:44 -0000 --f403045dc016b8eccd05626f9fc1 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 9, 2018 at 10:49 PM, Jana Iyengar wrote: > Martin, > > You are right that this isn't a new concern, and that this is worth noting > somewhere, perhaps in the applicability/API doc. > > The crux of this issue is that there's structure in application data that > the transport is unaware of. Specifically, there are dependencies among > application data units that is opaque to the transport. Using the transport > buffers as a part of handling these dependencies seems like a bad idea, > especially since the transport is likely to make decisions about flow > window updates based on rate at which data is consumed out of the receive > buffer(s). GQUIC does this, and so does every respectable TCP receiver > implementation. > > The SCTP API avoids this problem by not allowing the application to read > specific stream data out of the socket buffers. The receiving app receives > data that could belong to any stream and has to demux after reading out of > the socket. (Note that SCTP does not have per-stream flow control, so the > receive side here is more like SPDY/TCP, modulo HoL blocking at the > transport.) > > Protocols that create inter-stream dependency should be able to express > that in priorities down to the transport, which I believe is expected to be > part of the API. I believe that handles this issue, doesn't it? > > I thought priorities wouldn't solve the problem, but now I am not so sure. Here's an example we've been using in the compression design group: o Client sends requests A, B and on streams A, B. o Server receives requests, sends responses A, B. o the compression scheme allows inter-stream dependencies, so B's compressed header ends up depending on A's. There is a small prefix in each compressed header block the tells the client this. The idea is that the client can read the prefix, but will not read the rest until the dependency is satisfied on its end. o suppose A's header was only partially written so far (this is what we assumed, but I'm not sure this makes sense if A has priority over B) o and that due to sending A+B's (partial) responses the server is now connection-level flow control blocked. o Before the client receives A's header, client decides to cancel A, so it does STOP_SENDING/RST_STREAM on A. o e.g. the resource A is no longer desired, perhaps because the user scrolled and A no longer needed to render the on-screen area. o server receives STOP_SENDING/RST_Swhere the proxy treats streams as opaque and forwards dataTREAM on A, it resets it's side of A. o this will undo A's outstanding flow-control debt, but that will not be enough to resend A's full header (on another stream), since the adjustment to the connection level only corresponds to the partial header sent so far. I think priorities actually do help solve this in the following sense. It makes a variation of #4. A write can occur, even without immediately consuming flow control, but the priority does ensure it will get flow control when it needs it. This isn't necessarily HQ priorities though. A workable, but less performant variation, might be to say that if the transport does buffer writes, it must service buffered writes in a global FIFO order. With priorities, the part where A sends a partial header seems invalid. The header compression does have requirements that headers be encoded strictly sequentially, so partial header write doesn't make sense there. The counter example given was a proxy, but I'm not sure that it is reasonable to guarantee that QUIC proxies can always be oblivious to mapping level semantics. In the case of HTTP and header compression, it seems especially counter-intuitive to me, since most cases will not have a 1:1 upstream downstream connection topology. > - jana > > On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson > wrote: > >> Building a complex application protocol on top of QUIC continues to >> produce surprises. >> >> Today in the header compression design team meeting we discussed a >> deadlocking issue that I think warrants sharing with the larger group. >> This has implications for how people build a QUIC transport layer. It >> might need changes to the API that is exposed by that layer. >> >> This isn't really that new, but I don't think we've properly addressed >> the problem. >> >> >> ## The Basic Problem >> >> If a protocol creates a dependency between streams, there is a >> potential for flow control to deadlock. >> >> Say that I send X on stream 3 and Y on stream 7. Processing Y >> requires that X is processed first. >> >> X cannot be sent due to flow control but Y is sent. This is always >> possible even if X is appropriately prioritized. The receiver then >> leaves Y in its receive buffer until X is received. >> >> The receiver cannot give flow control credit for consuming Y because >> it can't consume Y until X is sent. But the sender needs flow control >> credit to send X. We are deadlocked. >> >> It doesn't matter whether the stream or connection flow control is >> causing the problem, either produces the same result. >> >> (To give some background on this, we were considering a preface to >> header blocks that identified the header table state that was >> necessary to process the header block. This would allow for >> concurrent population of the header table and sending message that >> depended on the header table state that is under construction. A >> receiver would read the identifier and then leave the remainder of the >> header block in the receive buffer until the header table was ready.) >> >> >> ## Options >> >> It seems like there are a few decent options for managing this. These >> are what occurred to me (there are almost certainly more options): >> >> 1. Don't do that. We might concede in this case that seeking the >> incremental improvement to compression efficiency isn't worth the >> risk. That is, we might make a general statement that this sort of >> inter-stream blocking is a bad idea. >> >> 2. Force receivers to consume data or reset streams in the case of >> unfulfilled dependencies. The former seems like it might be too much >> like magical thinking, in the sense that it requires that receivers >> conjure more memory up, but if the receiver were required to read Y >> and release the flow control credit, then all would be fine. For >> instance, we could require that the receiver reset a stream if it >> couldn't read and handle data. It seems like a bad arrangement >> though: you either have to allocate more memory than you would like or >> suffer the time and opportunity cost of having to do Y over. >> >> 3. Create an exception for flow control. This is what Google QUIC >> does for its headers stream. Roberto observed that we could >> alternatively create a frame type that was excluded from flow control. >> If this were used for data that had dependencies, then it would be >> impossible to deadlock. It would be similarly difficult to account >> for memory allocation, though if it were possible to process on >> receipt, then this *might* work. We'd have to do something to address >> out-of-order delivery though. It's possible that the stream >> abstraction is not appropriate in this case. >> >> 4. Block the problem at the source. It was suggested that in cases >> where there is a potential dependency, then it can't be a problem if >> the transport refused to accept data that it didn't have flow control >> credit for. Writes to the transport would consume flow control credit >> immediately. That way applications would only be able to write X if >> there was a chance that it would be delivered. Applications that have >> ordering requirements can ensure that Y is written after X is accepted >> by the transport and thereby avoid the deadlock. Writes might block >> rather than fail, if the API wasn't into the whole non-blocking I/O >> thing. The transport might still have to buffer X for other reasons, >> like congestion control, but it can guarantee that flow control isn't >> going to block delivery. >> >> >> ## My Preference >> >> Right now, I'm inclined toward option 4. Option 1 seems a little too >> much of a constraint. Protocols create this sort of inter-dependency >> naturally. >> >> There's a certain purity in having the flow control exert back >> pressure all the way to the next layer up. Not being able to build a >> transport with unconstrained writes is potentially creating >> undesirable externalities on transport users. Now they have to worry >> about flow control as well. Personally, I'm inclined to say that this >> is something that application protocols and their users should be >> exposed to. We've seen with the JS streams API that it's valuable to >> have back pressure available at the application layer and also how it >> is possible to do that relatively elegantly. >> >> I'm almost certain that I haven't thought about all the potential >> alternatives. I wonder if there isn't some experience with this >> problem in SCTP that might lend some insights. >> >> > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --f403045dc016b8eccd05626f9fc1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jan 9, 2018 at 10:49 PM, Jana Iyengar <jri@google.com> wrote:
Martin,

You are right that this isn't a new co= ncern, and that this is worth noting somewhere, perhaps in the applicabilit= y/API doc.

The crux of this issue is that there= 9;s structure in application data that the transport is unaware of. Specifi= cally, there are dependencies among application data units that is opaque t= o the transport. Using the transport buffers as a part of handling these de= pendencies seems like a bad idea, especially since the transport is likely = to make decisions about flow window updates based on rate at which data is = consumed out of the receive buffer(s). GQUIC does this, and so does every r= espectable TCP receiver implementation.

The SCTP A= PI avoids this problem by not allowing the application to read specific str= eam data out of the socket buffers. The receiving app receives data that co= uld belong to any stream and has to demux after reading out of the socket. = (Note that SCTP does not have per-stream flow control, so the receive side = here is more like SPDY/TCP, modulo HoL blocking at the transport.)

Protocols that create inter-stream dependency should be ab= le to express that in priorities down to the transport, which I believe is = expected to be part of the API. I believe that handles this issue, doesn= 9;t it?

=

I thought priori= ties wouldn't solve the problem, but now I am not so sure.=C2=A0 =C2=A0= =C2=A0

Here's an example we've been using = in the compression design group:

=C2=A0o=C2=A0 =C2= =A0Client sends requests A, B and on streams A, B.
=C2=A0o=C2=A0 = =C2=A0Server receives requests, sends responses A, B.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0o the compression scheme allows inter-stream dependencies,= so B's compressed header ends up depending on A's.=C2=A0 =C2=A0The= re=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is a small prefix in = each compressed header block the tells the client this.=C2=A0 The idea is t= hat the client can read the prefix,=C2=A0
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 but will not read the rest until the dependency is satisfied = on its end.=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0= =C2=A0o suppose A's header was only partially written so far (this is = what we assumed, but I'm not sure this makes sense if A has priority ov= er B)
=C2=A0 =C2=A0 =C2=A0 =C2=A0o and that due to sending A+B= 9;s (partial) responses the server is now connection-level flow control blo= cked.
o=C2=A0 Before the client receives A's header, client de= cides to cancel A, so it does STOP_SENDING/RST_STREAM on A.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 o e.g. the resource A is no longer desired, perhap= s because the user scrolled and A no longer needed to render the on-screen = area.
=C2=A0o=C2=A0 =C2=A0server receives STOP_SENDING/RST_Swhere the p= roxy treats streams as opaque and forwards dataTREAM on A, it resets it'= ;s side of A.
=C2=A0 =C2=A0 =C2=A0 =C2=A0o this will undo A's outst= anding flow-control debt, but that will not be enough to resend A's ful= l header (on another stream), since the adjustment to=C2=A0
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 the connection level only corresponds to the parti= al header sent so far.

I think priorities actually do help sol= ve this in the following sense.=C2=A0 =C2=A0It makes a variation of #4.=C2= =A0 =C2=A0A write can occur, even without immediately consuming flow contro= l, but the priority does ensure it will get flow control when it needs it.<= /div>
This isn't necessarily HQ priorities though.=C2=A0 =C2=A0A workable= , but less performant variation, might be to say that if the transport does= buffer writes, it must service buffered writes in a global FIFO order.

With priorities, the part where A sends a partial header seems in= valid.=C2=A0 =C2=A0The header compression does have requirements that heade= rs be encoded strictly sequentially, so partial header write doesn't ma= ke sense there.=C2=A0

The counter example given was a proxy, b= ut I'm not sure that it is reasonable to guarantee that QUIC proxies ca= n always be oblivious to mapping level semantics.=C2=A0 In the case of HTTP= and header compression, it seems especially counter-intuitive to me, since= most cases will not have a 1:1 upstream downstream connection topology.






=C2=A0 =C2=A0 =C2= =A0=C2=A0
=C2=A0 =C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 =C2=A0=C2= =A0
=C2=A0
=
- jana

On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson &= lt;martin.tho= mson@gmail.com> wrote:
Building a complex application protocol on top of QUIC conti= nues to
produce surprises.

Today in the header compression design team meeting we discussed a
deadlocking issue that I think warrants sharing with the larger group.
This has implications for how people build a QUIC transport layer.=C2=A0 It=
might need changes to the API that is exposed by that layer.

This isn't really that new, but I don't think we've properly ad= dressed
the problem.


## The Basic Problem

If a protocol creates a dependency between streams, there is a
potential for flow control to deadlock.

Say that I send X on stream 3 and Y on stream 7.=C2=A0 Processing Y
requires that X is processed first.

X cannot be sent due to flow control but Y is sent.=C2=A0 This is always possible even if X is appropriately prioritized.=C2=A0 The receiver then leaves Y in its receive buffer until X is received.

The receiver cannot give flow control credit for consuming Y because
it can't consume Y until X is sent.=C2=A0 But the sender needs flow con= trol
credit to send X.=C2=A0 We are deadlocked.

It doesn't matter whether the stream or connection flow control is
causing the problem, either produces the same result.

(To give some background on this, we were considering a preface to
header blocks that identified the header table state that was
necessary to process the header block.=C2=A0 This would allow for
concurrent population of the header table and sending message that
depended on the header table state that is under construction.=C2=A0 A
receiver would read the identifier and then leave the remainder of the
header block in the receive buffer until the header table was ready.)


## Options

It seems like there are a few decent options for managing this.=C2=A0 These=
are what occurred to me (there are almost certainly more options):

1. Don't do that.=C2=A0 We might concede in this case that seeking the<= br> incremental improvement to compression efficiency isn't worth the
risk.=C2=A0 That is, we might make a general statement that this sort of inter-stream blocking is a bad idea.

2. Force receivers to consume data or reset streams in the case of
unfulfilled dependencies.=C2=A0 The former seems like it might be too much<= br> like magical thinking, in the sense that it requires that receivers
conjure more memory up, but if the receiver were required to read Y
and release the flow control credit, then all would be fine.=C2=A0 For
instance, we could require that the receiver reset a stream if it
couldn't read and handle data.=C2=A0 It seems like a bad arrangement though: you either have to allocate more memory than you would like or
suffer the time and opportunity cost of having to do Y over.

3. Create an exception for flow control.=C2=A0 This is what Google QUIC
does for its headers stream.=C2=A0 Roberto observed that we could
alternatively create a frame type that was excluded from flow control.
If this were used for data that had dependencies, then it would be
impossible to deadlock.=C2=A0 It would be similarly difficult to account for memory allocation, though if it were possible to process on
receipt, then this *might* work.=C2=A0 We'd have to do something to add= ress
out-of-order delivery though.=C2=A0 It's possible that the stream
abstraction is not appropriate in this case.

4. Block the problem at the source.=C2=A0 It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for.=C2=A0 Writes to the transport would consume flow control credit=
immediately.=C2=A0 That way applications would only be able to write X if there was a chance that it would be delivered.=C2=A0 Applications that have=
ordering requirements can ensure that Y is written after X is accepted
by the transport and thereby avoid the deadlock.=C2=A0 Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O
thing.=C2=A0 The transport might still have to buffer X for other reasons,<= br> like congestion control, but it can guarantee that flow control isn't going to block delivery.


## My Preference

Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint.=C2=A0 Protocols create this sort of inter-dependency<= br> naturally.

There's a certain purity in having the flow control exert back
pressure all the way to the next layer up.=C2=A0 Not being able to build a<= br> transport with unconstrained writes is potentially creating
undesirable externalities on transport users.=C2=A0 Now they have to worry<= br> about flow control as well.=C2=A0 Personally, I'm inclined to say that = this
is something that application protocols and their users should be
exposed to.=C2=A0 We've seen with the JS streams API that it's valu= able to
have back pressure available at the application layer and also how it
is possible to do that relatively elegantly.

I'm almost certain that I haven't thought about all the potential alternatives.=C2=A0 I wonder if there isn't some experience with this problem in SCTP that might lend some insights.





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

--f403045dc016b8eccd05626f9fc1-- From nobody Wed Jan 10 10:23:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF3E127871 for ; Wed, 10 Jan 2018 10:23:04 -0800 (PST) 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 XKjkTufNfHTm for ; Wed, 10 Jan 2018 10:23:02 -0800 (PST) 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 9405512D77E for ; Wed, 10 Jan 2018 10:23:02 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eZL1g-0001kg-JV for quic@ietf.org; Wed, 10 Jan 2018 19:23:01 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eZL1b-0007NM-D6 for quic@ietf.org; Wed, 10 Jan 2018 13:22:58 -0500 Received: (qmail 9432 invoked from network); 10 Jan 2018 18:22:53 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2018 18:22:52 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C153) In-Reply-To: <5A563390.8050403@erg.abdn.ac.uk> Date: Wed, 10 Jan 2018 08:22:50 -1000 Cc: "Eggert, Lars" , "Black, David" , "tsvwg@ietf.org" , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hBLWOU3oxkI4vPhZr/z+MQXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKNPILOWNIp50KNu32/z0EB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUw8uEFOG92DI83j3LMNDNEdZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPzFy2BMVafZkKGCe45ASM DXlktEzRL2aN64ozk8iKu6gHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFirtlAtdsrBTAcAoY5WeLmsibYT4C2qF2lnc18bVJn64Q cGNbbUfVtyF2zetYzSLaI+V/fXqHoTlLNtJsRIkQZDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTvLpZVaBCgo9IFgw1OrNwYFjI1dRH6f16eQCtvwPkeoxzBkc1CTpvaEJjkrbHF6v+l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 18:23:05 -0000 > On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst wrote:= > ... >=20 > I suspect someone could use the final method with QUIC - since it's also a= UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - pleas= e get in touch if that is on your radar. The initial packets in QUIC are sent with min IPv6 MTU. During the initial e= xchange, the nodes send the maximum packet size that they might accept. QUIC= does not specify the actual probing algorithm but does specify that PMTU is= per path. Several QUIC implementations do PMTUD already, building simple probes with Q= UIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC p= ackets in UDP with segmentation turned off. If the probe packet is acknowled= ged, the applications know that this much MTU can be sent. Note the encrypted part. Replacing such mechanisms by a clear text exchange i= s not desirable. -- Christian Huitema=20= From nobody Wed Jan 10 10:41:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689BC12D72F for ; Wed, 10 Jan 2018 10:41:23 -0800 (PST) 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 4ZtXlocZarr3 for ; Wed, 10 Jan 2018 10:41:20 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE775124BAC for ; Wed, 10 Jan 2018 10:41:19 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id d21so13384343qkj.3 for ; Wed, 10 Jan 2018 10:41:19 -0800 (PST) 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=BG4AyqCXJzlG5An/SKq5W/u+Tx+kiQAxVKPqB9g2vHI=; b=Lptm1SsOfC/XTR44MdPZJy+WQ7Fy3Nysn19RUNW1BCa4gGDlIDVuZrb1aqSGHGPC78 f7S120GbwePIwcCWnHf+SLlwlO0+5YIZfMDPxycED1YPUZw6m1JSaXPrlBrcdp4DQ3SX 71lMIN8GLcVTEFuyZN6xm0hJiJ8fYpmJsbBewTn52meaaMSi3sdin9yXK3AwvDyUY4Wg 5aR4mqf0Qj8tsnIArE+O2MjWDxOHBN1x1aOzG37ZQzqmvTTUouLKIeQOm+qdEGGBmINm C/eWCd2KKz+URwkEoT5G5cQmmH7NBcXanPA9WaZnv8uXP7BXV/rIqbdmyM09lC41fMn/ blPw== 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=BG4AyqCXJzlG5An/SKq5W/u+Tx+kiQAxVKPqB9g2vHI=; b=ZqtD4vSzNxJS6+zSLJYvb9wIufD161LnlPoK+GNN3PI/6GQQ9Y1l7ABlJx9U+A2ru1 MW7FdRMOHKePzy3oicpN7y+fjHMcTUMFrXMv+AQlAvVUgJB+Qx1Qiw86bbJlkIoCR5kd 5FjNQMRvk+v0riN+DBMrOFUaifihxFA75m/wDU3jAHC/KR5CN3+c7MAe3fzHXGYWf/mr JAx7FVrs+PjzfeHn7UFNMWJXcw3DgG9VGb79ui7fmrM0dCQTrcG5tgYmPfT1rIUP525L NMLt1D2aZi+UjSApjYItk0EcSdEvanVnYlEwDFU/Q7Mq4rPIgUKSTrM1DrnWfgi+O5pE QQdA== X-Gm-Message-State: AKwxytef1Dx6Au/d4va0woKntfMOpUlTtA/savjvyYWdZ6fugz8L0kiL +rkmQ82mFCSxJm9CC13HlN7W8JI8mknO5LCxm1I= X-Google-Smtp-Source: ACJfBos94I0u+ZMSlGXi7XFHV7RTAIwys2ug0qzl1JLXCa+3u9GN8x7VL4804IPY0SDYcZr6FYeROazMEjBydYKBuuc= X-Received: by 10.55.50.83 with SMTP id y80mr26522704qky.347.1515609678513; Wed, 10 Jan 2018 10:41:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Wed, 10 Jan 2018 10:40:48 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 10 Jan 2018 10:40:48 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1146f7d48198a70562706012" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 18:41:23 -0000 --001a1146f7d48198a70562706012 Content-Type: text/plain; charset="UTF-8" Howdy, I think there are two cases being intermingled here, and I think it would be useful to pull them back apart. Comments to that end in-line. On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson wrote: > Building a complex application protocol on top of QUIC continues to > produce surprises. > > Today in the header compression design team meeting we discussed a > deadlocking issue that I think warrants sharing with the larger group. > This has implications for how people build a QUIC transport layer. It > might need changes to the API that is exposed by that layer. > > This isn't really that new, but I don't think we've properly addressed > the problem. > > > ## The Basic Problem > > If a protocol creates a dependency between streams, there is a > potential for flow control to deadlock. > > Say that I send X on stream 3 and Y on stream 7. Processing Y > requires that X is processed first. > > X cannot be sent due to flow control but Y is sent. This is always > possible even if X is appropriately prioritized. The receiver then > leaves Y in its receive buffer until X is received. > > The receiver cannot give flow control credit for consuming Y because > it can't consume Y until X is sent. But the sender needs flow control > credit to send X. We are deadlocked. > > I think there are two cases here. In case one, the transport itself cannot consume Y until X is sent, because X is needed to make Y's content semantically available to the transport. In that case, the deadlock case you give is a truly fatal error and building a transport that allowed this error case to occur would be a very bad notion. The second case is one in which the protocol using the transport cannot access Y's semantic content until X is received. In that case, it has three potential strategies. One is not to permit the dependency to occur at all; as you note, lots of applications have inherent dependencies or common optimizations (e.g. FEC) that use this strategy. This turns into a limit in the scope of what can use QUIC if this is the required strategy. Two is is for the using application/protocol to set up and manage its own buffers so that it can take Y out of the receive buffer and wait for X to arrive without blocking the transport. While that might be magical thinking for some using protocols of QUIC, it's not clear that it always would be, as an application protocol built with QUIC as a transport in mind could do it. There are video cases I've worked on in the past where this buffer-at-layer-above-the-network was the default, because multiple networks were simultaneously being used to build the video playout buffer. Three is to manage the writes to the network so the deadlock is unlikely to occur (your option 4, or something that manages priorities with sufficient strictness that it guarantees X is always available when Y is). For the case you're describing, I think strategy 3/option 4 is right. But I don't think we ought to rule out strategy one and two for all using protocols. If you have a protocol that doesn't require or can easily avoid these dependencies being split across streams, you get option one for cheap. If you have an application/protocol that's built with the idea of the application managing its own buffers for resolving these dependencies, two is practical rather than magical. Just my two cents, Ted It doesn't matter whether the stream or connection flow control is > causing the problem, either produces the same result. > > (To give some background on this, we were considering a preface to > header blocks that identified the header table state that was > necessary to process the header block. This would allow for > concurrent population of the header table and sending message that > depended on the header table state that is under construction. A > receiver would read the identifier and then leave the remainder of the > header block in the receive buffer until the header table was ready.) > > > ## Options > > It seems like there are a few decent options for managing this. These > are what occurred to me (there are almost certainly more options): > > 1. Don't do that. We might concede in this case that seeking the > incremental improvement to compression efficiency isn't worth the > risk. That is, we might make a general statement that this sort of > inter-stream blocking is a bad idea. > > 2. Force receivers to consume data or reset streams in the case of > unfulfilled dependencies. The former seems like it might be too much > like magical thinking, in the sense that it requires that receivers > conjure more memory up, but if the receiver were required to read Y > and release the flow control credit, then all would be fine. For > instance, we could require that the receiver reset a stream if it > couldn't read and handle data. It seems like a bad arrangement > though: you either have to allocate more memory than you would like or > suffer the time and opportunity cost of having to do Y over. > > 3. Create an exception for flow control. This is what Google QUIC > does for its headers stream. Roberto observed that we could > alternatively create a frame type that was excluded from flow control. > If this were used for data that had dependencies, then it would be > impossible to deadlock. It would be similarly difficult to account > for memory allocation, though if it were possible to process on > receipt, then this *might* work. We'd have to do something to address > out-of-order delivery though. It's possible that the stream > abstraction is not appropriate in this case. > > 4. Block the problem at the source. It was suggested that in cases > where there is a potential dependency, then it can't be a problem if > the transport refused to accept data that it didn't have flow control > credit for. Writes to the transport would consume flow control credit > immediately. That way applications would only be able to write X if > there was a chance that it would be delivered. Applications that have > ordering requirements can ensure that Y is written after X is accepted > by the transport and thereby avoid the deadlock. Writes might block > rather than fail, if the API wasn't into the whole non-blocking I/O > thing. The transport might still have to buffer X for other reasons, > like congestion control, but it can guarantee that flow control isn't > going to block delivery. > > > ## My Preference > > Right now, I'm inclined toward option 4. Option 1 seems a little too > much of a constraint. Protocols create this sort of inter-dependency > naturally. > > There's a certain purity in having the flow control exert back > pressure all the way to the next layer up. Not being able to build a > transport with unconstrained writes is potentially creating > undesirable externalities on transport users. Now they have to worry > about flow control as well. Personally, I'm inclined to say that this > is something that application protocols and their users should be > exposed to. We've seen with the JS streams API that it's valuable to > have back pressure available at the application layer and also how it > is possible to do that relatively elegantly. > > I'm almost certain that I haven't thought about all the potential > alternatives. I wonder if there isn't some experience with this > problem in SCTP that might lend some insights. > > --001a1146f7d48198a70562706012 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

I think there are two cases being= intermingled here, and I think it would be useful to pull them back apart.= =C2=A0 Comments to that end in-line.

On Tue, Jan 9, 2018 at 10:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Building a complex application protocol on top of QUIC continues= to
produce surprises.

Today in the header compression design team meeting we discussed a
deadlocking issue that I think warrants sharing with the larger group.
This has implications for how people build a QUIC transport layer.=C2=A0 It=
might need changes to the API that is exposed by that layer.

This isn't really that new, but I don't think we've properly ad= dressed
the problem.


## The Basic Problem

If a protocol creates a dependency between streams, there is a
potential for flow control to deadlock.

Say that I send X on stream 3 and Y on stream 7.=C2=A0 Processing Y
requires that X is processed first.

X cannot be sent due to flow control but Y is sent.=C2=A0 This is always possible even if X is appropriately prioritized.=C2=A0 The receiver then leaves Y in its receive buffer until X is received.

The receiver cannot give flow control credit for consuming Y because
it can't consume Y until X is sent.=C2=A0 But the sender needs flow con= trol
credit to send X.=C2=A0 We are deadlocked.


I think there are two cases here.=C2= =A0 In case one, the transport itself cannot consume Y until X is sent, bec= ause X is needed to make Y's content semantically available to the tran= sport.=C2=A0 In that case, the deadlock case you give is a truly fatal erro= r and building a transport that allowed this error case to occur would be a= very bad notion.

The second case is one in which = the protocol using the transport cannot access Y's semantic content unt= il X is received.=C2=A0 In that case, it has three potential strategies.=C2= =A0 One is not to permit the dependency to occur at all; as you note, lots = of applications have inherent dependencies or common optimizations (e.g. FE= C) that use this strategy.=C2=A0 This turns into a limit in the scope of wh= at can use QUIC if this is the required strategy.

<= div>Two is is for the using application/protocol to set up and manage its o= wn buffers so that it can take Y out of the receive buffer and wait for X t= o arrive without blocking the transport.=C2=A0 While that might be magical = thinking for some using protocols of QUIC, it's not clear that it alway= s would be, as an application protocol built with QUIC as a transport in mi= nd could do it.=C2=A0 There are video cases I've worked on in the past = where this buffer-at-layer-above-the-network was the default, because = multiple networks were simultaneously being used to build the video playout= buffer.=C2=A0

Three is to manage the writes = to the network so the deadlock is unlikely to occur (your option 4, or some= thing that manages priorities with sufficient strictness that it guarantees= X is always available when Y is).=C2=A0

For = the case you're describing, I think strategy 3/option 4 is right.=C2=A0= But I don't think we ought to rule out strategy one and two for all us= ing protocols.=C2=A0 If you have a protocol that doesn't require or can= easily avoid these dependencies being split across streams, you get option= one for cheap.=C2=A0 If you have an application/protocol that's built = with the idea of the application managing its own buffers for resolving the= se dependencies,=C2=A0 two is practical rather than magical.
= =C2=A0
Just my two cents,

Ted
<= div>
It doesn't matter whether the stream or connection flow control is
causing the problem, either produces the same result.

(To give some background on this, we were considering a preface to
header blocks that identified the header table state that was
necessary to process the header block.=C2=A0 This would allow for
concurrent population of the header table and sending message that
depended on the header table state that is under construction.=C2=A0 A
receiver would read the identifier and then leave the remainder of the
header block in the receive buffer until the header table was ready.)


## Options

It seems like there are a few decent options for managing this.=C2=A0 These=
are what occurred to me (there are almost certainly more options):

1. Don't do that.=C2=A0 We might concede in this case that seeking the<= br> incremental improvement to compression efficiency isn't worth the
risk.=C2=A0 That is, we might make a general statement that this sort of inter-stream blocking is a bad idea.

2. Force receivers to consume data or reset streams in the case of
unfulfilled dependencies.=C2=A0 The former seems like it might be too much<= br> like magical thinking, in the sense that it requires that receivers
conjure more memory up, but if the receiver were required to read Y
and release the flow control credit, then all would be fine.=C2=A0 For
instance, we could require that the receiver reset a stream if it
couldn't read and handle data.=C2=A0 It seems like a bad arrangement though: you either have to allocate more memory than you would like or
suffer the time and opportunity cost of having to do Y over.

3. Create an exception for flow control.=C2=A0 This is what Google QUIC
does for its headers stream.=C2=A0 Roberto observed that we could
alternatively create a frame type that was excluded from flow control.
If this were used for data that had dependencies, then it would be
impossible to deadlock.=C2=A0 It would be similarly difficult to account for memory allocation, though if it were possible to process on
receipt, then this *might* work.=C2=A0 We'd have to do something to add= ress
out-of-order delivery though.=C2=A0 It's possible that the stream
abstraction is not appropriate in this case.

4. Block the problem at the source.=C2=A0 It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for.=C2=A0 Writes to the transport would consume flow control credit=
immediately.=C2=A0 That way applications would only be able to write X if there was a chance that it would be delivered.=C2=A0 Applications that have=
ordering requirements can ensure that Y is written after X is accepted
by the transport and thereby avoid the deadlock.=C2=A0 Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O
thing.=C2=A0 The transport might still have to buffer X for other reasons,<= br> like congestion control, but it can guarantee that flow control isn't going to block delivery.


## My Preference

Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint.=C2=A0 Protocols create this sort of inter-dependency<= br> naturally.

There's a certain purity in having the flow control exert back
pressure all the way to the next layer up.=C2=A0 Not being able to build a<= br> transport with unconstrained writes is potentially creating
undesirable externalities on transport users.=C2=A0 Now they have to worry<= br> about flow control as well.=C2=A0 Personally, I'm inclined to say that = this
is something that application protocols and their users should be
exposed to.=C2=A0 We've seen with the JS streams API that it's valu= able to
have back pressure available at the application layer and also how it
is possible to do that relatively elegantly.

I'm almost certain that I haven't thought about all the potential alternatives.=C2=A0 I wonder if there isn't some experience with this problem in SCTP that might lend some insights.


--001a1146f7d48198a70562706012-- From nobody Wed Jan 10 10:57:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313AB127023; Wed, 10 Jan 2018 10:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 yX05TtvDGR7N; Wed, 10 Jan 2018 10:57:29 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A6C1200B9; Wed, 10 Jan 2018 10:57:29 -0800 (PST) Received: from [10.0.3.2] (unknown [212.201.121.94]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 2533672106C12; Wed, 10 Jan 2018 19:57:25 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 From: Michael Tuexen In-Reply-To: <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> Date: Wed, 10 Jan 2018 19:57:22 +0100 Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 18:57:32 -0000 > On 10. Jan 2018, at 19:22, Christian Huitema = wrote: >=20 >=20 >> On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst = wrote: >> ... >>=20 >> I suspect someone could use the final method with QUIC - since it's = also a UDP-based transport. I don' knopw of anyone planning PMTUD for = QUIC - please get in touch if that is on your radar. >=20 > The initial packets in QUIC are sent with min IPv6 MTU. During the = initial exchange, the nodes send the maximum packet size that they might = accept. QUIC does not specify the actual probing algorithm but does = specify that PMTU is per path. >=20 > Several QUIC implementations do PMTUD already, building simple probes = with QUIC's Ping and Padding frames. Probes are then encrypted, and sent = as QUIC packets in UDP with segmentation turned off. If the probe packet = is acknowledged, the applications know that this much MTU can be sent. Your description of the probe packets is the one we have in mind. It = just needs to be specified. The more interesting part of the document is the way (when and which = size) you probe, not how you probe. >=20 > Note the encrypted part. Replacing such mechanisms by a clear text = exchange is not desirable. And not intended... Best regards Michael >=20 > -- Christian Huitema=20 From nobody Wed Jan 10 11:34:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6512711B for ; Wed, 10 Jan 2018 11:34:15 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 dc46LfV0lhcq for ; Wed, 10 Jan 2018 11:34:13 -0800 (PST) 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 3391F1200B9 for ; Wed, 10 Jan 2018 11:34:13 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id z132so45456ywd.9 for ; Wed, 10 Jan 2018 11:34:13 -0800 (PST) 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=fWRymcIvApO+itdwS2vGlfKOFrd+ygZxMC8qSCo9/oI=; b=SswZWm5JBnh/3PgJHLyarOlYG1S/WIrUEZ3lT33HjLnJuIO0bRgpbXu4wB0Cdvmk7N A0DVqq/O8bncqd7QfXIWzmL1Oiz/OFer5pmCws09r1I7LjolCS9BKv4f0xVJPcOErGK+ iTUOpFKCi97WwlHDYeueEjiKWWgg8J2qh8IzISsAwLonOpt2t5K4c/ZRWUTR2Y7YlR9n h6MSdXN7IfuQ9s2XxDly1pztntggBd4bb2bd45NR9xokFe6IZooN02IbOqVKteTGW5Bl AFlkHz8FihC2fV7svpGRc55Q/yg4dmqnR5ruqGizhlnqaYtlQFhhDxS8UB6uXFMuKZ0W W1Gw== 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=fWRymcIvApO+itdwS2vGlfKOFrd+ygZxMC8qSCo9/oI=; b=h1XIZMENO/doRLa3UhmxIaFM6Cgnbpdt7GhO/Sa+4OjtDvzLgegc1kb2G/IaRpJ762 sQ5a4yxA3kUC5Kj7NLkEHD7klfJ+4x3IO8A+pW4Fx8ceCF5mQE9OY9TUV92vzJhsZf91 Tryc44mdz7macRNlTKUYueYBrzgbHebwC51vzWWD7OZ2klUHd2KmAHWO9K7CxUnc1kv/ SqtRiOXDoY/E+X3A/7ad+PZTdDmHsZNE8d4kmKbbY1q3sQsPbtPcylIhUJVXltEO3FnM PiRugad1UYN8TKFTngcrl6PgVAzsb4chXCsnacn4t+JNc4avYchcknuFUWIgSS0M2KCZ jpBA== X-Gm-Message-State: AKwxytf+MTk6oSxQ203l1yvR9rbp5VUbKc7OcvkO1yAy6AisXf7W6exb KiuXbCx4dwjQK6H1G+S9Cs7IIzTEfSkIBwx9o3ulyw== X-Google-Smtp-Source: ACJfBouwKUl/ki1WSbcnIocwj1K2iNJesJ5gbdDGyXr0SeWwDZENv/Q6UoxC+aXBq6ThpnQIadHR1zl13wqF4sFLOew= X-Received: by 10.129.87.130 with SMTP id l124mr2605511ywb.139.1515612852068; Wed, 10 Jan 2018 11:34:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 11:34:11 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 10 Jan 2018 11:34:11 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: "Charles 'Buck' Krasic" Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="001a113aa1ecaad6200562711dde" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 19:34:15 -0000 --001a113aa1ecaad6200562711dde Content-Type: text/plain; charset="UTF-8" On Wed, Jan 10, 2018 at 9:47 AM, Charles 'Buck' Krasic wrote: [pruning] I think priorities actually do help solve this in the following sense. It > makes a variation of #4. A write can occur, even without immediately > consuming flow control, but the priority does ensure it will get flow > control when it needs it. > This isn't necessarily HQ priorities though. A workable, but less > performant variation, might be to say that if the transport does buffer > writes, it must service buffered writes in a global FIFO order. > I agree. That's what I meant by priorities solving it -- that the shared resource (connection-level flow buffer), if consumed in priority order at the sender, avoids this deadlock. This assumes that the application can express this to the transport of course. With priorities, the part where A sends a partial header seems invalid. > The header compression does have requirements that headers be encoded > strictly sequentially, so partial header write doesn't make sense there. > > The counter example given was a proxy, but I'm not sure that it is > reasonable to guarantee that QUIC proxies can always be oblivious to > mapping level semantics. In the case of HTTP and header compression, it > seems especially counter-intuitive to me, since most cases will not have a > 1:1 upstream downstream connection topology. > Yup, agreed. --001a113aa1ecaad6200562711dde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 10, 2018 at 9:47 AM, Charles 'Buck' Krasic <ckrasic@google.com> wrote:

[pruning]

I think priorities actually do help sol= ve this in the following sense.=C2=A0 =C2=A0It makes a variation of #4.=C2= =A0 =C2=A0A write can occur, even without immediately consuming flow contro= l, but the priority does ensure it will get flow control when it needs it.<= /div>
This isn't necessarily HQ priorities though.=C2=A0 =C2=A0A workable= , but less performant variation, might be to say that if the transport does= buffer writes, it must service buffered writes in a global FIFO order.

I agree. That's wh= at I meant by priorities solving it -- that the shared resource (connection= -level flow buffer), if consumed in priority order at the sender, avoids th= is deadlock. This=C2=A0 assumes that the application can express this to th= e transport of course.

<= div dir=3D"ltr">
With p= riorities, the part where A sends a partial header seems invalid.=C2=A0 =C2= =A0The header compression does have requirements that headers be encoded st= rictly sequentially, so partial header write doesn't make sense there.= =C2=A0

The counter example given was a proxy, but I'm not = sure that it is reasonable to guarantee that QUIC proxies can always be obl= ivious to mapping level semantics.=C2=A0 In the case of HTTP and header com= pression, it seems especially counter-intuitive to me, since most cases wil= l not have a 1:1 upstream downstream connection topology.
=

Yup, agreed.

--001a113aa1ecaad6200562711dde-- From nobody Wed Jan 10 11:47:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7324F12711B for ; Wed, 10 Jan 2018 11:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiHJW5JGoyDr for ; Wed, 10 Jan 2018 11:47:23 -0800 (PST) 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 41BAA1200B9 for ; Wed, 10 Jan 2018 11:47:23 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id a8so389739qkb.8 for ; Wed, 10 Jan 2018 11:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=sqIFdkNpkuy8C9RVXdmU8gJJmwGm5ddM5Aqgewg8XGA=; b=F051L5MOovv4PtxaIn4Ven4BTi7KYOSIHbBs8/5Qp5lRc370I5arF9ci3hC5OSA3Qo iTWKtL3Cr/OZTpnPYeOulSkQ1ZrJG5Kr4HF1pHOq8YZ3tLBgvxP//XAhJsG1EbhpZMH3 /wlREGWyxi3jPPyx1bqa6BwO9dUEnl83YNrntQ0dcHaEfNI0lbzWNgg69jnCnfAEdn/n wlk5DUuJYHLIv9Kj7M0iLN76g4MMUhElGNGCQi8Ssn3Skmq0fy2hFOoFDAINGbtgeWn/ izcRJnCBTF1Tor9OlpN3F32sssMTc2sit6G3iylMeOxB6UxH9nnYl/Q26l4cjiI2VL5M qe2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=sqIFdkNpkuy8C9RVXdmU8gJJmwGm5ddM5Aqgewg8XGA=; b=RwxGMD3EFnKkZbJNRkA5EilX3vG9y07TD32pgqNWryYG9+IlNVqD6dPhHF2/maFTuT edQUfqDHNs0I1q+7Osg6GlUAzsohg9I9om6Vt6jA9Wf2Udt+s2EGfV1mjvcNwueKySYa KYNenND/9VPWN54BrxB/7s/IAQXTyesqtZ8XGRswxNHGmE5lRiWXgZcEJ0ndY6BYHLDb UHpMT1VPpzW+1jqRra06ZMg8TJh5t6Hj0RkxTmbrIsze1/FiFVbWgPNDkQkHkB5b/s// tbOUdy89MJDD67Di6n/Ghfoxk3+MXCP52YXvSYzDLanc0wwJFKPqI7GrA2rVeD9s+FvJ RwxQ== X-Gm-Message-State: AKwxyteCXDZBSTqiK6Tw/XQ7nPGQBWJ19ahkJOPy39TePZj5dGjuCfew YIq14KT1bwJfJNJcE157M+aF/A== X-Google-Smtp-Source: ACJfBou8dxXum7hfJzTGxA3ChP5uMJULd8w3TLtBH+aDy/Q7fXG8zuGp35EI2CIMfeTvSdLB4vg+JQ== X-Received: by 10.55.112.199 with SMTP id l190mr27593174qkc.342.1515613642436; Wed, 10 Jan 2018 11:47:22 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id y45sm11238688qtc.20.2018.01.10.11.47.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 11:47:21 -0800 (PST) Date: Wed, 10 Jan 2018 14:47:17 -0500 From: Dmitri Tikhonov To: Jana Iyengar Cc: Charles 'Buck' Krasic , QUIC WG , Martin Thomson Subject: Re: Deadlocking in the transport Message-ID: <20180110194716.GA30573@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , Charles 'Buck' Krasic , QUIC WG , Martin Thomson References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:47:26 -0000 On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote: > I agree. That's what I meant by priorities solving it -- that the shared > resource (connection-level flow buffer), if consumed in priority order at > the sender, avoids this deadlock. This assumes that the application can > express this to the transport of course. Even if the application can express it, the transport is not guaranteed to consume the data in priority order: see the specification [1]. - Dmitri. 1. https://tools.ietf.org/html/draft-ietf-quic-transport-08#section-10.6 From nobody Wed Jan 10 12:04:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2457712D7EF for ; Wed, 10 Jan 2018 12:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 wkygYcysJfxM for ; Wed, 10 Jan 2018 12:04:14 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB05612D849 for ; Wed, 10 Jan 2018 12:04:13 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id m19so76157ywh.12 for ; Wed, 10 Jan 2018 12:04:13 -0800 (PST) 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; bh=vth9AVvu/bZWeDwHY68nM2+6rDilq8HD16b60aP2jN0=; b=dFWVfT5yLh/gJqmi05vKgGcWc9FN3vYp3QtU1D/XnA3rc2MIFpHfN1ZNOg7147nct+ DhbvS5/sRuyZ8aqWZqDv/O6dMQlzHmmiLk3BREyIiQldUBDm95xytPLIjoGgganM4Bc3 URdQ42ASq78uMHCH4EnbV6Pwa9TA/INCRQtAJXBf5doxqvKvyg7mHaO1svahN8f/iAhG r6EzamsdaqqIjMesL1nfe2Mk5V7ZNjUKIZl7APgT5qAshLEtBiDYJ6RFW0Li7ypXpjgA uO/d+i48xtHOaGjo8tl7Uq28gOw3JjwkU3sa0qUxmmO95QtS/q6HztJWdTBP8ZTmraH4 +6lg== 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=vth9AVvu/bZWeDwHY68nM2+6rDilq8HD16b60aP2jN0=; b=nM6cgRCZCBsTvvTAUgwLXrVzRXpTI3UqgPi1M9RLn7z0uBMO94jWPbxqEHxUrtzqmc sLc58/cwrtYKGE0dDLvmU0StxxQEZfEs7c/d6Hm++jaeW4J9rmXk7tagvD6y24/OA4iB sccsclbnblF677XXlEll3bK1sFBZzdM/Yhe2uUw8J+1QVohybE6Gpnxfs9RbEB3aievH hYOZcQO6GC71rp2bo7XeV+2ajtXHLJ+HmSFT2wSRL3AuHlhTGYyXKF3x5WsbzcHgU8UC ZWIYldWb0J5N+UswJu184lD/9M2qQrNksdfE7Opos+/wvW4PhkQhkiH4CzORlOYvjrK4 2m5g== X-Gm-Message-State: AKwxytfnb5fWFoSY0Tm11Opy+16SYvZ+4/6Tcf1Lp4lFLlSAZbcvE0yE eusopk/r6KzrmnyPyrcmZZ2zlffcuA6fGsmtTwccVg== X-Google-Smtp-Source: ACJfBotStJWIE60flrL/i8pJGBB6ACgj9/CeEyvH2dGP6/qLV8ShlT/p+5SQfYZwg/6GzZiBd94lgpEdh4eSRooswZQ= X-Received: by 10.129.87.130 with SMTP id l124mr2678825ywb.139.1515614652531; Wed, 10 Jan 2018 12:04:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 12:04:11 -0800 (PST) In-Reply-To: <20180110194716.GA30573@ubuntu-dmitri> References: <20180110194716.GA30573@ubuntu-dmitri> From: Jana Iyengar Date: Wed, 10 Jan 2018 12:04:11 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , "Charles 'Buck' Krasic" , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a113aa1ecfbbabc0562718875" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 20:04:16 -0000 --001a113aa1ecfbbabc0562718875 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote: > > I agree. That's what I meant by priorities solving it -- that the shared > > resource (connection-level flow buffer), if consumed in priority order at > > the sender, avoids this deadlock. This assumes that the application can > > express this to the transport of course. > > Even if the application can express it, the transport is not guaranteed > to consume the data in priority order: see the specification [1]. I don't see the text in that section that says otherwise. Under what conditions does the transport invert application stream priorities? --001a113aa1ecfbbabc0562718875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov <= dtikhonov@litespeedtech.com> wrote:
On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iy= engar wrote:
> I agree. That's what I meant by priorities solving it -- that the = shared
> resource (connection-level flow buffer), if consumed in priority order= at
> the sender, avoids this deadlock. This=C2=A0 assumes that the applicat= ion can
> express this to the transport of course.

Even if the application can express it, the transport is not guarant= eed
to consume the data in priority order: see the specification [1].

I don't see the text in that section that says o= therwise. Under what conditions does the transport invert application strea= m priorities?=C2=A0
--001a113aa1ecfbbabc0562718875-- From nobody Wed Jan 10 12:06:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669ED12711B for ; Wed, 10 Jan 2018 12:06:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM_iOraFaYkw for ; Wed, 10 Jan 2018 12:06:50 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB51E126DED for ; Wed, 10 Jan 2018 12:06:49 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id j185so567466qkc.5 for ; Wed, 10 Jan 2018 12:06:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rALQYFvAOJAzJuSvN6JCR+3ObsgFJDr4l6JTr/58QSg=; b=Ke/zVu8SvKzbjTfQ3LP2iuZK9EuwgMAXNI3yeC6bXYLut33LbyZIDhvqBL2afU93La 2A/zWdBiyFM6oG1n4BZDhgQm6BTtmUTQFWdCRIfSUD3InpH9Sr8Fq0nb+DPBQg/bI+Bt JHDJqtizZ4vlDSCNUuFYKit+xuZgt6uJ1X+RdsAgozD2Ano9e4/qdVZbdVORVzEJ3M+E AGo4qaEsqUt/LV7cgdo9X6/gHexfPgzof9hviONG+LNTW43rX9PaDGj6j8a+GA0mErjK aV8aLrDcSEKCeb05fgtISqAwS8uBPB+JmdaRwq8D1ayjtbEJGb7HpM3qXxGYlKP67w0A XTFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=rALQYFvAOJAzJuSvN6JCR+3ObsgFJDr4l6JTr/58QSg=; b=QViOwx1+pUGcy9doCwaYmSHdBWQjoF2LsAbWSKZrPGVWqbF4+LbHoq79fdnnbFlOz7 oXrCDIzfBIXQpvyWN2fIRdMjBoHkPRSIyGsbfxRhiBq6zI4R30hThemSfkBl3XFcUctg erwQ7xKztC88Uj2ligwD0RDTLN1pJVXg0WFRjx/zDBgbt26lp/NOCyGTMYlR6kDrM7a8 jVM5M+Rs4iKNlALpqZmwUQpiAK7AC1HHYFV9TptGTSJPwx7DGQqcTwn9swX+J2IwyxOc zlfWFL2gDhQb8Of+AFv/U74Is169Ji5OW6vX8xmPxdB6lhWdz4+nq6QGp7caQNOmTpaT Yjtw== X-Gm-Message-State: AKwxytdxJAjSnn7aNVHuQmKWDfwWexuRYD7uBx+xYbgpuUMKe4H2iorU Aqe+YALcPZuB2FAXeC/TNZPijg== X-Google-Smtp-Source: ACJfBousY+GDlsGLiVBbE6lN4I6vp2sJE7gCgHRKnyCMA32bMfmmMqC7bV//c3tn0DomS/ANWuZ2FA== X-Received: by 10.55.53.205 with SMTP id c196mr16849894qka.311.1515614808885; Wed, 10 Jan 2018 12:06:48 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id s41sm1767429qtk.39.2018.01.10.12.06.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 12:06:48 -0800 (PST) Date: Wed, 10 Jan 2018 15:06:46 -0500 From: Dmitri Tikhonov To: Jana Iyengar Cc: Charles 'Buck' Krasic , QUIC WG , Martin Thomson Subject: Re: Deadlocking in the transport Message-ID: <20180110200646.GB30573@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , Charles 'Buck' Krasic , QUIC WG , Martin Thomson References: <20180110194716.GA30573@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:06:52 -0000 On Wed, Jan 10, 2018 at 12:04:11PM -0800, Jana Iyengar wrote: > On Wed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > > > On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote: > > > I agree. That's what I meant by priorities solving it -- that the shared > > > resource (connection-level flow buffer), if consumed in priority order at > > > the sender, avoids this deadlock. This assumes that the application can > > > express this to the transport of course. > > > > Even if the application can express it, the transport is not guaranteed > > to consume the data in priority order: see the specification [1]. > > I don't see the text in that section that says otherwise. Under what > conditions does the transport invert application stream priorities? This is the text: " When deciding which streams to dedicate resources to, QUIC " SHOULD use the information provided by the application. ^^^^^^ - Dmitri. From nobody Wed Jan 10 12:14:18 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2545912711B for ; Wed, 10 Jan 2018 12:14:17 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 lcW3xbeBNi_t for ; Wed, 10 Jan 2018 12:14:15 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 3984C126DED for ; Wed, 10 Jan 2018 12:14:15 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id a82so110403ybg.1 for ; Wed, 10 Jan 2018 12:14:15 -0800 (PST) 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; bh=24r5AYcA6zaSkjKYjvoBqpQSvV2B28lI066lc/iMTkE=; b=vNuDohiUiS9MXGvYeuN/RrbvM587YanRVIIWwWK35vV0xIsXLuA+JuHg/9Owuv3ekm 2Y6Ynh5Ar8/f4jFMuVVnmOjc1KMb9noFzI6/Le3YJ57cXzZ6zhvUKIyNvmKrbnim5+Gm 0+EMRG6gd5t/tG+2bPXRLbZ9umGuNfXWSkx9ap9RCAxxvH7XwWY8RSAB7Ny/kzmYwsfE S+Q4tvB75B6IhnM4yuCNNDUtzmKnQDmedrj7B8pDZ4jVjGNz0Z48SXmobqLZ8psSGYLf qJ3pCIsUWOZdKMtPH2K5ILWQDkGJ38ZFWu0Usaykug0xER5eYa9BI42wFfWOJMN5+JlW /E0g== 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=24r5AYcA6zaSkjKYjvoBqpQSvV2B28lI066lc/iMTkE=; b=UoE2wMDMNK7ABhffvhX9EnKG5HqUamL0mCLD7Wfob2wdyCBISRlDHp693AcvTGO+h+ gjapZDuRYtiz8O+G3bfj/T0FY7pq1JbosWHdyd+WHdzGT+dQm6SZdXZ9hhmH0f4/4hxb 6f2WE6C8JM4E5pj9A5pT3D7e1VMVDqbytN954UaE3dyMZ4phEyA3fCmEMSorsTbHHUo1 0AxLpQQfsXbTtqmI3eWHjdNpWrfAYEMEz6krWyWVObYkIVoD1XWy/29tQa+NUlWgyUMU Ll30Ey1aUcwYV2a8Z/2UxOtVkKWHY3MdY1goxWsf5dQd/V7c6ZWf3pLJm2cltNTwzmL3 DwdQ== X-Gm-Message-State: AKwxyteNRXmGvR8AzEccRYuiRhP9Muj9WMVuV33CydrLdxmYhxjK73HC mkfpT606x6IlzvPdEgoXwQ7xq1C5dQuNtBE8SDGbUQ== X-Google-Smtp-Source: ACJfBouk4OZ+Xo8498XAHXa8m/ZIOUzVk3OL/Psl99VgTbgABtyZ2P+mQ1itynMsL1tIfvgIUaQHcf/quL8R74t9dik= X-Received: by 10.37.74.132 with SMTP id x126mr1093598yba.91.1515615254119; Wed, 10 Jan 2018 12:14:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 12:14:13 -0800 (PST) In-Reply-To: <20180110200646.GB30573@ubuntu-dmitri> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> From: Jana Iyengar Date: Wed, 10 Jan 2018 12:14:13 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , "Charles 'Buck' Krasic" , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a113e652ad729ca056271ac14" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 20:14:17 -0000 --001a113e652ad729ca056271ac14 Content-Type: text/plain; charset="UTF-8" SHOULD is pretty strong. It's not a guarantee, but then a transport implementation that doesn't do it is expected to know what it's doing. We could include language in this section about priorities being important to avoid deadlocks when an application has dependencies across streams. On Wed, Jan 10, 2018 at 12:06 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Wed, Jan 10, 2018 at 12:04:11PM -0800, Jana Iyengar wrote: > > On Wed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov < > > dtikhonov@litespeedtech.com> wrote: > > > > > On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote: > > > > I agree. That's what I meant by priorities solving it -- that the > shared > > > > resource (connection-level flow buffer), if consumed in priority > order at > > > > the sender, avoids this deadlock. This assumes that the application > can > > > > express this to the transport of course. > > > > > > Even if the application can express it, the transport is not guaranteed > > > to consume the data in priority order: see the specification [1]. > > > > I don't see the text in that section that says otherwise. Under what > > conditions does the transport invert application stream priorities? > > This is the text: > > " When deciding which streams to dedicate resources to, QUIC > " SHOULD use the information provided by the application. > ^^^^^^ > > - Dmitri. > --001a113e652ad729ca056271ac14 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SHOULD is pretty strong. It's not a guarantee, but the= n a transport implementation that doesn't do it is expected to know wha= t it's doing.
We could include language in this section about prior= ities being important to avoid deadlocks when an application has dependenci= es across streams.

On Wed, Jan 10, 2018 at 12:06 PM, Dmitri Tikhonov <= dtikhonov@litespeedtech.com> wrote:
On Wed, Jan 10, 2018 at 12= :04:11PM -0800, Jana Iyengar wrote:
> On Wed, Jan 10, 2018 at 11:47 AM, Dmitri Tikhonov <
> dtikhonov@litespeedtech= .com> wrote:
>
> > On Wed, Jan 10, 2018 at 11:34:11AM -0800, Jana Iyengar wrote:
> > > I agree. That's what I meant by priorities solving it --= that the shared
> > > resource (connection-level flow buffer), if consumed in prio= rity order at
> > > the sender, avoids this deadlock. This=C2=A0 assumes that th= e application can
> > > express this to the transport of course.
> >
> > Even if the application can express it, the transport is not guar= anteed
> > to consume the data in priority order: see the specification [1].=
>
> I don't see the text in that section that says otherwise. Under wh= at
> conditions does the transport invert application stream priorities?
This is the text:

=C2=A0 " When deciding which streams to dedicate resources to, QUIC =C2=A0 " SHOULD use the information provided by the application.
=C2=A0 =C2=A0 ^^^^^^

=C2=A0 - Dmitri.

--001a113e652ad729ca056271ac14-- From nobody Wed Jan 10 12:24:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA8E12711B for ; Wed, 10 Jan 2018 12:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAYHAilYLFH0 for ; Wed, 10 Jan 2018 12:24:01 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A11126DED for ; Wed, 10 Jan 2018 12:24:00 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id j137so645191qke.10 for ; Wed, 10 Jan 2018 12:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=E3+esAT+xlCJlOl8rLTfQ1hW79GPnyDTSvWEdztQu3c=; b=XU7ZICrCAlRBtcc3HP810RijNoT5fnvQjqa0dWP2aK6hnsjExe7lNR74qlxwmOFYH9 YVzz1h3VzJ0welandGc+Tb7ZHLD+eYgceJaAC43ruvdzs0i1bB535usVi/bGjEhk/Rnj p6E3RDmqiEa3wDKmT5ubrEhnbjjh/s+xWufa2KHrgFk8pEjmox/1mpkRRFWpihzlZBqc +rnknl/nymhEdD2MV6SpYxzUJ7ZeXkYetn6c3McKudQXwwVKPzPvtIRiTnmrYdVtF5M0 iEaqpmMj0Xw15myEUFDeD8qfoL7UHWwYeN1k14A1ai99F0D+XwIIX4dGtHoFziEOmfTe VTeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=E3+esAT+xlCJlOl8rLTfQ1hW79GPnyDTSvWEdztQu3c=; b=MLq6w170ap9RB+3beXFOlWHNvuWRJS6VUJ7NcgvX6YRcAUJ2ZG26GwgEMl9IqOjsCi dZoIsklMPBF0L1r+MWpg6uHI6hXZPCms4LlEImLvukMuIs5rGc3cDj4PeObPQRwQ+HFb Df9JmcyL24kcu51iLGSNFBCwwqDqc2LuD71BXHzzWLYsa9G8mlkC4zDz/x83RPf3uwq3 ljSxlBBsex6vUHi0wzfBeZ0ho9GfDd2V/qnIhymwz4U1zoYjTBwcjrP/QzJ+ZIGb5mIx UHsjj9exgJBEASBFZ8VUMdZpfj8PzNRB6qY3bO9VlIBiYGlpHI3+KxgidigZxkl0ZTt9 E4Ig== X-Gm-Message-State: AKwxytcCbPcYVzPF4cRQxuu+CpE4P6cweTVRnWYoOhoAkbeTMi9tS7pb bK3XHyhlezfhvdezDPDq4liHGQ== X-Google-Smtp-Source: ACJfBotdemj+PwUEXDZ1n5CaIsjIDHa9CerKuU5glim0rRZKzv/g5n9s6kKtw3IhTgEtyUCuc0ARTg== X-Received: by 10.55.215.139 with SMTP id t11mr24584609qkt.355.1515615839857; Wed, 10 Jan 2018 12:23:59 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id s126sm3977886qkh.59.2018.01.10.12.23.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 12:23:59 -0800 (PST) Date: Wed, 10 Jan 2018 15:23:57 -0500 From: Dmitri Tikhonov To: Jana Iyengar Cc: Charles 'Buck' Krasic , QUIC WG , Martin Thomson Subject: Re: Deadlocking in the transport Message-ID: <20180110202357.GC30573@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , Charles 'Buck' Krasic , QUIC WG , Martin Thomson References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:24:03 -0000 On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iyengar wrote: > SHOULD is pretty strong. It's not a guarantee, but then a transport > implementation that doesn't do it is expected to know what it's doing. If an application protocol is based on an assumption that the transport's SHOULD is really a MUST, then you end up with an application that works with some transport implementations, but not other -- conforming! -- implementations. > We could include language in this section about priorities being important > to avoid deadlocks when an application has dependencies across streams. What would this advice be? "Consume *all data* from higher priority streams before consuming data from lower priority streams?" - Dmitri. From nobody Wed Jan 10 12:27:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17701289B0 for ; Wed, 10 Jan 2018 12:27:04 -0800 (PST) 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=lMKxgPua; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=dlB4cQEM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMssY0TOJGOj for ; Wed, 10 Jan 2018 12:27:02 -0800 (PST) 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 A8C4912711B for ; Wed, 10 Jan 2018 12:27:02 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0AKNMfN030719; Wed, 10 Jan 2018 12:27:00 -0800 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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=coYb6XFHCP+bF0v0ZBDSlyTMjt1BbhMDJx7+JlCR5Jc=; b=lMKxgPuaIvBV7r0lV6D7OOQDjgvVX3rrahGt8NxBlIudDF4/TYSi0wRgnPVmuIEZ4mXS dpPvPQYqEBrfwvdL7jOXPS/vqfzYGCU2chU4fr1+PH1N3Q8O98q3xaKMscmW18RipqlY ZPL2RvUJHNlfzcj4FdqWVv9pnVVFLrWBy6w= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fdsh4r1x5-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 Jan 2018 12:27:00 -0800 Received: from NAM01-BY2-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.361.1; Wed, 10 Jan 2018 15:26:59 -0500 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=coYb6XFHCP+bF0v0ZBDSlyTMjt1BbhMDJx7+JlCR5Jc=; b=dlB4cQEMFQqcf46yDdExi8ZKZ17RAr5LRdg84jlqCWeAw0la3ifwtZe8idIlGtEWOcxoIhl7lMBje8Cz3OqHQuF58d79HuwMKg15wATs5q+lkRpQfAR7IU9Y0UAgMJoE0quqqP+DF84qQ0+iqtetwNSyhTCnjxDyyHHb/OR88gY= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2181.namprd15.prod.outlook.com (52.132.131.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Wed, 10 Jan 2018 20:26:57 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::7d32:3266:94b6:13f1]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::7d32:3266:94b6:13f1%13]) with mapi id 15.20.0386.009; Wed, 10 Jan 2018 20:26:57 +0000 From: Roberto Peon To: Martin Thomson , QUIC WG Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNtCOaA Date: Wed, 10 Jan 2018 20:26:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:810d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2181; 7:LytLwtTvFFGdA+Vuvag1nZqjx3lsZllc9MJUMzLkDdC5KNrwZkgl/A/EAO3VESAAHQnzAP7n0HhR8ymxSurKQ9MiomvXmSooG2GXtNW8zftdwEzhnKJgL56zrXJcm1PW9Xti15pgExFmi9OsNc7spWA2RJKJW4u3SOjj06+2d5L8KxR3pZJ5k9zRjhptHPtToxnpDdGuyNfGxiU/2WFj6Qfi4uC5lCKo8eNyjJ5V1NZM5aUntIBdl3N9IS3TEqsl; 20:pG3V6mEKkXPqkIBI170NRqJo7XyeKkoinu98DxeyX47ZRyLckSoE7YMcAhjpJZ2ioEj9EgSnHnlbdu0syXGmWjRENZLyQ/AXKnnS9hEXoHzvQZ72evmJLrvpPkK5DfX24ulGDkreNWINBGflLN+5F+L/fb76AAFphNNlH+vBJ2w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0d051a81-226a-497c-dfdc-08d558687f2b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020055)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2181; x-ms-traffictypediagnostic: DM5PR1501MB2181: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3002001)(3231023)(11241501184)(944501122)(93006095)(93001095)(10201501046)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR1501MB2181; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR1501MB2181; x-forefront-prvs: 0548586081 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(39380400002)(376002)(346002)(366004)(24454002)(189003)(54094003)(199004)(3660700001)(39060400002)(97736004)(2900100001)(3280700002)(478600001)(6116002)(14454004)(8936002)(59450400001)(305945005)(81166006)(5660300001)(86362001)(7736002)(76176011)(3480700004)(6246003)(83716003)(99286004)(8676002)(81156014)(2906002)(6436002)(6506007)(53546011)(33656002)(229853002)(2950100002)(68736007)(6512007)(316002)(110136005)(6346003)(36756003)(25786009)(5250100002)(105586002)(53936002)(102836004)(106356001)(6486002)(82746002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2181; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: dTdHAQgPccOmKm1mn5y8omdHQwgt0xP/Sy9px7BQeLnM7kwIbCuWoZMw0xWiXxiv5zo0fuMxnyYLUQUuJu9KWQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d051a81-226a-497c-dfdc-08d558687f2b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 20:26:57.5436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2181 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-10_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 20:27:05 -0000 QW5vdGhlciBvcHRpb246DQpBbGxvdyBhIGZsb3ctY29udHJvbCDigJhvdmVycmlkZeKAmSB3aGlj aCBhbGxvd3MgYSByZWNlaXZlciB0byBzdGF0ZSB0aGF0IHRoZXkgcmVhbGx5IHdhbnQgZGF0YSBv biBhIHBhcnRpY3VsYXIgc3RyZWFtLCBhbmQgaWdub3JlIHRoZSBnbG9iYWwgZmxvdyBjb250cm9s IGZvciB0aGlzLg0KDQpIb3cgeW914oCZZCBkbyBpdDoNCkEgcmVjZWl2ZXIgY2FuIHNlbmQgYSBm bG93LWNvbnRyb2wgb3ZlcnJpZGUgZm9yIGEgc3RyZWFtLiBUaGlzIGluY2x1ZGVzIHRoZSBzdHJl YW0gaWQgdG8gd2hpY2ggdGhlIGdsb2JhbCB3aW5kb3cgdGVtcG9yYXJpbHkgZG9lcyBub3QgYXBw bHksIHRoZSByZWNlaXZlcuKAmXMgY3VycmVudCBzdHJlYW0gZmxvdy1jb250cm9sIG9mZnNldCwg YW5kIHRoZSBvZmZzZXQgdGhlIHJlY2VpdmVyIHdvdWxkIHdpc2ggdG8gYmUgYWJsZSB0byByZWNl aXZlLg0KQSByZWNlaXZlciBtdXN0IGNvbnRpbnVlIHRvIChyZSlzZW5kIHRoZSBvdmVycmlkZSAo aS5lLiByZXhtaXQpIHVudGlsIGl0IGlzIGFja+KAmWQuIEl0IGNhbm5vdCBzZW5kIG90aGVyIGZs b3ctY29udHJvbCBmb3IgdGhhdCBzdHJlYW0gdW50aWwgdGhlIG92ZXJyaWRlIGlzIGFja+KAmWQu DQpUaHVzOg0KICBnbG9iYWwtZmxvdy1jb250cm9sLW92ZXJyaWRlOiA8c3RyZWFtLWlkPiA8Y3Vy cmVudC1mbG93LWNvbnRyb2wtb2Zmc2V0PiwgPG92ZXJyaWRlLWZsb3ctY29udHJvbC1vZmZzZXQ+ DQoNClRoZSBzZW5kZXIgKHdoaWNoIHJlY2VpdmVzIHRoZSBvdmVycmlkZSkgY3JlZGl0cyB0aGUg Z2xvYmFsIGZsb3cgY29udHJvbCB3aXRoIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGRhdGEg c2VudCBiZXlvbmQgdGhlIHJlY2VpdmVycyBjdXJyZW50bHkta25vd24gZmxvdy1jb250cm9sIG9m ZnNldCB1cG9uIHJlY2VpcHQgb2YgdGhlIG92ZXJyaWRlLg0KVGhpcyBzeW5jaHJvbml6ZXMgdGhl IGdsb2JhbCBzdGF0ZSBiZXR3ZWVuIHRoZSByZWNlaXZlciBhbmQgdGhlIHNlbmRlci4NClRoZSBz ZW5kZXIgY2FuIHRoZW4gc2VuZCB0aGUgZGF0YSBvbiB0aGUgc3RyZWFtICh3aXRob3V0IHRvdWNo aW5nIGFueSBvdGhlciBmbG93IGNvbnRyb2wgZGF0YSkuDQoNCldoeToNClRoaXMgYWxsb3dzIGZv ciBhIHJlY2VpdmVyIHRvIHJlc29sdmUgcHJpb3JpdHkgaW52ZXJzaW9ucyB3aGljaCB3b3VsZCBv dGhlcndpc2UgbGVhZCB0byBkZWFkbG9jaywgZXZlbiB3aGVuIHRoZSBkYXRhL2RlcCBsZWFkaW5n IHRvIHRoaXMgd2FzIG5vdCBrbm93biB0byB0aGUgdHJhbnNwb3J0LiBUaGlzIGV4dGVuZHMgYmV5 b25kIHN1Y2ggaXNzdWVzIGJleW9uZCBqdXN0IGhlYWRlciBjb21wcmVzc2lvbi4NCg0KU2luY2Ug dGhlIGdsb2JhbCBmbG93LWNvbnRyb2wgZXhpc3RzIHRvIHByb3RlY3QgdGhlIGFwcCBmcm9tIHJl c291cmNlIGV4aGF1c3Rpb24sIHRoaXMgcG9zZXMgbm8gYWRkaXRpb25hbCByaXNrIHRvIHRoZSBh cHBsaWNhdGlvbi4NClNpbXBseSBpbmNyZWFzaW5nIHRoZSBnbG9iYWwgZmxvdyBjb250cm9sIHBy b3ZpZGVzIGxlc3Mgc3Ryb25nIGd1YXJhbnRlZXPigJRhbnkgc3RyZWFtIG1pZ2h0IGNvbnN1bWUg aXQsIHdoaWNoIGRvZXNu4oCZdCByZXNvbHZlIHRoZSBkZXAgaW52ZXJzaW9uLiBSZWppZ2dlcmlu ZyBwcmlvcml0aWVzIGNhbiBoZWxwIHRvIHJlc29sdmUgdGhpcywgYnV0IHdvdWxkIHJlcXVpcmUg dGhlIHNlbmRlciB0byBzZW5kIHByaW9yaXRpZXMgdG8gdGhlIGNsaWVudCwgd2hpY2ggaXMgcHJv YmxlbWF0aWMgdy5yLnQucmFjZXMgYW5kIGp1c3QgYSB3ZWIgb2YgaWNrLiANCg0KSGF2aW5nIGEg Y3VzdG9tIGZyYW1lIHR5cGUgaXMgYWxzbyBhIGxlc3Mgc3Ryb25nIGd1YXJhbnRlZSBhcyBpdCBy ZXF1aXJlcyB0aGUga25vd2xlZGdlIHRoYXQgdGhlIGRlcCBleGlzdHMgdG8gYmUgcHJlc2VudCBh dCB0aGUgdGltZSBvZiBzZW5kaW5nLCB3aGljaCBpcyBvZnRlbiBpbXBvc3NpYmxlLg0KDQotPVIN Cg0KT24gMS85LzE4LCAxMDoxNyBQTSwgIlFVSUMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29u IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20+IHdyb3RlOg0KDQogICAgQnVpbGRpbmcgYSBjb21wbGV4IGFwcGxpY2F0aW9uIHByb3Rv Y29sIG9uIHRvcCBvZiBRVUlDIGNvbnRpbnVlcyB0bw0KICAgIHByb2R1Y2Ugc3VycHJpc2VzLg0K ICAgIA0KICAgIFRvZGF5IGluIHRoZSBoZWFkZXIgY29tcHJlc3Npb24gZGVzaWduIHRlYW0gbWVl dGluZyB3ZSBkaXNjdXNzZWQgYQ0KICAgIGRlYWRsb2NraW5nIGlzc3VlIHRoYXQgSSB0aGluayB3 YXJyYW50cyBzaGFyaW5nIHdpdGggdGhlIGxhcmdlciBncm91cC4NCiAgICBUaGlzIGhhcyBpbXBs aWNhdGlvbnMgZm9yIGhvdyBwZW9wbGUgYnVpbGQgYSBRVUlDIHRyYW5zcG9ydCBsYXllci4gIEl0 DQogICAgbWlnaHQgbmVlZCBjaGFuZ2VzIHRvIHRoZSBBUEkgdGhhdCBpcyBleHBvc2VkIGJ5IHRo YXQgbGF5ZXIuDQogICAgDQogICAgVGhpcyBpc24ndCByZWFsbHkgdGhhdCBuZXcsIGJ1dCBJIGRv bid0IHRoaW5rIHdlJ3ZlIHByb3Blcmx5IGFkZHJlc3NlZA0KICAgIHRoZSBwcm9ibGVtLg0KICAg IA0KICAgIA0KICAgICMjIFRoZSBCYXNpYyBQcm9ibGVtDQogICAgDQogICAgSWYgYSBwcm90b2Nv bCBjcmVhdGVzIGEgZGVwZW5kZW5jeSBiZXR3ZWVuIHN0cmVhbXMsIHRoZXJlIGlzIGENCiAgICBw b3RlbnRpYWwgZm9yIGZsb3cgY29udHJvbCB0byBkZWFkbG9jay4NCiAgICANCiAgICBTYXkgdGhh dCBJIHNlbmQgWCBvbiBzdHJlYW0gMyBhbmQgWSBvbiBzdHJlYW0gNy4gIFByb2Nlc3NpbmcgWQ0K ICAgIHJlcXVpcmVzIHRoYXQgWCBpcyBwcm9jZXNzZWQgZmlyc3QuDQogICAgDQogICAgWCBjYW5u b3QgYmUgc2VudCBkdWUgdG8gZmxvdyBjb250cm9sIGJ1dCBZIGlzIHNlbnQuICBUaGlzIGlzIGFs d2F5cw0KICAgIHBvc3NpYmxlIGV2ZW4gaWYgWCBpcyBhcHByb3ByaWF0ZWx5IHByaW9yaXRpemVk LiAgVGhlIHJlY2VpdmVyIHRoZW4NCiAgICBsZWF2ZXMgWSBpbiBpdHMgcmVjZWl2ZSBidWZmZXIg dW50aWwgWCBpcyByZWNlaXZlZC4NCiAgICANCiAgICBUaGUgcmVjZWl2ZXIgY2Fubm90IGdpdmUg ZmxvdyBjb250cm9sIGNyZWRpdCBmb3IgY29uc3VtaW5nIFkgYmVjYXVzZQ0KICAgIGl0IGNhbid0 IGNvbnN1bWUgWSB1bnRpbCBYIGlzIHNlbnQuICBCdXQgdGhlIHNlbmRlciBuZWVkcyBmbG93IGNv bnRyb2wNCiAgICBjcmVkaXQgdG8gc2VuZCBYLiAgV2UgYXJlIGRlYWRsb2NrZWQuDQogICAgDQog ICAgSXQgZG9lc24ndCBtYXR0ZXIgd2hldGhlciB0aGUgc3RyZWFtIG9yIGNvbm5lY3Rpb24gZmxv dyBjb250cm9sIGlzDQogICAgY2F1c2luZyB0aGUgcHJvYmxlbSwgZWl0aGVyIHByb2R1Y2VzIHRo ZSBzYW1lIHJlc3VsdC4NCiAgICANCiAgICAoVG8gZ2l2ZSBzb21lIGJhY2tncm91bmQgb24gdGhp cywgd2Ugd2VyZSBjb25zaWRlcmluZyBhIHByZWZhY2UgdG8NCiAgICBoZWFkZXIgYmxvY2tzIHRo YXQgaWRlbnRpZmllZCB0aGUgaGVhZGVyIHRhYmxlIHN0YXRlIHRoYXQgd2FzDQogICAgbmVjZXNz YXJ5IHRvIHByb2Nlc3MgdGhlIGhlYWRlciBibG9jay4gIFRoaXMgd291bGQgYWxsb3cgZm9yDQog ICAgY29uY3VycmVudCBwb3B1bGF0aW9uIG9mIHRoZSBoZWFkZXIgdGFibGUgYW5kIHNlbmRpbmcg bWVzc2FnZSB0aGF0DQogICAgZGVwZW5kZWQgb24gdGhlIGhlYWRlciB0YWJsZSBzdGF0ZSB0aGF0 IGlzIHVuZGVyIGNvbnN0cnVjdGlvbi4gIEENCiAgICByZWNlaXZlciB3b3VsZCByZWFkIHRoZSBp ZGVudGlmaWVyIGFuZCB0aGVuIGxlYXZlIHRoZSByZW1haW5kZXIgb2YgdGhlDQogICAgaGVhZGVy IGJsb2NrIGluIHRoZSByZWNlaXZlIGJ1ZmZlciB1bnRpbCB0aGUgaGVhZGVyIHRhYmxlIHdhcyBy ZWFkeS4pDQogICAgDQogICAgDQogICAgIyMgT3B0aW9ucw0KICAgIA0KICAgIEl0IHNlZW1zIGxp a2UgdGhlcmUgYXJlIGEgZmV3IGRlY2VudCBvcHRpb25zIGZvciBtYW5hZ2luZyB0aGlzLiAgVGhl c2UNCiAgICBhcmUgd2hhdCBvY2N1cnJlZCB0byBtZSAodGhlcmUgYXJlIGFsbW9zdCBjZXJ0YWlu bHkgbW9yZSBvcHRpb25zKToNCiAgICANCiAgICAxLiBEb24ndCBkbyB0aGF0LiAgV2UgbWlnaHQg Y29uY2VkZSBpbiB0aGlzIGNhc2UgdGhhdCBzZWVraW5nIHRoZQ0KICAgIGluY3JlbWVudGFsIGlt cHJvdmVtZW50IHRvIGNvbXByZXNzaW9uIGVmZmljaWVuY3kgaXNuJ3Qgd29ydGggdGhlDQogICAg cmlzay4gIFRoYXQgaXMsIHdlIG1pZ2h0IG1ha2UgYSBnZW5lcmFsIHN0YXRlbWVudCB0aGF0IHRo aXMgc29ydCBvZg0KICAgIGludGVyLXN0cmVhbSBibG9ja2luZyBpcyBhIGJhZCBpZGVhLg0KICAg IA0KICAgIDIuIEZvcmNlIHJlY2VpdmVycyB0byBjb25zdW1lIGRhdGEgb3IgcmVzZXQgc3RyZWFt cyBpbiB0aGUgY2FzZSBvZg0KICAgIHVuZnVsZmlsbGVkIGRlcGVuZGVuY2llcy4gIFRoZSBmb3Jt ZXIgc2VlbXMgbGlrZSBpdCBtaWdodCBiZSB0b28gbXVjaA0KICAgIGxpa2UgbWFnaWNhbCB0aGlu a2luZywgaW4gdGhlIHNlbnNlIHRoYXQgaXQgcmVxdWlyZXMgdGhhdCByZWNlaXZlcnMNCiAgICBj b25qdXJlIG1vcmUgbWVtb3J5IHVwLCBidXQgaWYgdGhlIHJlY2VpdmVyIHdlcmUgcmVxdWlyZWQg dG8gcmVhZCBZDQogICAgYW5kIHJlbGVhc2UgdGhlIGZsb3cgY29udHJvbCBjcmVkaXQsIHRoZW4g YWxsIHdvdWxkIGJlIGZpbmUuICBGb3INCiAgICBpbnN0YW5jZSwgd2UgY291bGQgcmVxdWlyZSB0 aGF0IHRoZSByZWNlaXZlciByZXNldCBhIHN0cmVhbSBpZiBpdA0KICAgIGNvdWxkbid0IHJlYWQg YW5kIGhhbmRsZSBkYXRhLiAgSXQgc2VlbXMgbGlrZSBhIGJhZCBhcnJhbmdlbWVudA0KICAgIHRo b3VnaDogeW91IGVpdGhlciBoYXZlIHRvIGFsbG9jYXRlIG1vcmUgbWVtb3J5IHRoYW4geW91IHdv dWxkIGxpa2Ugb3INCiAgICBzdWZmZXIgdGhlIHRpbWUgYW5kIG9wcG9ydHVuaXR5IGNvc3Qgb2Yg aGF2aW5nIHRvIGRvIFkgb3Zlci4NCiAgICANCiAgICAzLiBDcmVhdGUgYW4gZXhjZXB0aW9uIGZv ciBmbG93IGNvbnRyb2wuICBUaGlzIGlzIHdoYXQgR29vZ2xlIFFVSUMNCiAgICBkb2VzIGZvciBp dHMgaGVhZGVycyBzdHJlYW0uICBSb2JlcnRvIG9ic2VydmVkIHRoYXQgd2UgY291bGQNCiAgICBh bHRlcm5hdGl2ZWx5IGNyZWF0ZSBhIGZyYW1lIHR5cGUgdGhhdCB3YXMgZXhjbHVkZWQgZnJvbSBm bG93IGNvbnRyb2wuDQogICAgSWYgdGhpcyB3ZXJlIHVzZWQgZm9yIGRhdGEgdGhhdCBoYWQgZGVw ZW5kZW5jaWVzLCB0aGVuIGl0IHdvdWxkIGJlDQogICAgaW1wb3NzaWJsZSB0byBkZWFkbG9jay4g IEl0IHdvdWxkIGJlIHNpbWlsYXJseSBkaWZmaWN1bHQgdG8gYWNjb3VudA0KICAgIGZvciBtZW1v cnkgYWxsb2NhdGlvbiwgdGhvdWdoIGlmIGl0IHdlcmUgcG9zc2libGUgdG8gcHJvY2VzcyBvbg0K ICAgIHJlY2VpcHQsIHRoZW4gdGhpcyAqbWlnaHQqIHdvcmsuICBXZSdkIGhhdmUgdG8gZG8gc29t ZXRoaW5nIHRvIGFkZHJlc3MNCiAgICBvdXQtb2Ytb3JkZXIgZGVsaXZlcnkgdGhvdWdoLiAgSXQn cyBwb3NzaWJsZSB0aGF0IHRoZSBzdHJlYW0NCiAgICBhYnN0cmFjdGlvbiBpcyBub3QgYXBwcm9w cmlhdGUgaW4gdGhpcyBjYXNlLg0KICAgIA0KICAgIDQuIEJsb2NrIHRoZSBwcm9ibGVtIGF0IHRo ZSBzb3VyY2UuICBJdCB3YXMgc3VnZ2VzdGVkIHRoYXQgaW4gY2FzZXMNCiAgICB3aGVyZSB0aGVy ZSBpcyBhIHBvdGVudGlhbCBkZXBlbmRlbmN5LCB0aGVuIGl0IGNhbid0IGJlIGEgcHJvYmxlbSBp Zg0KICAgIHRoZSB0cmFuc3BvcnQgcmVmdXNlZCB0byBhY2NlcHQgZGF0YSB0aGF0IGl0IGRpZG4n dCBoYXZlIGZsb3cgY29udHJvbA0KICAgIGNyZWRpdCBmb3IuICBXcml0ZXMgdG8gdGhlIHRyYW5z cG9ydCB3b3VsZCBjb25zdW1lIGZsb3cgY29udHJvbCBjcmVkaXQNCiAgICBpbW1lZGlhdGVseS4g IFRoYXQgd2F5IGFwcGxpY2F0aW9ucyB3b3VsZCBvbmx5IGJlIGFibGUgdG8gd3JpdGUgWCBpZg0K ICAgIHRoZXJlIHdhcyBhIGNoYW5jZSB0aGF0IGl0IHdvdWxkIGJlIGRlbGl2ZXJlZC4gIEFwcGxp Y2F0aW9ucyB0aGF0IGhhdmUNCiAgICBvcmRlcmluZyByZXF1aXJlbWVudHMgY2FuIGVuc3VyZSB0 aGF0IFkgaXMgd3JpdHRlbiBhZnRlciBYIGlzIGFjY2VwdGVkDQogICAgYnkgdGhlIHRyYW5zcG9y dCBhbmQgdGhlcmVieSBhdm9pZCB0aGUgZGVhZGxvY2suICBXcml0ZXMgbWlnaHQgYmxvY2sNCiAg ICByYXRoZXIgdGhhbiBmYWlsLCBpZiB0aGUgQVBJIHdhc24ndCBpbnRvIHRoZSB3aG9sZSBub24t YmxvY2tpbmcgSS9PDQogICAgdGhpbmcuICBUaGUgdHJhbnNwb3J0IG1pZ2h0IHN0aWxsIGhhdmUg dG8gYnVmZmVyIFggZm9yIG90aGVyIHJlYXNvbnMsDQogICAgbGlrZSBjb25nZXN0aW9uIGNvbnRy b2wsIGJ1dCBpdCBjYW4gZ3VhcmFudGVlIHRoYXQgZmxvdyBjb250cm9sIGlzbid0DQogICAgZ29p bmcgdG8gYmxvY2sgZGVsaXZlcnkuDQogICAgDQogICAgDQogICAgIyMgTXkgUHJlZmVyZW5jZQ0K ICAgIA0KICAgIFJpZ2h0IG5vdywgSSdtIGluY2xpbmVkIHRvd2FyZCBvcHRpb24gNC4gT3B0aW9u IDEgc2VlbXMgYSBsaXR0bGUgdG9vDQogICAgbXVjaCBvZiBhIGNvbnN0cmFpbnQuICBQcm90b2Nv bHMgY3JlYXRlIHRoaXMgc29ydCBvZiBpbnRlci1kZXBlbmRlbmN5DQogICAgbmF0dXJhbGx5Lg0K ICAgIA0KICAgIFRoZXJlJ3MgYSBjZXJ0YWluIHB1cml0eSBpbiBoYXZpbmcgdGhlIGZsb3cgY29u dHJvbCBleGVydCBiYWNrDQogICAgcHJlc3N1cmUgYWxsIHRoZSB3YXkgdG8gdGhlIG5leHQgbGF5 ZXIgdXAuICBOb3QgYmVpbmcgYWJsZSB0byBidWlsZCBhDQogICAgdHJhbnNwb3J0IHdpdGggdW5j b25zdHJhaW5lZCB3cml0ZXMgaXMgcG90ZW50aWFsbHkgY3JlYXRpbmcNCiAgICB1bmRlc2lyYWJs ZSBleHRlcm5hbGl0aWVzIG9uIHRyYW5zcG9ydCB1c2Vycy4gIE5vdyB0aGV5IGhhdmUgdG8gd29y cnkNCiAgICBhYm91dCBmbG93IGNvbnRyb2wgYXMgd2VsbC4gIFBlcnNvbmFsbHksIEknbSBpbmNs aW5lZCB0byBzYXkgdGhhdCB0aGlzDQogICAgaXMgc29tZXRoaW5nIHRoYXQgYXBwbGljYXRpb24g cHJvdG9jb2xzIGFuZCB0aGVpciB1c2VycyBzaG91bGQgYmUNCiAgICBleHBvc2VkIHRvLiAgV2Un dmUgc2VlbiB3aXRoIHRoZSBKUyBzdHJlYW1zIEFQSSB0aGF0IGl0J3MgdmFsdWFibGUgdG8NCiAg ICBoYXZlIGJhY2sgcHJlc3N1cmUgYXZhaWxhYmxlIGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBh bmQgYWxzbyBob3cgaXQNCiAgICBpcyBwb3NzaWJsZSB0byBkbyB0aGF0IHJlbGF0aXZlbHkgZWxl Z2FudGx5Lg0KICAgIA0KICAgIEknbSBhbG1vc3QgY2VydGFpbiB0aGF0IEkgaGF2ZW4ndCB0aG91 Z2h0IGFib3V0IGFsbCB0aGUgcG90ZW50aWFsDQogICAgYWx0ZXJuYXRpdmVzLiAgSSB3b25kZXIg aWYgdGhlcmUgaXNuJ3Qgc29tZSBleHBlcmllbmNlIHdpdGggdGhpcw0KICAgIHByb2JsZW0gaW4g U0NUUCB0aGF0IG1pZ2h0IGxlbmQgc29tZSBpbnNpZ2h0cy4NCiAgICANCiAgICANCg0K From nobody Wed Jan 10 12:32:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD31B12711B for ; Wed, 10 Jan 2018 12:32:21 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 OQkKxbh8j4hC for ; Wed, 10 Jan 2018 12:32:20 -0800 (PST) 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 0DDF9126DED for ; Wed, 10 Jan 2018 12:32:19 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id m84so120157ywd.5 for ; Wed, 10 Jan 2018 12:32:19 -0800 (PST) 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; bh=ayO6k16YG4GjR0GFlAGqEg75x7Tcs6MYKXAizbkzksI=; b=C0lRNqbNARB98dBKWaR9hoFFhUVjDZS5VxyErhzW3GiTRMMV2W15xQfKoi3SiF14tC riGD5Owq03yRz3APWhuudBLRJCrAFzWwoO84/T8BdVSQjf9jN7IwZNlG6H8hP75jw79U 6Dzdh8BJVrOwJz9kytGRNWh+Q8Sy4342KN/PdNRFBlT98eeViLAjIvkf2obbZM4GPLfe 3x/Magpe9VN0Bx3R8H4IVa5PnqNaTOLeSaK3X9lHWZxhQXdgbQZHt+zUOZNJ++5hVLgq /x9g5SKSKUBZtQyOiN0cgyTvSo4YVD3Pqmm+kTrvJTfnU3AIMsf2KssFWOMNitySnBLT XOkQ== 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=ayO6k16YG4GjR0GFlAGqEg75x7Tcs6MYKXAizbkzksI=; b=gK6ahvBTptp3Q9fc52klI/HmL6hYQp7m0quG+XnAA5EHi+GLkvKp/qmMheoOOHa+uF Rxxdz/Ds2y2TNRz2eREOmBeWWDScyw555Zdf0zBjy7FTE4bM2VIGFls2XtZQAGz0gopg ojDwLVG4bXMEo/cqnjlEtPKwLUZwnjPH11y4Qnrudg+qCIXBs31A9pNmDTCa9yY6VEuZ Xrm6SAQUuvGwPCYikEeI7vaNdHt3skrtWd0K+N8xzOmPL6xIDwZzjn/hy6AvMOINIAtZ wbocoyPS7+1MkJDgE854bKmbqxCRK3I+OAPaKiw2Adxt5oZFDvjNB+dnYPNlmsdTBBOC /5Lw== X-Gm-Message-State: AKGB3mK2njrsz2n+goJvMj7IyGTiEEHQgD/JgM1TnH//taRkWMnt5Smy fs+5zALtG7Qx2T+mzW/918wVbZvKGXiI7yBLpWBMBg== X-Google-Smtp-Source: ACJfBos0FjOp/xtNJSL8p8195ue/PjIt2CP1XSAATOqLqXDS/8qo3RUP59S9tYTRTAFc0J8lGy20rX0CwIbvtAYmOlw= X-Received: by 10.13.213.20 with SMTP id x20mr8669291ywd.94.1515616338777; Wed, 10 Jan 2018 12:32:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 12:32:18 -0800 (PST) In-Reply-To: <20180110202357.GC30573@ubuntu-dmitri> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Jana Iyengar Date: Wed, 10 Jan 2018 12:32:18 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar , "Charles 'Buck' Krasic" , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c054bc47de8af056271eda7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 20:32:22 -0000 --94eb2c054bc47de8af056271eda7 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iyengar wrote: > > SHOULD is pretty strong. It's not a guarantee, but then a transport > > implementation that doesn't do it is expected to know what it's doing. > > If an application protocol is based on an assumption that the transport's > SHOULD is really a MUST, then you end up with an application that works > with some transport implementations, but not other -- conforming! -- > implementations. I agree, but we aren't specifying the entire API, and I'm not sure that we want to resolve all potential API inconsistencies here. > We could include language in this section about priorities being important > > to avoid deadlocks when an application has dependencies across streams. > > What would this advice be? "Consume *all data* from higher priority > streams before consuming data from lower priority streams?" Yes, to avoid deadlock. > > - Dmitri. > --94eb2c054bc47de8af056271eda7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov <= dtikhonov@litespeedtech.com> wrote:
On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iy= engar wrote:
> SHOULD is pretty strong. It's not a guarantee, but then a transpor= t
> implementation that doesn't do it is expected to know what it'= s doing.

If an application protocol is based on an assumption that the transp= ort's
SHOULD is really a MUST, then you end up with an application that works
with some transport implementations, but not other -- conforming! --
implementations.

I agree, but we aren't= specifying the entire API, and I'm not sure that we want to resolve al= l potential API inconsistencies here.

> We could include language in this section about priorities being impor= tant
> to avoid deadlocks when an application has dependencies across streams= .

What would this advice be?=C2=A0 "Consume *all data* from highe= r priority
streams before consuming data from lower priority streams?"

Yes, to avoid deadlock.
=C2=A0

=C2=A0 - Dmitri.

--94eb2c054bc47de8af056271eda7-- From nobody Wed Jan 10 12:41:01 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2021271DF for ; Wed, 10 Jan 2018 12:40:59 -0800 (PST) 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 vaxI7KuV3VCq for ; Wed, 10 Jan 2018 12:40:57 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 108C3126E01 for ; Wed, 10 Jan 2018 12:40:57 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id 68so946475ite.4 for ; Wed, 10 Jan 2018 12:40:57 -0800 (PST) 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=OsSsnz8XJBD9j3/nhNOqi6sqk+E3vnxsxo9CPvlJ+K0=; b=hc+Un0spA+D13dtsFZmZvqgdCpmbXO9+WxNeIcpDQ0m/ym2vNvC5BPEabrvVQLElEu gsVZR4tD3US8iIUstxsjrH4+9w9++zOyiyTomtyT3ORdX5ECNKbW80YuUxdAWtbaf1/z 9szmzZcx9enA1qr2tVWv9De+SCZBOd1xraRrFCCJ7CKFxHys2U1vShaawIfI3OM9RG2B 2r2HqUqxWGPfWBrUfljUWUqnb7XkkXVdI92Qz1QMBEw2g0m98GFAjk4RLIaTAXBJc6Hu SgMaxoS+i3yU/hGZ9xaV1dodrL0TUnDWbieVD6TSTj06+ofU7CynIQttM7wikAxTGNaR HdpA== 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=OsSsnz8XJBD9j3/nhNOqi6sqk+E3vnxsxo9CPvlJ+K0=; b=llQnrEsGq9Wh/J1iUWmlL7cB3SmIuCgy44RdAallCkJQDMrJOg4HkR7p82H8cTLw0t HR/4kJ62qdASWflz5252vWeUaHmY8qvGOy6ttVsPb8/oFSR74EjfhdmRCCUtJENvip5J hhJrAZL3DpPXzKXPk/vxzfbYrsYpdSDrrnNhLchx1HqR0vEDpG5BuRbkc1RSLTYlFnLh sufLpIP7n3UStKm+gIJdpM6Cwx/DXy0U9SkAo0f3L6h0nvLMappppi6pPgw5M0p8wR7e 9p3LQUXxwF6E8bv8D+SDiH0hZ2BluK1eqO89tO62PtXgqTq1PLKkOAUI2qm8vUhCt/zB ftzA== X-Gm-Message-State: AKGB3mJ+8T/hh61/G1Lh30hFzwjrThQIz8iB9DxEiKuYkIU9q4ZZDvvY 2wtTg5O6ymZfpz2eL62kfmOHMukeBcTDZfXB0RY= X-Google-Smtp-Source: ACJfBovMWGhGAAlV7gbObDh/YzAk6DYmH9t8cqyAw5ocigISB/bnXvvPefsXSARzdYpfZZ3NAG7itmCshSt1MxP0F8A= X-Received: by 10.36.181.4 with SMTP id v4mr19269777ite.42.1515616856496; Wed, 10 Jan 2018 12:40:56 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 15:40:55 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 15:40:55 -0500 Message-ID: Subject: Re: Deadlocking in the transport To: "Charles 'Buck' Krasic" , Jana Iyengar , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="f403045d996e58de860562720cd2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 20:40:59 -0000 --f403045d996e58de860562720cd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable How about a reserve bandwidth function in the API. Header transport could reserve the minimum needed to ensure a deadlock, and another reserve for the general traffic. This isolates bandwith consumption from other streams. I hinted at this earlier. Just like you can share to the total bandwidth across streams, you can share bandwidth across resource groups, where each stream belongs to a resource group. You can provide priorities to groups, but that should not mean the highest priority takes all. It would be inconvenient and could lead to other deadlocks. Deficit Round Robin can be applied to groups. https://en.wikipedia.org/wiki/Deficit_round_robin Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 10 January 2018 at 21.32.25, Jana Iyengar (jri@google.com) wrote: On Wed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iyengar wrote: > > SHOULD is pretty strong. It's not a guarantee, but then a transport > > implementation that doesn't do it is expected to know what it's doing. > > If an application protocol is based on an assumption that the transport's > SHOULD is really a MUST, then you end up with an application that works > with some transport implementations, but not other -- conforming! -- > implementations. I agree, but we aren't specifying the entire API, and I'm not sure that we want to resolve all potential API inconsistencies here. > We could include language in this section about priorities being importan= t > > to avoid deadlocks when an application has dependencies across streams. > > What would this advice be? "Consume *all data* from higher priority > streams before consuming data from lower priority streams?" Yes, to avoid deadlock. > > - Dmitri. > --f403045d996e58de860562720cd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = How about a reserve = bandwidth function in the API. Header transport could reserve the minimum n= eeded to ensure a deadlock, and another reserve for the general traffic. Th= is isolates bandwith consumption from other streams.

I hinted at this earlier. Just like you can= share to the total bandwidth across streams, you can share bandwidth acros= s resource groups, where each stream belongs to a resource group.

You can provide priorities to = groups, but that should not mean the highest priority takes all. It would b= e inconvenient and could lead to other deadlocks. Deficit Round Robin can b= e applied to groups.


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


On 10 January 2018 at 21.32.25, Jana Iyeng= ar (jri@google.com) wrote:

On Wed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Wed, Jan 10, 2018 at 12:14:13PM -0800, Jana Iyengar wrote:
> SHOULD is pretty strong. It's not a guarantee, but then a transport
> implementation that doesn't do it is expected to know what it's doing.

If an application protocol is based on an assumption that the transport's
SHOULD is really a MUST, then you end up with an application that works
with some transport implementations, but not other -- conforming! --
implementations.

I agree, but we aren't specifying the entire API, and I'm not sure that we want to resolve all potential API inconsistencies here.

> We could include language in this section about priorities being important
> to avoid deadlocks when an application has dependencies across streams.

What would this advice be?=C2=A0 "Consume *all data* from higher priority
streams before consuming data from lower priority streams?"

Yes, to avoid deadlock.
=C2=A0

=C2=A0 - Dmitri.

 --f403045d996e58de860562720cd2-- From nobody Wed Jan 10 12:50:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0E512D77C for ; Wed, 10 Jan 2018 12:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGiDu557zql3 for ; Wed, 10 Jan 2018 12:50:13 -0800 (PST) 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 A614F129C51 for ; Wed, 10 Jan 2018 12:50:13 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u76so829044qku.11 for ; Wed, 10 Jan 2018 12:50:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=khEBAnFG5zY0xT2ijlL0ePzhnqo0ajsHGu/8CuHaV9E=; b=sjLy9mpPicEbgvcEsEpKZuga5ILwW+NY1UBKsBrJE49TRlHoA0VHwqU5PUVIo//BRa wfyiA87RT83ExW4nRehSxIP3F43CrE87Ta0tQB2pK4LY9WHy2/BpQ4lea9iilcWtXlPe tVhFWyNqBgfEQHtLgF8BXiZyuF20PQ5erVLrK/5WOuuRHzSiRD2VUB1c4qQ5XP9PJHtJ oVbLa2lLGx5u1D6NDyzjdkuP3dbkudq+LDCl5EBjnbAnuF3xYPdwzYpZZtVk1cZIZURY jrgrsGAq1LKGowrwWxvBQZZMrbp/WJsaO3TbozQOaOOvTAieG+W+b9emI9Tm86eFKRig /l9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=khEBAnFG5zY0xT2ijlL0ePzhnqo0ajsHGu/8CuHaV9E=; b=gOLAGUtQGiTFNE6lyv5Vf4YOXpfvmnDX+ED3QRwq3Aj1zayDIWZ40xB6839YgD70EJ r+OFwIBsP+oEko7cc1+MCl8pWXsl6NgY94YIwZz+K0QKYZEnmMIswqFz/3/Dlwr9i9RT F+z8N9d4akssuFppI+yK5FsTHU7ZYFEp73pXwt+7Y9FtT6NK5TS2VT2tfL3nKM6EJzMY ChWm8SRj+Q9YcQd2SBW8jgs6TEulhrzaN+kkxg9iNj+lKWiTEawCTjMvWFQdaJjTWdvm MO3Ux7ovpDTV5u2npjFHzn1UfphhcQ/JpA66ZKOXqHZdr52t7T6M679ootFkAvSytOvL Tw5A== X-Gm-Message-State: AKwxytf3QvZkKG3I7ulwn1DTRwhE4tpWlpBgFH7uYnaJPS9wu6bQr3o0 4wlytlcBaEtLBoFnBfUAXKR1Ow== X-Google-Smtp-Source: ACJfBotGs7Efqt3YxP2zvEOE0YRsknorqEMaBvy707MO+wXy3haB6dcOUL0hKh+Gk0nUA2m0OR3Yow== X-Received: by 10.200.2.157 with SMTP id p29mr28258166qtg.155.1515617412813; Wed, 10 Jan 2018 12:50:12 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id j127sm4102820qkd.88.2018.01.10.12.50.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 12:50:12 -0800 (PST) Date: Wed, 10 Jan 2018 15:50:07 -0500 From: Dmitri Tikhonov To: Jana Iyengar Cc: Charles 'Buck' Krasic , QUIC WG , Martin Thomson Subject: Re: Deadlocking in the transport Message-ID: <20180110205006.GA3434@ubuntu-dmitri> Mail-Followup-To: Jana Iyengar , Charles 'Buck' Krasic , QUIC WG , Martin Thomson References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:50:16 -0000 On Wed, Jan 10, 2018 at 12:32:18PM -0800, Jana Iyengar wrote: > On Wed, Jan 10, 2018 at 12:23 PM, Dmitri Tikhonov wrote: > > > > If an application protocol is based on an assumption that the transport's > > SHOULD is really a MUST, then you end up with an application that works > > with some transport implementations, but not other -- conforming! -- > > implementations. > > I agree, but we aren't specifying the entire API, and I'm not sure that we > want to resolve all potential API inconsistencies here. We are not discussing the API; we are discussing the transport behaviors that the application can or cannot rely upon. > > What would this advice be? "Consume *all data* from higher priority > > streams before consuming data from lower priority streams?" > > Yes, to avoid deadlock. Let's make sure that we are talking about the same idea. It seems that what you are suggesting is either: A. The transport layer not allow the application to read from a stream if a higher-priority stream data is available for reading; or B. If the application wants to read from a lower-priority stream first, the transport layer will pretend that the higher-stream data has been read. In other words, the high-stream data will be set aside somehow, giving the peer flow control credits for sending more. Both seem suboptimal to me -- did you have something else in mind? - Dmitri. From nobody Wed Jan 10 13:07:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1680B12DA4C for ; Wed, 10 Jan 2018 13:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.399 X-Spam-Level: ** X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 kiQG1HcxWz5x for ; Wed, 10 Jan 2018 13:07:02 -0800 (PST) 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 45E8812D950 for ; Wed, 10 Jan 2018 13:07:02 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eZNaN-0004so-J7 for quic@ietf.org; Wed, 10 Jan 2018 22:07:00 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eZNaK-0006mX-De for quic@ietf.org; Wed, 10 Jan 2018 16:06:57 -0500 Received: (qmail 6764 invoked from network); 10 Jan 2018 21:06:54 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Jan 2018 21:06:54 -0000 To: quic@ietf.org References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <20180110205006.GA3434@ubuntu-dmitri> From: Christian Huitema Message-ID: <0a2778b8-f740-cf9f-656d-445ebfbb6f2b@huitema.net> Date: Wed, 10 Jan 2018 11:06:52 -1000 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: <20180110205006.GA3434@ubuntu-dmitri> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: Deadlocking in the transport X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5n0uRzd+4d1AZ+3tPm16Fg8Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsSG0P9vnFDCsUxeHeTNBAJB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RY6xvCTKpexH9NiU0GFJBW3GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIHI a5J8n3XNAXVqVUtf9Gu/ZOooRjA8u8TuHX6ZkKPotGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:07:04 -0000 On 1/10/2018 10:50 AM, Dmitri Tikhonov wrote: > Let's make sure that we are talking about the same idea. It seems that= > what you are suggesting is either: > > A. The transport layer not allow the application to read from > a stream if a higher-priority stream data is available for > reading; or > > B. If the application wants to read from a lower-priority stream > first, the transport layer will pretend that the higher-stream > data has been read. In other words, the high-stream data will > be set aside somehow, giving the peer flow control credits for > sending more. > > Both seem suboptimal to me -- did you have something else in mind? The problem arise because of over commitment of resource. Specifically, it arises if the MAX DATA limit is lower the sum of the MAX STREAM DATA limits. If MAX DATA was defined implicitly as the sum of MAX STREAM DATA, we could have a very simple API between application and transport. The application gives credits on the stream that it is ready to accept data, and the transport just follows that. I understand that from a resource point of view it is sub-optimal. The smaller MAX DATA can be tied to a buffer pool not yet allocated to specific streams, and there is some possibility to get the application going with less than 2 bandwidth*delay products of buffers. But then, this optimization is precisely what leads to deadlock conditions when the transport does not quite get the priorities of the application, or when the sender does not quite get the priorities of the receiver. So we have two alternatives. One is to make the API more "expressive" so the application can tell the transport exactly which order and priorities can be applied. The other is to make the API less complex by just mandating that MAX DATA be large than the sum of MAX STREAM DATA. Or possibly removing MAX DATA altogether. -- Christian Huitema From nobody Wed Jan 10 13:54:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F7412E042 for ; Wed, 10 Jan 2018 13:54:06 -0800 (PST) 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 qkZEZwLwcUTq for ; Wed, 10 Jan 2018 13:54:05 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 E6955120725 for ; Wed, 10 Jan 2018 13:54:04 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 5so428549oth.8 for ; Wed, 10 Jan 2018 13:54:04 -0800 (PST) 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=t7wwWHi9yRsqST8dEzAIUplbEGyrJPtuqQnqgr8/ELw=; b=OsFz0g8kB5bsV5wwlsraFd5Yp+n83wkaaathGWlf4PR5gw5TW6ICtsLnN1xsiIA8Su l1GjgFPYMKulmurn4mkQNDVbijh80OAhf8Q6/dQCPazqlHlXg7XrIRvRAbHd2IC5Pn9o RMQQt7rwModM2JkOQrMlsSrSgznLCE00N+LufKHn1WnjBnyJaf98umTeo0XZ6rGhJlEq 8Wxo+LvYHe0+y+rMS3xNfbkaVpkziBoyVawhQQ8Pm4ayI8J/OnO9hcIqhBC/MrYZ2XDR +vR5y8lOUMSW1a4YQbk/4gFSDyB/uKuaLwcjPaugmlGRyNOg7he6B7lZq1iBndga9gYv ZU2A== 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=t7wwWHi9yRsqST8dEzAIUplbEGyrJPtuqQnqgr8/ELw=; b=dMMaQQ8PU3qkh5GPbahbTh0cKtmtEKxDq4L7xwXkFa7/UVhOqYnyd2/I1V1RcWAq25 fc+JV/oTRJg4nUCDkQXfn9GXZXthqNP3oOOGwg7+2t1K8WjE47muS2bCDgfvKl3UbeO+ 4AdrXia9hH7pjMo6KHdNdc7UjZFkrfdL8MKB06I838ye5GEw1a/Q1j2SdZ/4DL8SKwny zUldsFZRMRHFXKRKii6vXRt5t0/mA+K40ceNXdTXBSWMj8BqHhbd3cUoOft15MBoyskn pyXrGuB/KKpd+UUyJfYwZNqk5AtjDADsrBZvJmPI9z0QEEJZHt/fqdvQtZFXehE2ikdm Ctzg== X-Gm-Message-State: AKwxytf6QPJirfGiaIkWohdY1YrQwnQFSbXSjDLcPnvp4gC+NE0X7x9U FT/Lpwce96ODdGuAiTui1lf/ixYZnCVWgg90G/wCJw== X-Google-Smtp-Source: ACJfBov82261uv7Slrb3CsLbfylk4F+szPll8+S+3DT1yQWrNYchXLURZfhOasNo9kOyHFCTlMMjccPZ0Sfwlw3v2B0= X-Received: by 10.157.68.154 with SMTP id v26mr3748751ote.308.1515621244168; Wed, 10 Jan 2018 13:54:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 13:54:03 -0800 (PST) In-Reply-To: <65EBA092-9DEF-4C9E-9DB8-AA490CA60598@trammell.ch> References: <65EBA092-9DEF-4C9E-9DB8-AA490CA60598@trammell.ch> From: Martin Thomson Date: Thu, 11 Jan 2018 08:54:03 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: "Brian Trammell (IETF)" Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 21:54:06 -0000 On Wed, Jan 10, 2018 at 6:04 PM, Brian Trammell (IETF) wrote: > Do we have any actual numbers on how much efficiency can actually be squeezed out of allowing compression dictionaries to create unbounded dependencies between streams on common, non-pathological workloads? Dmitri ran some tests with QMIN, which doesn't create dependencies, and found that for a time compression efficiency degraded noticeably if it couldn't create dependencies. I'll let Dmitri speak to that point. The shortcoming rectifies itself reasonably quickly, though Roberto makes the point that this is precisely the point where compression matters most. It's a point that the header compression folks are still debating. (The dependencies wouldn't be unbounded. One advantage of the mechanism that QMIN proposes is that these dependencies are pretty narrowly constrained and well understood.) From nobody Wed Jan 10 14:00:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAC312E044 for ; Wed, 10 Jan 2018 14:00:39 -0800 (PST) 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 kVFquveTtZCc for ; Wed, 10 Jan 2018 14:00:36 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 CB7AC127333 for ; Wed, 10 Jan 2018 14:00:36 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id o1so433575oti.12 for ; Wed, 10 Jan 2018 14:00:36 -0800 (PST) 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=rCz6xpk2qR+KMa81tJR3qrPmnxveOzmrLwlXk1VzEw4=; b=gucuq/p47glCtuk79kHOLjk5TnHEmFenNEvZuKK4r5ZaJbvt5+egpy5nwcfM8Tl/Rw M8UCF9h08mCQkmGEUbl656VeDtED7RNyFslwH1D5v8XBjerWIEl0nehAskCXjme64QTB 22T3ulbKmyj++2oCeAqfyl3/w2Cf0RIxMCt7wGQNzYROo7fAwW4UgenHemFAn9H6wnDh KUxxJyyEppwa/OF2VyMdOSdtRcLlhM2CL3SrYUs4UXE2ZNx0z1u/4cLqUgqe61DTjEGx b2dM25zRP1KpJVQqt+cRC8cs68RBulySdEczZ0sYAzo1yQdXcRQuUV95h49P41s5U4Oa IvrQ== 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=rCz6xpk2qR+KMa81tJR3qrPmnxveOzmrLwlXk1VzEw4=; b=Wlz8kI5KX4ABq5ulRYTnMaz/K4oBDj+BRXwhQlRE4IQP79e+fvvwsAFPwvYb/WvlE3 Z/DlaWZ60qfnX4Ra2SApAcqDuq1cUbVkgTCoREXn8Qk+eK5GbRPyqTah/aG6OSnTyvj9 Vrlt90nYTstWQT41nztHxqQp3gytDwRizOxK39vevkpOk8AG5qGRyNnelnCImentEyuA Cy3pkINfTe8ZJcl21WiabZlsFtwFnwf5SKKU2tMqKmj0Iy9cmjPd9ZBS7qaPtBL6kZKu THzZ3W3F6wVORs7LeUK6tGat5w9ouYER5NuCoxqEfelaMJeOmocARvoknr/kPYZeD62e eMSQ== X-Gm-Message-State: AKwxytfKfezFh9CS/58VL0jmTolYET12lFJX6sEDyTUBII9Zp+PvzOOR eky4ciiEr5QElAefnmAF3i4pekDDxr4N5G/5n6v/9Q== X-Google-Smtp-Source: ACJfBotTqA6/4wJfeNphbIJTJhgbCoJ1qTOPrZQeswXAP6/vh1z5lufXBtmRBXHYLFvrZiDeUZziMcJzRKcIcavg7so= X-Received: by 10.157.52.155 with SMTP id g27mr14090221otc.71.1515621636052; Wed, 10 Jan 2018 14:00:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 14:00:35 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 11 Jan 2018 09:00:35 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Ted Hardie 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: Wed, 10 Jan 2018 22:00:39 -0000 On Thu, Jan 11, 2018 at 5:40 AM, Ted Hardie wrote: > The second case is one in which the protocol using the transport cannot > access Y's semantic content until X is received. In that case, it has three > potential strategies. One is not to permit the dependency to occur at all; > as you note, lots of applications have inherent dependencies or common > optimizations (e.g. FEC) that use this strategy. This turns into a limit in > the scope of what can use QUIC if this is the required strategy. > > Two is is for the using application/protocol to set up and manage its own > buffers so that it can take Y out of the receive buffer and wait for X to > arrive without blocking the transport. While that might be magical thinking > for some using protocols of QUIC, it's not clear that it always would be, as > an application protocol built with QUIC as a transport in mind could do it. > There are video cases I've worked on in the past where this > buffer-at-layer-above-the-network was the default, because multiple networks > were simultaneously being used to build the video playout buffer. Yes, there will be cases where the content can be read, AND that that content won't impose a resource penalty on the receiver such that it is still able to release flow control credit for that read. Those applications can likely manage. As you say, a video application has to maintain memory for decoding N frames and it could take data from frame X+1 and run it partway through the decoder pipeline up to the point that X arrives. That's just an exception to this general problem. > For the case you're describing, I think strategy 3/option 4 is right. But I > don't think we ought to rule out strategy one and two for all using > protocols. If you have a protocol that doesn't require or can easily avoid > these dependencies being split across streams, you get option one for cheap. > If you have an application/protocol that's built with the idea of the > application managing its own buffers for resolving these dependencies, two > is practical rather than magical. Sure. I'd expect to have that protocol opt in to that sort of exceptional handling, because having it as a default is hazardous. From nobody Wed Jan 10 14:08:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02B45126C0F for ; Wed, 10 Jan 2018 14:08:03 -0800 (PST) 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 X--P575-TbQq for ; Wed, 10 Jan 2018 14:08:01 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 7B527126B72 for ; Wed, 10 Jan 2018 14:08:01 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id h2so470437oti.5 for ; Wed, 10 Jan 2018 14:08:01 -0800 (PST) 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=gs2F8Uj8wr489TwYvVXwEGkScZfsamlP655r5GDQshE=; b=e21b+q8Hsw4gP9b5QQILL3IAZO3q9rYHrtRxGeDPX4+e7oBhi6mbdFHG71/5/BiQKL 7O0WiVwRDrkSBLGrafpcw/Kz0YZ/sNcrtiZ6RKz9LgF6UESvNbYPWZL99ndb+E04riRu dJAk1UlDVxr/xVccLUszyqaIzHVxABHV78IV6bMHBnWVLZSVliV+qRN76egU6Mi3ZCcR uCSA+0IwOVRscxtz5dY92xjmv8fh1HAGSQQyiTAlVIqoyvLVyBtbzONyzRDHGIJUlOjG F/nWRiVOAk7C0IqrIG5A84zZZOhcrddjZ3TVm2xGVnLNzDJPQsR03gA8x0o6i/IWuPb4 LHJw== 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=gs2F8Uj8wr489TwYvVXwEGkScZfsamlP655r5GDQshE=; b=FEntvrUl0I86otcSMTR4zd03Xhvlz3oG7hxGUcJ3MI+KQeRit7jiy+ipoCnU8AwMGS 9UN4474G9FhIIw3MiWVJyUf+8hADBq1gG3UkTsZXasjC/WLwb2jinKNPwKiwSRy/loVJ YfLuFTTmM6a/6/oC12w7l/9r3ywJYgu6fcqPxaQjmPHTu9P+znpT9hmcEqAyKaYzfne1 8CYVopPYtxAKuErV7AQt3GuBdiEn4wn804oSZG+j+lV6h8po+l+X7mOC6iRf3wGZJGqz WY6omldV7FyVOyatm4s/6ij8+EV3oLk4BmNbunlD/MEhtdbH3hgy/SkolkiS2+bBuR0O 318A== X-Gm-Message-State: AKwxytePeZ2/1cjWHwX/WlPB5QzjOFfw7vxN5CoL2unkD1BnJ63iNIq+ qF5g1zj54Zsx8b5bv/92v6a+kSFPvK8Svt6zfGQ= X-Google-Smtp-Source: ACJfBouqbVDHg/CPXseqaZ5ODm5S19hKeTQSQggdz+LMw9AVEyBKSCkLqx6B4NNHwQb4o0SycK4Ovf80NNUgxeReavI= X-Received: by 10.157.85.233 with SMTP id z38mr12291427oti.16.1515622080828; Wed, 10 Jan 2018 14:08:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 14:08:00 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Martin Thomson Date: Thu, 11 Jan 2018 09:08:00 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar Cc: "Charles 'Buck' Krasic" , 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, 10 Jan 2018 22:08:03 -0000 On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar wrote: >> What would this advice be? "Consume *all data* from higher priority >> streams before consuming data from lower priority streams?" > > Yes, to avoid deadlock. Priorities in h2 were always guidelines. You (and I think Buck as well) are suggesting that a dependency would be something that the transport could be bound by. That creates a dangerous schism between interpretation of priorities. In h2, if Y depends on X, a server can still send Y first. It will likely do so if Y is ready to go before X. That is, generally, h2 favours forward progress over strict adherence to priority ordering. I agree that the case that we're talking about at the transport layer is substantively different, but if we don't have other language for what we're doing, we create the potential for some really bad confusion about this mechanism. This is exacerbated by the fact that QUIC doesn't have any concrete priority mechanism built in. QUIC depends on the application protocol to feed it priority information, and that naturally tends toward having hq (and h2) dictate priority. hq will likely use the h2 idiom, which won't fit well with this notion. From nobody Wed Jan 10 14:36:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C270127599 for ; Wed, 10 Jan 2018 14:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tQEO9n8df5S for ; Wed, 10 Jan 2018 14:36:46 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1922E127369 for ; Wed, 10 Jan 2018 14:36:46 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q1so1531381qkb.9 for ; Wed, 10 Jan 2018 14:36:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=rye00CwlF86J9tl/wRNrHv768EYBONTLKjBlMGiIAMY=; b=PLQK/f18PwWH/+hO8bmF8BwJ8q8F7P/9pE0S6kC4Qyt2C0HCtxoVUt7iJn4DMgxPuO RX1fmJTy/H2maATe4OhYFSLtY1RjycfN0PM4iegkW/VGCN46xAUrSArPw0rYm7tw4ydA fmx8VYkbhuOlEUGkHvd6HKvIAojqmi0fCGds28T+MLW1KufdIWp+dhwgthUXsOlf3GP0 zJk3ajjPSys5xSk7yZDJot/OuS/90eZJMd1GkTECPZhiM8TGDLEt2/kf8VC5t6bn1zmP XObu/mdQzhHG7YQ1onRoE21juX4y7+yaTmZIMln4CM45SzzFxGmj9/8nOFyPyGYLZMZ3 g79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=rye00CwlF86J9tl/wRNrHv768EYBONTLKjBlMGiIAMY=; b=GC9I76OoCoyYVWuxmSmcxPEnKuYSM1jUew3mUiVS18Y8VjoJtuO81a0OW+qm761EyS eQFelSVriLL5+E8j0fbZQxQzjxCE0duVt2+b8xRxp0UL5Qv0XYBGtHN9SItU5AeLr/y1 4vepyliuKfYby4uYGLtyJ0gAsdUXBHSuH7A2ODDY+mMRE9rEHa6aRFTf5pOIhDq+pPFg CbidYNpUu1TMtCxYSEftkbKVZz2EFlSja/lCQ0R7nc4rfIuIy2tLLpcrArjsr2cibsGB Z0SDsL2AgUyjo7BlH6f1+EuQ2Dv1LAQP9MlqiuVbINgZ+leIymauyuEKKxosaLrEHkl4 tU0A== X-Gm-Message-State: AKwxytdb623frZeHRe9PJvEYfevMPtMd27ysAgoDp1m7fbHsvk8JKM6E zNtrFP/4c7MlhR6T3JQkbf0OUg== X-Google-Smtp-Source: ACJfBotaSyK2zTAOQcTZlZKFzOwsqnN6/SBsAheSsJxwGENBOOWLGUfZevuIbizElIR7WMv4nexyMw== X-Received: by 10.55.88.7 with SMTP id m7mr10720937qkb.142.1515623804787; Wed, 10 Jan 2018 14:36:44 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id y191sm10397083qky.63.2018.01.10.14.36.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 14:36:44 -0800 (PST) Date: Wed, 10 Jan 2018 17:36:42 -0500 From: Dmitri Tikhonov To: Martin Thomson Cc: "Brian Trammell (IETF)" , QUIC WG Subject: Re: Deadlocking in the transport Message-ID: <20180110223642.GC7007@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , "Brian Trammell (IETF)" , QUIC WG References: <65EBA092-9DEF-4C9E-9DB8-AA490CA60598@trammell.ch> 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, 10 Jan 2018 22:36:48 -0000 On Thu, Jan 11, 2018 at 08:54:03AM +1100, Martin Thomson wrote: > On Wed, Jan 10, 2018 at 6:04 PM, Brian Trammell (IETF) wrote: > > Do we have any actual numbers on how much efficiency can actually be > > squeezed out of allowing compression dictionaries to create unbounded > > dependencies between streams on common, non-pathological workloads? > > Dmitri ran some tests with QMIN, which doesn't create dependencies, > and found that for a time compression efficiency degraded noticeably > if it couldn't create dependencies. I'll let Dmitri speak to that > point. The shortcoming rectifies itself reasonably quickly, though What we have is a set of simulation results comparing QMIN (conservative: no blocking) with QCRAM and QPACK (optimistic: blocking allowed). I used two web session traces: one visiting www.netbsd.org (small trace) and another visiting www.facebook.com (larger trace). I will paste parts of two reports: 1> I integrated my QMIN library [1] into Alan's proxygen simulator [2] to 1> assess QMIN's compression performance. Specifically, we want to see how 1> QMIN performs a) in a short-lived connection and b) in a longer connection. 1> I generated two HAR files: 1> 1> - I typed in www.netbsd.org into the Location bar of my browser and 1> waited for the page to load. This resulted in 18 requests, 17 of 1> them to www.netbsd.org and 1 to www.paypalobjects.com. 1> 1> - I signed in to Facebook and clicked about a dozen links. This resulted 1> in 383 requests: about 100 to www.facebook.com, about 280 to fbcdn.net, 1> and a few odd ones like facebook.net and fbsbx.com. 1> 1> I left all loss-related simulator options unset for the initial test, as we 1> just want to look at the ideal environment compression performance first. 1> The dynamic table capacity is set to 4 KB. The results are as follows: 1> 1> (The simulator implements the latest QPACK and QMIN drafts; its QCRAM 1> implementation dates to June -- but it is better than nothing.) 1> 1> Table 1: Compression performance comparison, no packet loss 1> 1> HPACK QPACK QCRAM QMIN 1> 1> netbsd 1265/6555 1309/6555 1361/6555 2202/6555 1> Ratio: 80 Ratio: 80 Ratio: 79 Ratio: 66 1> 1> facebook, 58528/243576 61753/243576 61386/243576 63782/243576 1> blended [a] Ratio: 75 Ratio: 74 Ratio: 74 Ratio: 73 1> 1> facebook, 59325/243576 62594/243576 63462/243576 67492/243576 1> unblended Ratio: 75 Ratio: 74 Ratio: 73 Ratio: 72 1> 1> a: "blended" means that the simulator pretends that facebook.com and 1> fbcdn.net is the same domain name. This is true by default; to 1> disable, pass -blend=false on the command line. The unblended 1> simulation is closer to reality. 1> 1> How to read this table: Each entry is a compressed version of the last 1> three lines of the simulator output: 1> Uncompressed Bytes: 243576 67492/243576 1> Compressed Bytes: 67492 ====> Ratio: 72 1> Compression Ratio: 72 The second report addresses compression performance during the first few flights: 2> What I do have, however, is my short netbsd session (a HAR of which I 2> emailed to the group in an earlier email). This is as good a starting 2> point as any for drilling down into the compression performance of the 2> first few header blocks. The netbsd trace contains 17 requests to 2> www.netbsd.org; they belong to three distinct flights: 2> 2> 1. Request index.html (1 request) 2> 2. Request CSS and JS (3 requests) 2> 3. Request images (13 requests) 2> 2> It would be informative to examine compression performance in each of 2> the flights. 2> 2> Since the meeting of Dec 4, Alan added a cumulative compression ratio 2> reporting to the proxygen simulator [2]. In addition, I added a 2> per-header block compression ratio reporting to the QMIN encoder library. 2> First, compression performance comparison: 2> 2> Table 1: Cumulative compression performance comparison 2> 2> Req # QPACK QCRAM QMIN 2> 2> 1 241/39 225/42 303/27 2> 2> 2 78/58 74/60 219/35 2> 3 46/67 44/68 195/39 2> 4 47/72 52/72 188/42 2> 2> 5 52/75 52/75 110/49 2> 6 55/77 55/76 96/53 2> 7 55/78 55/78 96/57 2> 8 54/79 54/78 95/59 2> 9 50/80 50/79 91/61 2> 10 55/80 55/80 96/63 2> 11 56/81 56/80 97/64 2> 12 63/81 63/80 104/65 2> 13 52/81 52/81 93/66 2> 14 51/82 51/81 92/67 2> 15 47/82 47/81 88/67 2> 16 46/82 46/82 87/68 2> 17 79/82 77/81 94/69 2> 2> How to read this table: the two numbers separated by the slash are the size 2> of the encoded header block followed by the cumulative compression ratio. 2> These values are parsed from the simulator output: 2> 2> Encoded request=0 for host=www.netbsd.org block size=225 cumulative \ 2> compression ratio=42 2> 2> translates to 2> 2> 225/42 2> 2> (Note that the cumulative compression of all three does not match previously 2> reported results: this is because I do not take the last request into account 2> here, as it is going to a different domain.) Caveat: QCRAM and QPACK drafts have changed significantly since then. QMIN performance can be improved slightly while still keeping its non-blocking behavior. > Roberto makes the point that this is precisely the point where > compression matters most. It's a point that the header compression > folks are still debating. The opposite view is that packet loss in the beginning would have a worse impact than compression inefficiency. I am sorry to say that we do not have good simulation data to go on. > (The dependencies wouldn't be unbounded. One advantage of the > mechanism that QMIN proposes is that these dependencies are pretty > narrowly constrained and well understood.) Yes. That is, QMIN does not introduce any stream dependencies. - Dmitri. From nobody Wed Jan 10 14:39:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77CC0126BF6 for ; Wed, 10 Jan 2018 14:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 USH0Tcw3lquP for ; Wed, 10 Jan 2018 14:39:26 -0800 (PST) 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 A5E131205F0 for ; Wed, 10 Jan 2018 14:39:26 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id c78so246761ywb.13 for ; Wed, 10 Jan 2018 14:39:26 -0800 (PST) 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=UmGbE9b6VaoIvF5y0c/5hsaFe7BDVYo8se6uH4sO5Xg=; b=FHfZnJLZEQQAnXB0mYMdmRTyYM5mU6BGRCI4wdWWdV391DC1bmoREowLi+17/a8LoT MlnXoLpLoH78w/dnZ0dc9CVw0QpCl7SeJ+WKoVE8GdpVYJ/SapKgqLZXNf9E50SeDTbe baLIY25S3UlYjulz1ce2+IvUCWNW2OAqbQmO4k3plLGsGvq62qn9T+oPWXhfPApDf3nN HQUOyHwrj0/UChmpehkixsub3qBVLRS9Jzu/CqOZBJx/wcGPpXNAn+2PhlzLIQnB/k3N AB6vkOnnlU5l/u9iAAL18bCzf2whyp40glSGyiIMh7UXvFQKQVrNodZHA6yss703WwKK S7Ew== 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=UmGbE9b6VaoIvF5y0c/5hsaFe7BDVYo8se6uH4sO5Xg=; b=KCH4Sxd6VrCbmU7CidXInuvYGgHIeS9fd77TZwv33O0/aIG79LchkVx5HQrmKkgJvB BpDkEWTq1TQ+3gm+jtzQI208h7eQh6ZlNPjW8WAxQRHNnEzeK7+F7tC3ejrZmLgIsxa0 4QErw+rj2e8pn2l1Jt57ELchtPesrr9YUC7EJH3bUeg6xXjmhelEX2Ihg85Bsnmhptsa jsl9vkmIw+HJNkkpks016sX1hKZey4ps+9onQurrDPBnUr7SaqIaLg3s6yBHf/lBtjGn C10HPp0XxtQOkjFpvgD8PC/sy3l7EqNUt12SMR7EZtAMSqG3t3DVFqM/RF1UmiIUDsIg wo1A== X-Gm-Message-State: AKGB3mJONFOJczF3141t6PBzbbJse7RIcyQ0jImHiupyjghvb7pYw82u +7QEeo547DJHSCPjHvQfSDs2CVbMu9tQZPRZnPOdlQ== X-Google-Smtp-Source: ACJfBov3VcOV4HGUL+WK4jjNUTTOXQgQyDrSUT6tReQIYwoAuWDllfubfBj91fPc5O7piOdqe3Q1aoU0k3/wskj14Eo= X-Received: by 10.129.146.86 with SMTP id j83mr17612666ywg.256.1515623965399; Wed, 10 Jan 2018 14:39:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 14:39:24 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Jana Iyengar Date: Wed, 10 Jan 2018 14:39:24 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson Cc: "Charles 'Buck' Krasic" , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c08fc8612fe5d056273b499" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 22:39:28 -0000 --94eb2c08fc8612fe5d056273b499 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 10, 2018 at 2:08 PM, Martin Thomson wrote: > On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar wrote: > >> What would this advice be? "Consume *all data* from higher priority > >> streams before consuming data from lower priority streams?" > > > > Yes, to avoid deadlock. > > Priorities in h2 were always guidelines. You (and I think Buck as > well) are suggesting that a dependency would be something that the > transport could be bound by. That creates a dangerous schism between > interpretation of priorities. > > In h2, if Y depends on X, a server can still send Y first. It will > likely do so if Y is ready to go before X. That is, generally, h2 > favours forward progress over strict adherence to priority ordering. > > I agree that the case that we're talking about at the transport layer > is substantively different, but if we don't have other language for > what we're doing, we create the potential for some really bad > confusion about this mechanism. This is exacerbated by the fact that > QUIC doesn't have any concrete priority mechanism built in. QUIC > depends on the application protocol to feed it priority information, > and that naturally tends toward having hq (and h2) dictate priority. > hq will likely use the h2 idiom, which won't fit well with this > notion. > Yes, I think there's easy misinterpretation here -- something I realized today as I've had conversations about this. What I meant was specifically at the API between the app and the transport, at the sender. This is basically saying that to avoid deadlock due to dependencies across streams, the transport write API must allow the app to express strict priorities. As Buck pointed out, I think this is an extention to option (4) in that it is useful when data beyond what's allowed by the flow controller is buffered at the transport sender. --94eb2c08fc8612fe5d056273b499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 10, 2018 at 2:08 PM, Martin Thomson <mar= tin.thomson@gmail.com> wrote:
On Thu, Jan 11, 2018 at 7:32 AM, Jana Iyengar <jri@google.com> wrote:=
>> What would this advice be?=C2=A0 "Consume *all data* from hig= her priority
>> streams before consuming data from lower priority streams?" >
> Yes, to avoid deadlock.

Priorities in h2 were always guidelines.=C2=A0 You (and I think Buck= as
well) are suggesting that a dependency would be something that the
transport could be bound by.=C2=A0 That creates a dangerous schism between<= br> interpretation of priorities.

In h2, if Y depends on X, a server can still send Y first.=C2=A0 It will likely do so if Y is ready to go before X.=C2=A0 That is, generally, h2
favours forward progress over strict adherence to priority ordering.

I agree that the case that we're talking about at the transport layer is substantively different, but if we don't have other language for
what we're doing, we create the potential for some really bad
confusion about this mechanism.=C2=A0 This is exacerbated by the fact that<= br> QUIC doesn't have any concrete priority mechanism built in.=C2=A0 QUIC<= br> depends on the application protocol to feed it priority information,
and that naturally tends toward having hq (and h2) dictate priority.
hq will likely use the h2 idiom, which won't fit well with this
notion.

Yes, I think there&= #39;s easy misinterpretation here -- something I realized today as I've= had conversations about this. What I meant was specifically at the API bet= ween the app and the transport, at the sender. This is basically saying tha= t to avoid deadlock due to dependencies across streams, the transport write= API must allow the app to express strict priorities.

As Buck pointed out, I thin= k this is an extention to option (4) in that it is useful when=C2=A0data be= yond what's allowed by the flow controller is buffered at the transport= sender.

--94eb2c08fc8612fe5d056273b499-- From nobody Wed Jan 10 14:42:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D299B1241FC for ; Wed, 10 Jan 2018 14:42:26 -0800 (PST) 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 gl9o5hNcv_jN for ; Wed, 10 Jan 2018 14:42:24 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 AA3951205F0 for ; Wed, 10 Jan 2018 14:42:24 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id s3so534754otc.9 for ; Wed, 10 Jan 2018 14:42:24 -0800 (PST) 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=SMPKRNdzjp6tQXmQjZ0OuZI6iM+v+vaPGhdYPiDaDeE=; b=qjBvcLmqySnDPagGG4ujoYCYp00uzYK90t7VeS+6W0WJnXSXwBm84RF2fZ10NIOQa8 g7ZLXf61MfozmRk8sP9AsHdp5wW+4BsrqxCY2Fkbh+RdK6fgWv4skOryTF2tfqDsz0Cl xNhdUUU9eyeb2795u99hZVRmKju+Mb1VJ4gPCE2J/sUq9d0acmSknm7fhHPMSI6s+CFV GOR6/dp23Ifxb0u7cGwRuooXYrvX0CGAhpwlpcIbbNuHSCElK2wMTDLFcALMPIlHfyNW 8XvHqqZMjcuynzrbMhzxceiub4nCmvpcwXY+i2SFod8tq2nDi42DSKy7HMjOB2huWohE isZQ== 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=SMPKRNdzjp6tQXmQjZ0OuZI6iM+v+vaPGhdYPiDaDeE=; b=MKY3dHK/9cElwD6xkZ5PD7IT0zkQ879e5tvkcY06Y8LpKROCdznlOby5Wm/K7YQXXc 7SfJvs4KK+IPqgdQuS6WltulvnqGpy7NQAUOyGYB/gAkvvELqYLHXMfCj9oHUHzFBj8v 1Vijfa/2yPpwvyOV+N+Ju9vASHyG7RJkxPqqr0f1PkXhNyVkFL3gjQnScNbNy8nMQdiR SCcVksiLbJrpfX+9IQTnzOJzhh1KUlImmEbpQkDfZ7eeKmZhN5UUGFJPqYbypxXe7kar X/x7DEME5hxGIzHnVF5ZOAVNxN2pZUgw2dP4Xk/A8tCEyWC6mt6LpzTz/bAnFWCPmGjL za1w== X-Gm-Message-State: AKwxytcZvYuPf/Htg/jez0iANfWzsac+Pw1JUv0cs0LLNKpk783aqkrH 8QC5APbGWD1v4ZQvhHOlasx7YuLByKmCShFsuJM= X-Google-Smtp-Source: ACJfBovNfETW1ZTNXZw0I/GoCFI24eUA1kb+A0V4LqXypbQKmJLyy8GRApXFor1m2lXRS83i0MfyzuIpUtxAa7mEoc0= X-Received: by 10.157.85.233 with SMTP id z38mr12349113oti.16.1515624144049; Wed, 10 Jan 2018 14:42:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 14:42:23 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Martin Thomson Date: Thu, 11 Jan 2018 09:42:23 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar Cc: "Charles 'Buck' Krasic" , 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, 10 Jan 2018 22:42:27 -0000 On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar wrote: > Yes, I think there's easy misinterpretation here -- something I realized > today as I've had conversations about this. What I meant was specifically at > the API between the app and the transport, at the sender. This is basically > saying that to avoid deadlock due to dependencies across streams, the > transport write API must allow the app to express strict priorities. Ahh, excellent, then I think at least we two are in agreement. It seems like there is an emerging acceptance of the problem and proposed approach, I guess we might start considering how to address it. I think that this needs to be in the main spec. Failing to document this sort of pitfall could be fatal. Does anyone disagree? From nobody Wed Jan 10 14:55:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9109A127876 for ; Wed, 10 Jan 2018 14:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 MIhRvyF-VAlN for ; Wed, 10 Jan 2018 14:55:10 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895D41241FC for ; Wed, 10 Jan 2018 14:55:10 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id z132so268099ywd.9 for ; Wed, 10 Jan 2018 14:55:10 -0800 (PST) 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=XQi7u4DWiiXEteilSHdYGSPJuXCcFjXW7KTgw+2pmY0=; b=sBfH1r+8o9MH5/c+6yW6tOLb8ubij+urhoxq/eTwGO78Kv+Il/z2iAOm887Zr5W04h ZhgGC9q7TFKGnmpNCul+8DE+z6KWXCun7secEKy7ryh7+gzCRtU1tY0mHNwRK329+HCV zJg5/JVOJdIbDAEu0QYYpfJMF8VZraFSCYDLttLl6pgLVc9Vdc1uDxwIZA3hBrmfMpf5 2iBPc+uSfhSS8xBBRFEj1X0+Evi+us3qRU8/2XHy4QAtOCqnSO009XY+tlZ9OCJ6d98F AlrcfABYumMQWhff7cyGSe73A1J9C4gEBcfe79z28QJ/oOEs2CYyOgilGt7XT6utyKsh GtrQ== 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=XQi7u4DWiiXEteilSHdYGSPJuXCcFjXW7KTgw+2pmY0=; b=hAel0tX1wbL+DVCpoEDYTZBVWTGcp6j0kEfvA3ooC11/C0XrksWA51vFsp8VpFL+ST NC0BeP2eCvpuPG5WQ5OicitIX9vC6TU6NLZyD3ow6O1QMqj5Diifk9V7n2s3m4k70XrA GaVBBSQD6p2FKFXqFkhEnMzRabGrnezfuF7BjJGxzxfpdTsos5ilELbT+9b99OBIeAKq TnT9KGojCvsdj4sgmDnkaWo4PM78QqDJ9AFeUq51h2ixKujD1ROKaCFqiLs5R0UQ0Rse nNZh7DPXWuBt1sYQkmCMyIKM+jstderl4LklvQ/ujWM1Bw/2es9AAg1IcAgjq7GNKV2c S2zQ== X-Gm-Message-State: AKGB3mKPHIw2ymDllCWKTrl9iBIsoUQL7Uw3LFiWSw4nE4B3qM/rDsEn WmQQBF/Bfmxr6o9TrwknxzglZxPmJr6a1SwjxJrcsQ== X-Google-Smtp-Source: ACJfBouwZycLDfc/XaDZ1pna8tZqYBgDARXYuFnq6xSMKjrqpA5C/i3vhgTFp/ymOIOcjuqrjsTMmhzWyxQ6CrpWDFM= X-Received: by 10.129.146.86 with SMTP id j83mr17635928ywg.256.1515624909255; Wed, 10 Jan 2018 14:55:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Wed, 10 Jan 2018 14:55:08 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Jana Iyengar Date: Wed, 10 Jan 2018 14:55:08 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson Cc: "Charles 'Buck' Krasic" , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c08fc8654ac59056273ec19" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 22:55:12 -0000 --94eb2c08fc8654ac59056273ec19 Content-Type: text/plain; charset="UTF-8" > > Ahh, excellent, then I think at least we two are in agreement. It > seems like there is an emerging acceptance of the problem and proposed > approach, I guess we might start considering how to address it. > I think so. I've heard some other approaches aired that folks may want to discuss however. > I think that this needs to be in the main spec. Failing to document > this sort of pitfall could be fatal. Does anyone disagree? > I agree that we should document this, especially since it's expected to be a common design pattern. Since we don't express dependencies among streams, we have to ensure that an app that wishes to do so doesn't do the wrong thing. I think we definitely should draw attention to this point, but I'm not sure that we need to be very prescriptive here for what the app should do, but I think we should use strong language for what a transport implementation should do. We should also mention that an app that chooses to not read out of a stream buffer may cause negative interactions with any autotuning mechanisms implemented to tune window update magnitude and frequency. --94eb2c08fc8654ac59056273ec19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ahh, excellent, then I think at least we two are= in agreement.=C2=A0 It
seems like there is an emerging acceptance of the problem and proposed
approach, I guess we might start considering how to address it.

I think so. I've heard some other approaches a= ired that folks may want to discuss however.
=C2=A0
I think that this needs to be in the main spec.=C2=A0 Failing to document this sort of pitfall could be fatal.=C2=A0 Does anyone disagree?

I agree that we sho= uld document this, especially since it's expected to be a common design= pattern. Since we don't express dependencies among streams, we have to= ensure that an app that wishes to do so doesn't do the wrong thing. I = think we definitely should draw attention to this point, but=C2=A0I'm n= ot sure that we need to be very prescriptive here for what the app should d= o, but I think we should use strong language for what a transport implement= ation should do.

We should also mention that an app that chooses to not read out = of a stream buffer may cause negative interactions with any autotuning mech= anisms implemented to tune window update magnitude and frequency.
--94eb2c08fc8654ac59056273ec19-- From nobody Wed Jan 10 14:55:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF2129C6A for ; Wed, 10 Jan 2018 14:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_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=evequefou.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 UWS2cf4tOo2u for ; Wed, 10 Jan 2018 14:55:49 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.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 E65A8129C51 for ; Wed, 10 Jan 2018 14:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h3KbHIk3opF11a4FGiuFV7tIlwKAhZNzPiInt1ARgso=; b=Lwt7qU7EiGOngrTyocMlmmHtHVneaWaH8HDy7q7lT51oo4g3O5wfQpWXdFhDlRYVesAlQ/qS/aDDhiH+kAGYExBKNZhvidfp37m/3jcLNsOmL0MuQGi1SgtFDSrq2IHhMOw5uRclm4mGx4oqhUgeny7vcwpMnOb71YhlOGAopR4= Received: from CY4PR08MB2423.namprd08.prod.outlook.com (10.168.169.142) by CY4PR08MB2422.namprd08.prod.outlook.com (10.168.169.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Wed, 10 Jan 2018 22:55:46 +0000 Received: from CY4PR08MB2423.namprd08.prod.outlook.com ([10.168.169.142]) by CY4PR08MB2423.namprd08.prod.outlook.com ([10.168.169.142]) with mapi id 15.20.0386.008; Wed, 10 Jan 2018 22:55:46 +0000 From: Mike Bishop To: Martin Thomson , Jana Iyengar CC: QUIC WG , Charles 'Buck' Krasic Subject: RE: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidqxAzZR0+xwkEuHcB1dPwao4qNsqpwAgAC3uoCAAB3vgIAAA6mAgAAEuICAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADWgIAAATfg Date: Wed, 10 Jan 2018 22:55:46 +0000 Message-ID: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR08MB2422; 7:TucqmBR7Cc67xnabA2mpDCsid7rKehY3kofEgyTI4UICDafE1gG03I0HMzSBgCuHPgKrvEu6TTER3PfcBqsZcwwsmzjr+bux39h4wUFLEi8fT9ncuGtVPn96/OHKUsoBQ7PLX1XZnj8roWN4PiSd8LzIiXvvNjmwEKQMDjSWQFCXhIQjTbkdBCl7HreRQHvmxdoQMyLlQmflXij3T9woRW1kYlo43kLmsNxphbCEpHRIzSTORCGyOaBq5VdrVQdh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5a77d8ff-64b4-45e8-2e80-08d5587d4908 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020057)(4652020)(7021087)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR08MB2422; x-ms-traffictypediagnostic: CY4PR08MB2422: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(944501125)(3002001)(10201501046)(93006095)(93001095)(6041268)(2016111802025)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:CY4PR08MB2422; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR08MB2422; x-forefront-prvs: 0548586081 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(396003)(376002)(366004)(346002)(39380400002)(189003)(199004)(24454002)(13464003)(51444003)(54906003)(9686003)(2950100002)(93886005)(305945005)(55016002)(3846002)(25786009)(86362001)(97736004)(316002)(2900100001)(68736007)(74316002)(105586002)(14454004)(6116002)(6436002)(7736002)(110136005)(53936002)(77096006)(478600001)(76176011)(3480700004)(229853002)(81166006)(102836004)(4326008)(8936002)(53546011)(2906002)(39060400002)(59450400001)(66066001)(99286004)(81156014)(8676002)(5660300001)(6506007)(106356001)(6246003)(3660700001)(33656002)(3280700002)(74482002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2422; H:CY4PR08MB2423.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: dbrHlNu0yzzk9/MzNsC36nqQIwblfZtrSDwxTnsabmkg1x/kvPzrZR/7Ko2Q4BOeCzSSFXoSvL9AKn4w2PLlQg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 5a77d8ff-64b4-45e8-2e80-08d5587d4908 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2018 22:55:46.0816 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2422 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 22:55:52 -0000 Tm8gZGlzYWdyZWVtZW50LiAgV2hlbiBjaG9vc2luZyB3aGljaCBzdHJlYW0gKndpdGggcGVuZGlu ZyBkYXRhKiB0byBtYWtlIHByb2dyZXNzIG9uLCBJIHRoaW5rIGNob29zaW5nIHRoZSBoaWdoZXIt cHJpb3JpdHkgc3RyZWFtIGlzIG5lY2Vzc2FyeSByYXRoZXIgdGhhbiBhZHZpc29yeS4gIFdpdGgg SDIsIHdlJ3JlIHRhbGtpbmcgYWJvdXQgY2xpZW50IHByZWZlcmVuY2VzIGFib3V0IHNlcnZlciBy ZXNwb25zZXMgd2hpY2ggbWlnaHQgbm90IGJlIHJlYWR5IHlldCwgc28gaXQncyBhbHdheXMgYWR2 aXNvcnkgdG8gdGhlIHNlcnZlci4gIEhlcmUsIHdlJ3JlIHRhbGtpbmcgYWJvdXQgdGhlIGFwcGxp Y2F0aW9uJ3MgcHJlZmVyZW5jZXMgYWJvdXQgaXRzIG93biBkYXRhIHRoYXQgaXQgaGFzIGFscmVh ZHkgaGFuZGVkIG9mZi4gIFRoYXQncyBzb21ldGhpbmcgdGhhdCBoYXBwZW5lZCB3aXRoaW4gdGhl IEhUVFAvMiBpbXBsZW1lbnRhdGlvbiwgc28gdGhlcmUgd2FzIG5vIGFncmVlbWVudCBvciBjb250 cmFjdCBuZWVkZWQuDQoNClNvIGxvbmcgYXMgdGhlIGRlcGVuZGVuY3kgaXMgc3RyaWN0bHkgb24g YSBoaWdoZXItcHJpb3JpdHkgc3RyZWFtIGFuZCB0aGUgdHJhbnNwb3J0IGxheWVyIGlzIGhhbmRs aW5nIHByaW9yaXRpZXMgc3RyaWN0bHkgd2hlbiBjaG9vc2luZyB3aGF0IHRvIHNlbmQgaW4gYSBm bG93LWNvbnRyb2wtbGltaXRlZCBzaXR1YXRpb24sIEkgdGhpbmsgd2UgYXZvaWQgdGhlIGRlYWRs b2NrLiAgVGhhdCBpcywgd2hlbiBYIGRlcGVuZHMgb24gWSwgaWYgbmV3IGZsb3cgY29udHJvbCBj cmVkaXQgaXMgZ3VhcmFudGVlZCB0byBjYXVzZSBZIHRvIG1ha2UgZm9yd2FyZCBwcm9ncmVzcyAo YW5kIHRoZSBvdGhlciBzaWRlIGlzIGNvbnRpbnVpbmcgdG8gcmVhZCBmcm9tIFkncyBzdHJlYW0p LCB0aGUgb3RoZXIgc2lkZSB3b3VsZCBldmVudHVhbGx5IGJlIGFibGUgdG8gcHJvY2VzcyBYLg0K DQpUaGlzIGlzbid0IGEgcHJvdG9jb2wgZWxlbWVudCwgYnV0IGFuIGltcGxlbWVudGF0aW9uIGVs ZW1lbnQgdGhhdCdzIG5lY2Vzc2FyeSBmb3IgdGhlIHByb3RvY29sIHRvIGJlIGZ1bGx5IGZ1bmN0 aW9uYWwuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6 IFdlZG5lc2RheSwgSmFudWFyeSAxMCwgMjAxOCAyOjQyIFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxq cmlAZ29vZ2xlLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgQ2hhcmxlcyAnQnVj aycgS3Jhc2ljIDxja3Jhc2ljQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogRGVhZGxvY2tpbmcg aW4gdGhlIHRyYW5zcG9ydA0KDQpPbiBUaHUsIEphbiAxMSwgMjAxOCBhdCA5OjM5IEFNLCBKYW5h IEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPiB3cm90ZToNCj4gWWVzLCBJIHRoaW5rIHRoZXJlJ3Mg ZWFzeSBtaXNpbnRlcnByZXRhdGlvbiBoZXJlIC0tIHNvbWV0aGluZyBJIA0KPiByZWFsaXplZCB0 b2RheSBhcyBJJ3ZlIGhhZCBjb252ZXJzYXRpb25zIGFib3V0IHRoaXMuIFdoYXQgSSBtZWFudCB3 YXMgDQo+IHNwZWNpZmljYWxseSBhdCB0aGUgQVBJIGJldHdlZW4gdGhlIGFwcCBhbmQgdGhlIHRy YW5zcG9ydCwgYXQgdGhlIA0KPiBzZW5kZXIuIFRoaXMgaXMgYmFzaWNhbGx5IHNheWluZyB0aGF0 IHRvIGF2b2lkIGRlYWRsb2NrIGR1ZSB0byANCj4gZGVwZW5kZW5jaWVzIGFjcm9zcyBzdHJlYW1z LCB0aGUgdHJhbnNwb3J0IHdyaXRlIEFQSSBtdXN0IGFsbG93IHRoZSBhcHAgdG8gZXhwcmVzcyBz dHJpY3QgcHJpb3JpdGllcy4NCg0KQWhoLCBleGNlbGxlbnQsIHRoZW4gSSB0aGluayBhdCBsZWFz dCB3ZSB0d28gYXJlIGluIGFncmVlbWVudC4gIEl0IHNlZW1zIGxpa2UgdGhlcmUgaXMgYW4gZW1l cmdpbmcgYWNjZXB0YW5jZSBvZiB0aGUgcHJvYmxlbSBhbmQgcHJvcG9zZWQgYXBwcm9hY2gsIEkg Z3Vlc3Mgd2UgbWlnaHQgc3RhcnQgY29uc2lkZXJpbmcgaG93IHRvIGFkZHJlc3MgaXQuDQoNCkkg dGhpbmsgdGhhdCB0aGlzIG5lZWRzIHRvIGJlIGluIHRoZSBtYWluIHNwZWMuICBGYWlsaW5nIHRv IGRvY3VtZW50IHRoaXMgc29ydCBvZiBwaXRmYWxsIGNvdWxkIGJlIGZhdGFsLiAgRG9lcyBhbnlv bmUgZGlzYWdyZWU/DQoNCg== From nobody Wed Jan 10 14:56:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D03612D7E9 for ; Wed, 10 Jan 2018 14:56:39 -0800 (PST) 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 BThcsHW4V3l8 for ; Wed, 10 Jan 2018 14:56:35 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B89512D7E8 for ; Wed, 10 Jan 2018 14:56:25 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id f143so1366665itb.0 for ; Wed, 10 Jan 2018 14:56:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=snBlLEWD3NIZ+AUjImN0U0VBcMlUQTLG/+Ga2270GtY=; b=t7NQRdSOXyC2/8Aa/sjS4ddx01n8qXQB+fLR86Cqbgu1qLvZF+o9bcykrmxD6h3748 T+BallKMOQzPFRIYUMUAnBbVkixk/7W14K9Cmdx/zZXF0sjQbcZPEWMsvikWBSR8hNFP vCXf++NZWevq4lQ9MUDs79vbDmG2KX5+MBiT2fkjU5H/lHL+q+tnSC7q1rwb7SJjf3ZP 5nbIYfRB7eRyTzchh3zdo24FnCoI6h40wD1CzVR1AV9Oy6DXIx8IlfhaTI/dGbkINDpk UOIc9k8F1/UYHHWHsoqvwUt9isMVRjk5dsCR37j7bzCGY1tOuMm9tTHJ7CpHqHoOk8ZY owRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=snBlLEWD3NIZ+AUjImN0U0VBcMlUQTLG/+Ga2270GtY=; b=fe54xuHnSLIPSvR5ed0uFkhG7HJAChkvb6HBueCeKfequKXlLGhfmTIXxmka2eLuB6 /cJ07cv5DHlm08B7UK3u+KDiYSBQJl6b7TCuGNzpk5KT7Et54o5MKvCn+M9FS1lW5jiR LpU5rFCga5YdLrfd5whW+8O1Fu3D4Js/P5KI9ZAMwYZOgs+wg0Dp7aXxLrPMZxYczuE9 zxABrmNQ7ZUHHhwaRyefA0lbToEGN/akfPCGSaCm39fIG853jh08jhnbLfyaN1nc2w75 xxBTyGL3XGW5PVmCKSKQjJ2sTeKFVFWKgUNXKoInYdnm14fyaSEfpqmTuQRXtEbFh4HO 0Vvw== X-Gm-Message-State: AKwxyteVkeufRmvGYTNUkS84NxR8o6tF3/rHFvnGoWGDQrZm1pzzIzc1 E7PjSvtdpz8+W6t8N6Da2gw/sFXnacuSay/wGbk= X-Google-Smtp-Source: ACJfBovNzre8eLnt/9wk+Wm7FL2Z4DYCu5/T644McR5gxFsWyMqhV+hCunxGSZkIz/iPAt6WzIs5UgN/P3eUaIoICkc= X-Received: by 10.36.0.209 with SMTP id 200mr14533339ita.4.1515624984984; Wed, 10 Jan 2018 14:56:24 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 17:56:23 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 17:56:23 -0500 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson , Jana Iyengar Cc: "Charles 'Buck' Krasic" , QUIC WG Content-Type: multipart/alternative; boundary="001a11c14088d7c30a056273f06b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Jan 2018 22:56:39 -0000 --001a11c14088d7c30a056273f06b Content-Type: text/plain; charset="UTF-8" I think that this needs to be in the main spec. Failing to document this sort of pitfall could be fatal. Does anyone disagree? I agree with the idea which I find it important. But I disagree with strict priorities. It should be possible to for lower priorities to communicate with reduced throughput which is readily handled by a pacing algorithm. There need to be some guarantees for priority 0 though. --001a11c14088d7c30a056273f06b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I think th= at this needs to be in the main spec. Failing to document=C2=A0
this sort of pitfall could be fatal. D= oes anyone disagree?=C2=A0

I agree with the idea which I find it = important. But I disagree with strict priorities. It should be possible to = for lower priorities to communicate with reduced throughput which is readil= y handled by a pacing algorithm. There need to be some guarantees for prior= ity 0 though.

--001a11c14088d7c30a056273f06b-- From nobody Wed Jan 10 15:59:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C5612D7E8 for ; Wed, 10 Jan 2018 15:59:51 -0800 (PST) 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 i-fkUJ3IMNYs for ; Wed, 10 Jan 2018 15:59:49 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 0FB16127058 for ; Wed, 10 Jan 2018 15:59:49 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id j129so516319oib.12 for ; Wed, 10 Jan 2018 15:59:49 -0800 (PST) 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=cM9SRjARZaG7SHAsenNdPdKwdrZJj4s9HOSl648P6UQ=; b=S3levthhqSMvBxac0fxIjpMoJy24g/Lh5FBOIlOL+By5ZIly9MRLPuj2TWwB4JyThi vr2KhAMYkU/RsgIUAmG1qo6LbghJJQCKjFkyvjAxkHQfxj9434OXvDIIak7K4gi0onm1 wssceX7hubS+7kZNwntcPdzVt+VIqD5BDKGnBiPiGsuIhtqW2SP1l4udHl9+FjOxv0CT xf/23F76UO75KTxrmJXCV2PUW/FBLb5K1rLDLPn5/qXKFI2PJgCEvVdrR01epHqED6jK mk1PVdELipm4mokcWVudGFCF5e0UK++l7JoX/ZogY9FN2muj36zdRdhkU2zSSufUPNZg Xs7A== 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=cM9SRjARZaG7SHAsenNdPdKwdrZJj4s9HOSl648P6UQ=; b=Nt8NjauTlVZK98pE5aeGZV4t8tpvkXIfAx9SYuRJXdwYA956Vxh1ZS1xusn7wg5U5i m0Ru2FhLqzmvfQatbsbUKxaa7IAxwoUjfx42TqQhpnFTuO7xtTE0upRVkU2U1eF6MlLS eFSwoAswTVLLiTb/2m5vB8GcenXDa69WLA+x85g/btpVIhqqVpB1QHCFqWxpTzdoix4n KOVbxpEITqDRN6jbxC7ker6yw62GcCx6bsEpWXMdrS6YCT5LlBT70afLEDvuMYEV/StW ytdjM5iaKn8ySlWNRvSau5S/biSzdM7etaSMhTlIyN8jExoqm5D2JTw4Es8ezU838Qrv jZqQ== X-Gm-Message-State: AKwxytdUbWVQN2b0NSUnaTvjNPPgp/OtAe82krJsT5IxuFvBv1/NBBw+ QExQS9EAAPwn3S3gnn7mdq1fncZ8I/W6lungrPk= X-Google-Smtp-Source: ACJfBosyceqC7INgsdT0Qr9I+Rkg0XD1k8AXF/2MX3a9O4xgPyaLUBhO2CHbB2N+eW7uFzIJkJbLVc/QGLuf8sWnNhc= X-Received: by 10.202.205.145 with SMTP id d139mr3704128oig.84.1515628788221; Wed, 10 Jan 2018 15:59:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 15:59:47 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Martin Thomson Date: Thu, 11 Jan 2018 10:59:47 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Jana Iyengar , "Charles 'Buck' Krasic" , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 23:59:51 -0000 On Thu, Jan 11, 2018 at 9:56 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I think that this needs to be in the main spec. Failing to document > this sort of pitfall could be fatal. Does anyone disagree? > > I agree with the idea which I find it important. But I disagree with stri= ct > priorities. It should be possible to for lower priorities to communicate > with reduced throughput which is readily handled by a pacing algorithm. > There need to be some guarantees for priority 0 though. See what I mean when I said that talking about this in terms of priorities is hazard? If you have a concrete dependency, then reducing throughput doesn't solve the issue. At best, it might hide the issue by reducing probability. The language problem is that we can sometimes express a dependency in a priority scheme, such as the one in h2. This is fundamentally different to that particular scheme in that it isn't something that can be fudged or ignored. From nobody Wed Jan 10 16:09:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA812D7E8 for ; Wed, 10 Jan 2018 16:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 4BtEGiOTvSy9 for ; Wed, 10 Jan 2018 16:08:59 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 CB6C1127058 for ; Wed, 10 Jan 2018 16:08:58 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id c17so1380130iod.1 for ; Wed, 10 Jan 2018 16:08:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=F95DPAs8J6cpqpibOJF5dCPWd1CSWvFawuxgmYffezM=; b=hYrtjjt+Fay8/DNHAdFLyfLHV+sfZ6d+CzqKAxrtJru0fS4ZpvsubufTMH5mIiDh4O cgzQLddnr2vKD2fwVhxNxu5dClLAT5MKwfqN3TjF/adZ2KYqjv1JcX7yffwki52el6ue BaAWExMBxPro319BGc9YeqPHb5vi+rxOyk8FJm+KuQqTjpfLbGLWb3oVNZgMVYlGEhiQ SYPv20geVanMPQWTYOOALN3sbT9NiWIcDmFvHwU6chxpN1D8cu6a4uy1er/9IJEuSvHt WmRO4RrpG3gBYNzlMbdVhuAGeT976LXTgPlppkrZF2ONXAfHOB+DWtMumvL4hNTPKBvC uaNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=F95DPAs8J6cpqpibOJF5dCPWd1CSWvFawuxgmYffezM=; b=arXFur1BdaF6a6YRldQVOHBRDwXzXMgQzThcATPaC9keKsNsXV289IBzbfazH8meRk PdnygGXomjUtaUFwrmRAOurTkZwuRQV+R/DbWjs0Ap2gVF0RcyuuQApC0JaGRF1y/6xw OgTG5HKfDdspjQhmwDsxPYgw8yZbo0nbcOj+mMf5wV0vnHFsiebQzs7PUV0MQ9A/A+rX R46vNAn/wwdw5no28H3DW4zzA3+30VfaU0oHirVlGJGvXhldDNax1y0W3Mj+5/oBbCDl XNnCBz4tzhZuyoin4/PTWenTuWPNfSnaJwwhlMXnsNhdqxGrLqR/8bBbvHNdwOuzuvr3 oeaQ== X-Gm-Message-State: AKGB3mI0qAPeLZ93Jm04IzT13S/GCtt7UTpJb/KrVtnK8WZxzfIQ3eDw g35c9oe1RkdMMV6Y/xIxsWWPM6/vFSQWOV63Uw4= X-Google-Smtp-Source: ACJfBoutzOu2yd+HSOBgwOMKvLB1Gyab4zu4GLf02ts0W7Kn4Jmh21pIZieCW5oMWLCSCXtR98SZC4Xd0vK8M7j0BaI= X-Received: by 10.107.168.73 with SMTP id r70mr19094312ioe.16.1515629338106; Wed, 10 Jan 2018 16:08:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 10 Jan 2018 19:08:57 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 10 Jan 2018 19:08:57 -0500 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson Cc: "Charles 'Buck' Krasic" , Jana Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="001a11426b784f20ea056274f450" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 00:09:01 -0000 --001a11426b784f20ea056274f450 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m not sure we disagree, but it is hard to formulate exact. An example is a bus and 2 car lanes, and a bicycle lane. You don=E2=80=99t = stop all traffic to ensure a bus can get through, but you reserve some capacity for priority. My concern is that you create a presidential cortege where you close the highway for all other traffic for some hard to predict interval. It might solve the primary deadlock but could generate others, and have other unintended side effects. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 11 January 2018 at 00.59.48, Martin Thomson (martin.thomson@gmail.com) wrote: On Thu, Jan 11, 2018 at 9:56 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I think that this needs to be in the main spec. Failing to document > this sort of pitfall could be fatal. Does anyone disagree? > > I agree with the idea which I find it important. But I disagree with strict > priorities. It should be possible to for lower priorities to communicate > with reduced throughput which is readily handled by a pacing algorithm. > There need to be some guarantees for priority 0 though. See what I mean when I said that talking about this in terms of priorities is hazard? If you have a concrete dependency, then reducing throughput doesn't solve the issue. At best, it might hide the issue by reducing probability. The language problem is that we can sometimes express a dependency in a priority scheme, such as the one in h2. This is fundamentally different to that particular scheme in that it isn't something that can be fudged or ignored. --001a11426b784f20ea056274f450 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m not sure= we disagree, but it is hard to formulate exact.

An example is a bus and 2 car lanes, and a bicy= cle lane. You don=E2=80=99t stop all traffic to ensure a bus can get throug= h, but you reserve some capacity for priority.

My concern is that you create a presidential cort= ege where you close the highway for all other traffic for some hard to pred= ict interval. It might solve the primary deadlock but could generate others= , and have other unintended side effects.


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

On 11 January 2018 at 00.59.48, Martin Thomson (<= a href=3D"mailto:martin.thomson@gmail.com">martin.thomson@gmail.com) wr= ote:

On Thu, Jan 11, 2018 at 9:56 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen
<mikkelfj@gmail.com> wr= ote:
> I think that this needs to be in the main spec. Failing to documen= t
> this sort of pitfall could be fatal. Does anyone disagree?
>
> I agree with the idea which I find it important. But I disagree wi= th strict
> priorities. It should be possible to for lower priorities to commu= nicate
> with reduced throughput which is readily handled by a pacing algor= ithm.
> There need to be some guarantees for priority 0 though.

See what I mean when I said that talking about this in terms of
priorities is hazard? If you have a concrete dependency, then
reducing throughput doesn't solve the issue. At best, it might hid= e
the issue by reducing probability.

The language problem is that we can sometimes express a dependency in
a priority scheme, such as the one in h2. This is fundamentally
different to that particular scheme in that it isn't something that
can be fudged or ignored.
--001a11426b784f20ea056274f450-- From nobody Wed Jan 10 16:11:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57528126CB6 for ; Wed, 10 Jan 2018 16:11:05 -0800 (PST) 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 HnYp0Vt4Blim for ; Wed, 10 Jan 2018 16:11:03 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 10E23126C22 for ; Wed, 10 Jan 2018 16:11:03 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id p16so716070otf.1 for ; Wed, 10 Jan 2018 16:11:02 -0800 (PST) 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=/XnC0fEUVJPqahKLg/ZQxy0ubne1bt/5Ut0/lqx+09E=; b=ndxxG9xGa02JQ9YYHg0PTGmi5J/AIZAQ/1RZKnNheqGAl50dvobpUFeGxhdkjheb4n vTOS4m3Cj7VqCOfXlktf5qjnr5JeZnQ94x/UAvF/I4EqK1NnAg3JMbPJY/HuOayncRID z8ZejPFiOT9UQ6cdFWi6QRGhR7yzmvUpCuiHwhUfLryJ8L8BWOtCW5FPrCxG6NAUxPop mkyLJS1R0RJJNO4INiWczs9iVRDtCmCkk2KpgGloy0pj+22QzvCyoqDg/eCQzO67ByHT +q8kwKPWj3dKR+0L3aefgVvAFE6ZJrNyokPdUDtwLoBZv0xA585H89jbmKJer1adeMs1 CsFQ== 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=/XnC0fEUVJPqahKLg/ZQxy0ubne1bt/5Ut0/lqx+09E=; b=lIl/JdS+DDDWFBq1BDinB9sIgLiMS3TXRYQ7mT8Dgf7hx79GM0UUD/TQCn3f7CWwh5 ULYxJAcfCmgItJ9aJFk/1SAXprtv2UOfzAYkj3oRU9w0AVPY1GW+bgl39klKDNVndyv7 iaUzQAbkTzzblQVsZZZjoAAponpIZsFniHyEm3DPWvGB7mbCjuDsC/PcRNlxW9LOEjw9 BFAprvklsjaFR87V9xFmnxwlYxwfX1WTHnk2gCz+d3zTAijWuV87JfzDN1Kthvt6d5PD KhUYg+USJzIUkhFIc+/tRVSz2ED1sz0qjkt3scuXJsDONlqU4WjQwVt5OEywt3uv7qEt mcyQ== X-Gm-Message-State: AKwxytff88fAAWxGK0NhL6KFihb6yNTyIo6nkNTVr7gXoNoj7yKw74Yx 3aST/gy94jsx38PDmxafJ/r+lBYFWdMhiobwa0Q= X-Google-Smtp-Source: ACJfBou/jcWfRn60xCcnKIvOmAITh2KB0AHP7GC9URvs198U59ar8J9g0ZwJx78dBbqCj+Db1vbYksB9HkQhEl+s01E= X-Received: by 10.157.72.138 with SMTP id d10mr6286707otf.93.1515629462145; Wed, 10 Jan 2018 16:11:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 10 Jan 2018 16:11:01 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> From: Martin Thomson Date: Thu, 11 Jan 2018 11:11:01 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Charles 'Buck' Krasic" , Jana Iyengar , QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 00:11:05 -0000 I don't think that those analogies are accurate in this context. Maybe a better analogy would be a truck and the oversized trailer it pulls. You can't put the oversized trailer into three adjacent lanes before the truck. On Thu, Jan 11, 2018 at 11:08 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I=E2=80=99m not sure we disagree, but it is hard to formulate exact. > > An example is a bus and 2 car lanes, and a bicycle lane. You don=E2=80=99= t stop all > traffic to ensure a bus can get through, but you reserve some capacity fo= r > priority. > > My concern is that you create a presidential cortege where you close the > highway for all other traffic for some hard to predict interval. It might > solve the primary deadlock but could generate others, and have other > unintended side effects. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 11 January 2018 at 00.59.48, Martin Thomson (martin.thomson@gmail.com) > wrote: > > On Thu, Jan 11, 2018 at 9:56 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: >> I think that this needs to be in the main spec. Failing to document >> this sort of pitfall could be fatal. Does anyone disagree? >> >> I agree with the idea which I find it important. But I disagree with >> strict >> priorities. It should be possible to for lower priorities to communicate >> with reduced throughput which is readily handled by a pacing algorithm. >> There need to be some guarantees for priority 0 though. > > See what I mean when I said that talking about this in terms of > priorities is hazard? If you have a concrete dependency, then > reducing throughput doesn't solve the issue. At best, it might hide > the issue by reducing probability. > > The language problem is that we can sometimes express a dependency in > a priority scheme, such as the one in h2. This is fundamentally > different to that particular scheme in that it isn't something that > can be fudged or ignored. From nobody Wed Jan 10 20:54:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC3712E891 for ; Wed, 10 Jan 2018 20:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gaTcFMv7lrJN for ; Wed, 10 Jan 2018 20:54:24 -0800 (PST) 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 2C17712E88D for ; Wed, 10 Jan 2018 20:54:24 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0B4q30U008192; Thu, 11 Jan 2018 04:54:18 GMT 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=fQakvMF9HUyJlTMGcN/dMvwS2SprmcrpmLIszOgG4YE=; b=mORppK/r9A17YbKAEfD0owD2WWAXc7uZ3iDsmDQCcJ/YYcECPy0/xw0op+v0voXuXFwv cQEz4dZ1PghGvTI6bZOdMrUMYVXb0bu/lGR/Wfq0vVQwwaZl26zelgMHbMbxu+mHbrEc iX90uavzrBlsKtMpEMh9Vciex/8TdcztGUfBOL6cuqw8w9MsarRKzEyOOtbYseM/QI59 NEz7sCShKFeSeY8fMH7LJhW+ZB9lmm8kVThpaMCik2/v+KY0Y/880VGDJ7eFyFEsYqZ1 KM5beiomwmHCDfK1e3tqH9AVN3vcRN68YlSF1FMOvDsGYnu7NHPbaZQwp3JexnYrdFn6 lA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2fda90n4w1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 04:54:17 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0B4ogZ4030837; Wed, 10 Jan 2018 23:54:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fatpe5897-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 10 Jan 2018 23:54:16 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 10 Jan 2018 23:54:15 -0500 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, 10 Jan 2018 23:54:15 -0500 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, 10 Jan 2018 23:54:15 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "jri@google.com" , "mbishop@evequefou.be" CC: "quic@ietf.org" , "ckrasic@google.com" Subject: RE: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidqwSZojuevrjEKuWaFfJc7FkKNs/m4AgAC3uoCAAB3ugIAAA6mAgAAEuYCAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADVgIAAA74AgAAQVsA= Date: Thu, 11 Jan 2018 04:54:14 +0000 Message-ID: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@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 Content-Type: multipart/alternative; boundary="_000_d8fc96a972bb43c5b6e13fc60c8bc9adusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=550 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110063 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=501 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110063 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 04:54:27 -0000 --_000_d8fc96a972bb43c5b6e13fc60c8bc9adusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mandating a strict priority order on the sender may cause an increase in HO= L blocking, if the contents of a higher-priority stream are not needed by a= ll lower-priority streams. That happens when a higher-priority stream has M= AX_STREAM_DATA that allows the sender to keep transmitting on that stream e= xclusively for 1-2 rtt, but one of the early packets is lost. The entire co= nnection is blocked till that one loss is repaired. The value of MAX_STREAM_DATA cannot be reduced below 1-2 rtt-worth of data,= in case the higher-priority stream is the only stream with data. A transport wishing to minimize HOL blocking may decide to allocate bandwid= th in an other than strict priority order. Or the transport API would need = to be very versatile to convey strict stream dependency graphs as well as s= tream priorities. -----Original Message----- From: Mike Bishop [mbishop@evequefou.be] Received: Wednesday, 10 Jan 2018, 5:55PM To: Martin Thomson [martin.thomson@gmail.com]; Jana Iyengar [jri@google.com= ] CC: QUIC WG [quic@ietf.org]; Charles 'Buck' Krasic [ckrasic@google.com] Subject: RE: Deadlocking in the transport No disagreement. When choosing which stream *with pending data* to make pr= ogress on, I think choosing the higher-priority stream is necessary rather = than advisory. With H2, we're talking about client preferences about serve= r responses which might not be ready yet, so it's always advisory to the se= rver. Here, we're talking about the application's preferences about its ow= n data that it has already handed off. That's something that happened with= in the HTTP/2 implementation, so there was no agreement or contract needed. So long as the dependency is strictly on a higher-priority stream and the t= ransport layer is handling priorities strictly when choosing what to send i= n a flow-control-limited situation, I think we avoid the deadlock. That is= , when X depends on Y, if new flow control credit is guaranteed to cause Y = to make forward progress (and the other side is continuing to read from Y's= stream), the other side would eventually be able to process X. This isn't a protocol element, but an implementation element that's necessa= ry for the protocol to be fully functional. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Wednesday, January 10, 2018 2:42 PM To: Jana Iyengar Cc: QUIC WG ; Charles 'Buck' Krasic Subject: Re: Deadlocking in the transport On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar wrote: > Yes, I think there's easy misinterpretation here -- something I > realized today as I've had conversations about this. What I meant was > specifically at the API between the app and the transport, at the > sender. This is basically saying that to avoid deadlock due to > dependencies across streams, the transport write API must allow the app t= o express strict priorities. Ahh, excellent, then I think at least we two are in agreement. It seems li= ke there is an emerging acceptance of the problem and proposed approach, I = guess we might start considering how to address it. I think that this needs to be in the main spec. Failing to document this s= ort of pitfall could be fatal. Does anyone disagree? --_000_d8fc96a972bb43c5b6e13fc60c8bc9adusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mandating a strict priority order on the sender may cause = an increase in HOL blocking, if the contents of a higher-priority stream ar= e not needed by all lower-priority streams. That happens when a higher-priority stream has MAX_STREAM_DATA th= at allows the sender to keep transmitting on that stream exclusively for 1-= 2 rtt, but one of the early packets is lost. The entire connection is block= ed till that one loss is repaired.

The value of MAX_STREAM_DATA cannot be reduced below 1-2 rtt-worth of data,= in case the higher-priority stream is the only stream with data.

A transport wishing to minimize HOL blocking may decide to allocate bandwid= th in an other than strict priority order. Or the transport API would need = to be very versatile to convey strict stream dependency graphs as well as s= tream priorities.

-----Original Message-----
From: Mike Bishop [mbishop@evequefou.be]
Received: Wednesday, 10 Jan 2018, 5:55PM
To: Martin Thomson [martin.thomson@gmail.com]; Jana Iyengar [jri@goo= gle.com]
CC: QUIC WG [quic@ietf.org]; Charles 'Buck' Krasic [ckrasic@google.c= om]
Subject: RE: Deadlocking in the transport

No disagreement.  When choosing which stream = *with pending data* to make progress on, I think choosing the higher-priori= ty stream is necessary rather than advisory.  With H2, we're talking a= bout client preferences about server responses which might not be ready yet, so it's always advisory to the server. = Here, we're talking about the application's preferences about its own data= that it has already handed off.  That's something that happened withi= n the HTTP/2 implementation, so there was no agreement or contract needed.

So long as the dependency is strictly on a higher-priority stream and the t= ransport layer is handling priorities strictly when choosing what to send i= n a flow-control-limited situation, I think we avoid the deadlock.  Th= at is, when X depends on Y, if new flow control credit is guaranteed to cause Y to make forward progress (and the = other side is continuing to read from Y's stream), the other side would eve= ntually be able to process X.

This isn't a protocol element, but an implementation element that's necessa= ry for the protocol to be fully functional.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Martin Thomson
Sent: Wednesday, January 10, 2018 2:42 PM
To: Jana Iyengar <jri@google.com>
Cc: QUIC WG <quic@ietf.org>; Charles 'Buck' Krasic <ckrasic@google= .com>
Subject: Re: Deadlocking in the transport

On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar <jri@google.com> wrote:=
> Yes, I think there's easy misinterpretation here -- something I
> realized today as I've had conversations about this. What I meant was =
> specifically at the API between the app and the transport, at the
> sender. This is basically saying that to avoid deadlock due to
> dependencies across streams, the transport write API must allow the ap= p to express strict priorities.

Ahh, excellent, then I think at least we two are in agreement.  It see= ms like there is an emerging acceptance of the problem and proposed approac= h, I guess we might start considering how to address it.

I think that this needs to be in the main spec.  Failing to document t= his sort of pitfall could be fatal.  Does anyone disagree?

 --_000_d8fc96a972bb43c5b6e13fc60c8bc9adusma1exdag1mb5msgcorpak_-- From nobody Wed Jan 10 21:53:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702D12E8A8 for ; Wed, 10 Jan 2018 21:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEVW9AV15pVp for ; Wed, 10 Jan 2018 21:52:57 -0800 (PST) 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 D2403126C83 for ; Wed, 10 Jan 2018 21:52:56 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id g10so521715qtj.12 for ; Wed, 10 Jan 2018 21:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UcLCC4/VqyI2TlRRkC4yWQPRWYUV3SAT4P/pM8Y/KC8=; b=TXPjueZyKZ5QwhkLOAts57gTVGqN5mXvZwCjAqxb5ZV75zcDXq6f61K2X/qQpT0z3D 6f7+iDyiBPP77XUVuBzk6S0Qyr1c/AxPpTwDZo2XUsmE3Rtt37eos8H0p4bN7q+iKvhh /NqGim1uCtOvW6BpsJnAQwML+nyPWljdcw61d5RTh9bCWWtkGKZHIhS4i4aYbMPru7xH jDhOhvRg5aosbXczcJOYNR1bj0K2iGPNzbjOmqkscWgQ0oXGlY+zlknWTgjZ3QzUPzLl Muerg0trrU92qMpmvHIpNKPEsfdamoKPlvmDz2CpDLnmiBf6h9nE2lWelqRB2I7jz+Lu NtRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=UcLCC4/VqyI2TlRRkC4yWQPRWYUV3SAT4P/pM8Y/KC8=; b=dk0U60yrAifU54b7rNEbmBlCrwOMA3KTPDjxVqZ+o/LLLt0K8mJAFJ110hEgL97h+X RJn6UbB2HenkYKrKNEkh/lV7FUaPcbCW7kLXI/rTsam85X1M3thp0edWMHkuvsNw29lL ugi2OYVja36qkfigVWOCx420RTOIXEo+MddhEtp7Rcfai7f9in2LeV/jR4PPCYz/pwu8 uwS/GBR2gg3RugPbHW+yim3Pnps9uKGma0aULTyCSz8eOx8M22ejgjTPI25R5l2jemYc uUMwaj1dtOE1Kpl4jyMUtWn1Y/NbHRiJ2QgvMSrQJXA303MRZYIOrFh9MWdrMVlkpdZW Mv0g== X-Gm-Message-State: AKwxytfc5LwbnLxfa4hghvRAzU3m4ALt6gtCzQtRSjEFnNszOvo7Jq9c cGe/WZfKPaONDik4x8fvWu/dMw== X-Google-Smtp-Source: ACJfBovE7fHBiSELAt9JZte5BNHd1aj55yde9HMEsaxodwH15pDgty7P/VaiZQYiP//SEGhg+tQdJA== X-Received: by 10.200.25.228 with SMTP id s33mr5290638qtk.57.1515649975928; Wed, 10 Jan 2018 21:52:55 -0800 (PST) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id k3sm11328393qtj.40.2018.01.10.21.52.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jan 2018 21:52:55 -0800 (PST) Date: Thu, 11 Jan 2018 00:52:53 -0500 From: Dmitri Tikhonov To: Mike Bishop Cc: Martin Thomson , Jana Iyengar , QUIC WG , Charles 'Buck' Krasic Subject: Re: Deadlocking in the transport Message-ID: <20180111055253.GC21534@ubuntu-dmitri> Mail-Followup-To: Mike Bishop , Martin Thomson , Jana Iyengar , QUIC WG , Charles 'Buck' Krasic References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 05:52:59 -0000 On Wed, Jan 10, 2018 at 10:55:46PM +0000, Mike Bishop wrote: > No disagreement. When choosing which stream *with pending data* to make > progress on, I think choosing the higher-priority stream is necessary > rather than advisory. With H2, we're talking about client preferences > about server responses which might not be ready yet, so it's always > advisory to the server. Here, we're talking about the application's > preferences about its own data that it has already handed off. > That's something that happened within the HTTP/2 implementation, ^^^^^^^^^^^^^^^^^^^^^^^ > so there was no agreement or contract needed. What is that something that happened? and to which HTTP/2 implementation? - Dmitri. From nobody Thu Jan 11 09:55:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1866612EC15 for ; Thu, 11 Jan 2018 09:55:09 -0800 (PST) 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 JJu4pWmGinwJ for ; Thu, 11 Jan 2018 09:55:07 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 6CDDC12EC28 for ; Thu, 11 Jan 2018 09:55:07 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id 37so2802354otv.6 for ; Thu, 11 Jan 2018 09:55:07 -0800 (PST) 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=AzLzeEtFtQtaMkZD2bt12AzgMoiw/Gz5GsVLYo9wJs8=; b=h9OYArFl+mQgJiRMj51FvBfTVKle7gJv/zRfADvt9VToVXwMcnYtgzY7dCNEgVGs7l wI/A5DcLEbgok+EbfT9idAIGUHKoU3JyQ0BWBaRAZL0jiHbIJc8FpszeHj/XvgT8LVn/ h0dbGLETgcqS789xw1ZVwKrzDBQNd+j6+Md5AeeP1o3GE7wY4ZVmMACrlRR4hsQ26Yjt IF29EUEo64ZwVqdoDpHPSGdJdzvUGO8T7HUtI3fDc7TwE1yvsVpELWPAvA0GDgrxjkzW IlRjhYZ+8y8tyXgXgKL/2LILvKkEOM9eiFrcoZpsrAMmhnvhWJpVYaBFQO9ysNOZZgu+ NfcA== 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=AzLzeEtFtQtaMkZD2bt12AzgMoiw/Gz5GsVLYo9wJs8=; b=eMs0OdQE9/BrdFcShHjPJJInUHrYYy1i2Td2HgrpaqWwbK/nP2vorIkeqHQ1CftcyL +uljIa8pSiCb3D058wJsMPGV4BX3JJQkNDqVJw5eq9ZxWE6+89Fqb285WuGcy07apZ0u b+gncQkeVgEcrJLI81jNCtC7jY5coEwUGQLIPH2PvDZzZ7aOuxpupUmFCkMpuqKiq9E1 1EHB18HOdT0sy0L1cw6QWepVz98jgHO/eKHDZ/Kp8dOmv0aLoktjzD7Bve8pIG/tfZBw 17ery9jSI9hAC3jrIcPTUKHDw8pP1iPj0RSNRI0Yww+LFzddTl218VgUuLDVa7rLePLT QJdA== X-Gm-Message-State: AKwxytf7fiHQlO3O84LwBU1IS/tTV22YfdyTS6h/KjV2ZLuF6YV3kmpJ ic6AF1wnhxl9E8NMDXSWRhXH1u0GhWw9Emd/Wbs= X-Google-Smtp-Source: ACJfBosI1vhc7qnQ6LCv8G9k90F7kzt1bs15YroOdWcsZzCUjyf6MboBfEWsOaVnJiimXEI4Wtm0xwEBkDcINKbft6E= X-Received: by 10.157.52.241 with SMTP id t46mr13892260otd.103.1515693306729; Thu, 11 Jan 2018 09:55:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Thu, 11 Jan 2018 09:55:03 -0800 (PST) In-Reply-To: <20180111055253.GC21534@ubuntu-dmitri> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <20180111055253.GC21534@ubuntu-dmitri> From: Martin Thomson Date: Fri, 12 Jan 2018 04:55:03 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Mike Bishop , Martin Thomson , Jana Iyengar , QUIC WG , "Charles 'Buck' Krasic" 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, 11 Jan 2018 17:55:09 -0000 Mike's point is that we didn't address this particular problem in h2. We left it up to implementations to manage. It's possible that we had this problem of dependencies between streams, but only at the highest layers (that is, above HTTP) where the problem already has well-established patterns for managing it. Those being firmly along the lines of "don't do that". On Thu, Jan 11, 2018 at 4:52 PM, Dmitri Tikhonov wrote: > On Wed, Jan 10, 2018 at 10:55:46PM +0000, Mike Bishop wrote: >> No disagreement. When choosing which stream *with pending data* to make >> progress on, I think choosing the higher-priority stream is necessary >> rather than advisory. With H2, we're talking about client preferences >> about server responses which might not be ready yet, so it's always >> advisory to the server. Here, we're talking about the application's >> preferences about its own data that it has already handed off. >> That's something that happened within the HTTP/2 implementation, > ^^^^^^^^^^^^^^^^^^^^^^^ >> so there was no agreement or contract needed. > > What is that something that happened? and to which HTTP/2 implementation? > > - Dmitri. From nobody Thu Jan 11 15:16:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCDC129C6A for ; Thu, 11 Jan 2018 15:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 gtrUOXJLgAmg for ; Thu, 11 Jan 2018 15:16:12 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A075D129C51 for ; Thu, 11 Jan 2018 15:16:12 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id c14so3973119qkh.4 for ; Thu, 11 Jan 2018 15:16:12 -0800 (PST) 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=tB4Yv18KlAatFQ4f6kxJFg+rYvjkrh6s775rIdWHVWA=; b=KhSVOmJTTjR1lOg1z6ovF0CM+yyH75IeqzYSzTt+b7+RTvXi+vBZQFrIpznVfby89j goWA8DNCAgCfHtaUtHfSI+fPKAh9qSCFgAm5L621gqL7PkWc6X38v1iG2qYSHeYthGv6 xJuSHCDI3YGGJnjvE0drfQ2/8/Wyd8J5WPu46deXM/uqYWNliGjj5KkolRL7A8R1JQWe /EloyTrmU6V8jCDxnG9KpQiY/r6AgBYw8Etmi7e8/6QRAVy/zwQOiI1uqqSZjxfUvDFs JPrm+OyLjmK3i2nvtzD0vgguPjf2JLbyuod1VEOOGr2MEodCCylq6bOi3H/+Fyvl783n 03+Q== 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=tB4Yv18KlAatFQ4f6kxJFg+rYvjkrh6s775rIdWHVWA=; b=FXe1EAk2txj8Px7fOQyFlw/dHXCUC8mvcsrHp0ViR+BZvEUnKeqO+UuOvN4KIC1hjn WPuTpwl5XiYTUNUrl/BsvRqfH4665yAeuidDdn4bj2rqS327W9SgeXVk4TTUFwa3a1nk DtgWjJbws2qWgDB0KgIAjolDaVq5MxQX5IKEqcDaqN5YLj+yPZRF4BjlJtwT3iyfWQwP m+U4jao35D+4mrVKbsc7TEcq9PEBvhxaps5rOjIHwlhFsPn7NRKHfPq5ig//KX4xV0kY xFeZAA4nl1D/aMl1a2cNxyDmQBKh7Y6uybVmsy8DPy6JQ0YyKjFBwa2YhHruXDqGrDOa 70gA== X-Gm-Message-State: AKwxytdoKDHT9q18p2+lKwc4U5gnkg7u3G0E020K1ajphmZPlFue5bkN t6wq4lWQqftEMgRiZwBspVFtMnXNWKKuHLjQIAUL/y2U9w0= X-Google-Smtp-Source: ACJfBouuLZbtHMfs46//9ASm0aAXFny1+W5L0XwC6J+SGo265OZAxaWHr8kXmUx7mdffkbp3I+1BtA0ITA444i06UwA= X-Received: by 10.55.25.146 with SMTP id 18mr32446229qkz.214.1515712571179; Thu, 11 Jan 2018 15:16:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.156.209 with HTTP; Thu, 11 Jan 2018 15:16:10 -0800 (PST) From: Victor Vasiliev Date: Thu, 11 Jan 2018 18:16:10 -0500 Message-ID: Subject: Increasing QUIC connection ID size To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1147b2c063b7ac05628855bc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 23:16:15 -0000 --001a1147b2c063b7ac05628855bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --001a1147b2c063b7ac05628855bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

In the current = version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob= , and that is set as an invariant in the protocol.

I=E2=80=99ve looked into possibility of using a connection ID to encode th= e specific server details into it (to provide stability of the connection i= n case of load balancing changes, especially BGP flaps for anycast IPs), an= d have chatted about this with other people I knew were interested in this.= =C2=A0 It seems like 64 bits might be too small for this purpose, and we mi= ght want to leave an opportunity to extend the connection ID size.

The basic idea is that you want to be able to:
<= ol>
  • Store some routing metadata in the connection ID.
  • Have s= ome entropy that allows distinguish users with identical routing metadata.<= br>
  • Have a checksum to ensure the validity of routing information
  • Encrypt the information above to prevent disclosing the route in= formation and allow generating uncorrelatable connection IDs.
    • =
    There are two underlying issues here.=C2=A0 The first problem is= that all of this does not fit well into 64 bits, and you have to seriously= compromise on the strength of the checksum (which is bad especially if you= want it to be a MAC rather than a checksum).=C2=A0 The second problem is t= hat encrypting 64-bit values fast is actually fairly hard since the block c= iphers easily available in hardware have 128-bit block size, and the perfor= mance requirements on load balancers are tighter than on servers.=C2=A0=C2= =A0

    In other words, having a 128-bit connection ID= provides for an easy secure way to generate unlinkable connection IDs on m= igration.

    So, the problem we=E2=80=99re trying to = solve is that the connection ID is too small.=C2=A0 There are two questions= I believe the working group should answer at this point:
      Do we want to address this problem at this point in standardization proces= s?
    1. If we don=E2=80=99t address this problem right now, how do w= e structure the standard in a way that we can extend the connection ID in t= he future?
    There are multiple ways to solve the pro= blem of making connection ID larger.=C2=A0 One is to just add extra bit to = the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connection = IDs.=C2=A0 Another approach is to allow connection ID size to be explicitly= specified by the server, and then assume that the load balancer knows that= size and no one else on the path needs to read it.

    There=E2=80=99s also a question of how much of connection IDs do middlebo= xes (excluding load balancers and other boxes owned by the same entity as e= ither client or server) need to know.=C2=A0 We could go for both =E2=80=9Cm= iddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80= =9Cmiddleboxes should not read connection IDs at all options=E2=80=9D, but = I think there=E2=80=99s also a room for more flexible formulations like =E2= =80=9Cmiddleboxes always get first 64 bits and they have useful entropy to = distinguish connections=E2=80=9D.

    =C2=A0 -- Victor= .
    --001a1147b2c063b7ac05628855bc-- From nobody Thu Jan 11 15:51:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4181275C5 for ; Thu, 11 Jan 2018 15:51:44 -0800 (PST) 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 8whOfp27WORJ for ; Thu, 11 Jan 2018 15:51:41 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10A661205F0 for ; Thu, 11 Jan 2018 15:51:41 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id b77so7061278itd.0 for ; Thu, 11 Jan 2018 15:51:41 -0800 (PST) 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=h+lpMGjQTv/qQ9I7Vpkv8L50ZdOV2cR/jzYtxjCrBrA=; b=Y2z2TrCo2V2FPTu0dMvnauUAkYkWVAKS6tzxCxUq3IJaJCQf4TS9ITeP/7tUnPrDuz iJVwjlSk/mKsL8W9/dMdyi38xy5dndM57z9ppWarA6PFg0ADYui/vVVMSoRrsrpaJoWn 2N0LxzBWOrTeweZGzbU9QzyhB2zIJhlB6gcm9rvN3o7BwBHo7WTe+hT5UkWgF0nqAu4b adCXJo+M7A/yXm8fUfekqKHvN5kONhaz8TDiZ5QIrQAx1q/DHuisJVB+9BJb1i/kmARO jxhlQldqnoFzXnTxbNdDIMhuq3HdXSjtadnb6YttbTwxjjm+/h5F2nnkDERvkk1ZepXd WZWg== 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=h+lpMGjQTv/qQ9I7Vpkv8L50ZdOV2cR/jzYtxjCrBrA=; b=ZUw0jI6Z2brruuPU+jilrNdV8YNT/N7YUIDWov2hZD8MGSZjPPg6CYVY+ouVN5Uvj2 pgbXCWqvyXYOBNkB73N8uNDjmzORtwE4tmRvik2XF0+W4hXJhrr8urvm/I6GVe8imLPU So76g+nTeyzoMkXEcUuipyi0vuPL3vnrFleBeTB/tGDv4V+1tNj2Yub7WCgGl7AFvarT ppw1mTPh2nGaL1l8YSY4RKHv0Frx6y2o1PoFnpVfQokccsY2QA/AR0sSq0ic6sEv293a e0GRmSkNwL4c08iTyCE/MRJv5eWqzXPEztHXYcuOU3x0zvBWhsgmX4hBnpqPOQ33qd1k IINQ== X-Gm-Message-State: AKwxytcszgyYccLwHHVaOGmiVDxPwUVMfcTJnKLATaEcuwDZxKnSeUzh d9RKg4lJCnLR4jsXRwZGNkWD8pBgTH0R3VbU4rkeGQ== X-Google-Smtp-Source: ACJfBotMpmYezRS+Ta1w7tG0rGHnCNW33FKR7sVTfZhczK4AEBIQSZLTiYUk0py838ljRYHdovFSbekNQf0w5lEhTy0= X-Received: by 10.36.188.198 with SMTP id n189mr2968153ite.91.1515714700224; Thu, 11 Jan 2018 15:51:40 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 15:51:39 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 15:51:39 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c11416049aff5056288d49f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 23:51:44 -0000 --94eb2c11416049aff5056288d49f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can also see a need for larger connection ID=E2=80=99s for routing purpos= es in overlay networks, but I decided it was probably better to prefix the QUIC header in that case. It is worth noting that if you have a non-unique tuple of port-address pairs, you need the connection ID in every packet, and that can be a lot of overhead. So a large ID would likely isolate that version to a dedicated purpose, and then you might as well add a packet prefix. An alternative solution is to use the connection ID as an index into a routing table that has the real details, but this requires that early packets of the connection carry those details in a way that routers can pick up which probably isn=E2=80=99t practical. A more practical solution is to keep the connection ID as is to serve its primary purpose. A given protocol version could negotiate an extension the the clear text header. Even if those data are not directly following the connection ID, they can easily be picked up by router. This is essentially the same as a packet prefix, except that the QUIC invariants are now maintained. As to encryption: block encryption generally works by xor=E2=80=99ing a =E2= =80=9Crandom=E2=80=9D value to the clear text. AES produces such a value from a counter or similar unique value per block but does not need the clear text data at all. The output of AES is simply XOR=E2=80=99ed with the clear text data (t= his can be different when encrypting multiple blocks). This means that if the block size is 128 bit you can easily encrypt 64 bytes by XOR=E2=80=99ing with the= first 64-bits of the AES output. But you likely want to zero extend instead due to auth tag: It is not safe to use block encryption alone. It must nearly always be associated with an authentication tag as with AES-GCM. Otherwise an attacker will quickly learn that, say, bit 53 and bit 32 affects routing and can trivially cause at least 1/4 packets to land somewhere else just be flipping either bit. A compact auth tag does not have to be very long for such a short message but it adds to the overall size requirement and complexity of the solution.It could be generated with CMAC that are two AES encryption rounds. (CMAC on connection ID could, BTW, also be used to very quickly reject invalid QUIC packets, which I have proposed earlier). The CMAC output will be one AES block, but it can be truncated depending on the security level required. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.16.21, Victor Vasiliev (vasilvv@google.com) wrote: Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --94eb2c11416049aff5056288d49f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I can also see a nee= d for larger connection ID=E2=80=99s for routing purposes in overlay networ= ks, but I decided it was probably better to prefix the QUIC header in that = case.

    It is worth not= ing that if you have a non-unique tuple of port-address pairs, you need the= connection ID in every packet, and that can be a lot of overhead. So a lar= ge ID would likely isolate that version to a dedicated purpose, and then yo= u might as well add a packet prefix.
    <= br>
    An alternative s= olution is to use the connection ID as an index into a routing table that h= as the real details, but this requires that early packets of the connection= carry those details in a way that routers can pick up which probably isn= =E2=80=99t practical.

    A more practi= cal solution is to keep the connection ID as is to serve its primary purpos= e. A given protocol version could negotiate an extension the the clear text= header. Even if those data are not directly following the connection ID, t= hey can easily be picked up by router. This is essentially the same as a pa= cket prefix, except that the QUIC invariants are now maintained.

    As to encryption: block encryption ge= nerally works by xor=E2=80=99ing a =E2=80=9Crandom=E2=80=9D value to the cl= ear text. AES produces such a value from a counter or similar unique value = per block but does not need the clear text data at all. The output of AES i= s simply XOR=E2=80=99ed with the clear text data (this can be different whe= n encrypting multiple blocks). This means that if the block size is 128 bit= you can easily encrypt 64 bytes by XOR=E2=80=99ing with the first 64-bits = of the AES output. But you likely want to zero extend instead due to auth t= ag:

    It is not safe to= use block encryption alone. It must nearly always be associated with an au= thentication tag as with AES-GCM. Otherwise an attacker will quickly learn = that, say, bit 53 and bit 32 affects routing and can trivially cause at lea= st 1/4 packets to land somewhere else just be flipping either bit. A compac= t auth tag does not have to be very long for such a short message but it ad= ds to the overall size requirement and complexity of the solution.It could = be generated with CMAC that are two AES encryption rounds. (CMAC on connect= ion ID could, BTW, also be used to very quickly reject invalid QUIC packets= , which I have proposed earlier). The CMAC output will be one AES block, bu= t it can be truncated depending on the security level required.


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


    On 12 January 2018 at 00.16.21, Victor Vasiliev (vasilvv@google.com) wrote:

    Hi everyone,

    In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

    I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size.

    The basic idea is that you want to be able to:
    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing metadata.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs.
    There are two underlying issues here.=C2=A0 The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers.=C2=A0=C2=A0

    In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration.

    So, the problem we=E2=80=99re trying to solve is that the connection ID is too small.=C2=A0 There are two questions I believe the working group should answer at this point:
    1. Do we want to address this problem at this point in standardization process?
    2. If we don=E2=80=99t address this problem right now, how do we structure the standard in a way that we can extend the connection ID in the future?
    There are multiple ways to solve the problem of making connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs.= =C2=A0 Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it.

    There=E2=80=99s also a question of how much of connection IDs do middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.=C2=A0 We could go for both =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read connection IDs = at all options=E2=80=9D, but I think there=E2=80=99s also a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits and they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0 -- Victor.
    --94eb2c11416049aff5056288d49f-- From nobody Thu Jan 11 15:54:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E8E11205F0 for ; Thu, 11 Jan 2018 15:54:25 -0800 (PST) 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 OfCcvdBhe_VG for ; Thu, 11 Jan 2018 15:54:22 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5EC61275C5 for ; Thu, 11 Jan 2018 15:54:21 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id d11so3928498iog.5 for ; Thu, 11 Jan 2018 15:54:21 -0800 (PST) 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=jTaROEe+NJ3UJdRmv8OKXMhyJUQuwJgLq276piXqWNc=; b=Xv6X9MFfr+1WidvxqF1EqHxSWUriX1QBkSNS9DGdhMjjxuA6jHFP5VKSDiHzsO2QcU pBIgyF9ffZgw+KrK9w23KtLsQpeoUytROhFLtTHYQcRi39+k6Tk9gJYvcBQcuSnyG1Uf obAu1wNOd4Jrf9BR4F1OoBpqtiz06Zs+B2/MrWofB7xe4xLfPqiKAUgkS6UIotsu+ZUx NeLaec5Qdsb90Ep/ik6cRpoaHkddDS5BZeu+SouFuWtazbXuhKhbBVf8EczJOgc2gFTK 9aYF6R/T50DKGwQ/7d6UyTNdMxE0NOhi/jqELaPKiPXsgoC5E5Dtf31LWBA7u4V+X8kc 2pzg== 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=jTaROEe+NJ3UJdRmv8OKXMhyJUQuwJgLq276piXqWNc=; b=VYizN/ZQJG+4/VMV3UG/Oo5MJbE6Bv7WjBovTdW/FS8Ds2xysUViPLMi4RdJd9OapA jqVghsvC4DrPkNe8+14C1u/iBcARWFaSiB2WKfaIfm54oLwdGtRAJJyYgOPgf6yo+xCy P0MYPylGOfnVa7iRYRIl2LVwvk4C18FZMXE/U/5mDblyQw2H1R706lxbZXNOC615oEPS HvHeuFE8iKgiEeD4C3fcaY97EWwcMsIheVDbefcSNhXNHviy2iGccco8BmtZwbsGHzNU OYmeqaJlCPikiSPj1WorrlD3MiTEAoXquQZm484KpPeydFA9vIf/ybO4Es2Ukq/b9aoi dboQ== X-Gm-Message-State: AKGB3mIxVA6G8LoMC09KMxQdzLwV8BGe0WzmvpF635wo7AlhnZwl8r3d ISQImxW3/DKf1C/4pIvtvqHoNdBG6G5XNGzTdIXJd+82 X-Google-Smtp-Source: ACJfBouRpMwgMACBxHVhtiUpGV4YgMeHj7oSxUcKORP9a3DzqThYPjheNbOjLE5uM9qq04DufEobkk/KfcVtscikbCQ= X-Received: by 10.107.5.142 with SMTP id 136mr24000220iof.239.1515714861261; Thu, 11 Jan 2018 15:54:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 15:54:20 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 15:54:20 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113edec0e2e912056288dda7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 23:54:25 -0000 --001a113edec0e2e912056288dda7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable EDIT: I didn=E2=80=99t propose CMAC on connection ID - it needs to change, = so it would be on the packet number for the sake of fast rejection of invalid packets. The counter argument was that it is fast enough to check the auth tag of the entire message. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.51.39, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: I can also see a need for larger connection ID=E2=80=99s for routing purpos= es in overlay networks, but I decided it was probably better to prefix the QUIC header in that case. It is worth noting that if you have a non-unique tuple of port-address pairs, you need the connection ID in every packet, and that can be a lot of overhead. So a large ID would likely isolate that version to a dedicated purpose, and then you might as well add a packet prefix. An alternative solution is to use the connection ID as an index into a routing table that has the real details, but this requires that early packets of the connection carry those details in a way that routers can pick up which probably isn=E2=80=99t practical. A more practical solution is to keep the connection ID as is to serve its primary purpose. A given protocol version could negotiate an extension the the clear text header. Even if those data are not directly following the connection ID, they can easily be picked up by router. This is essentially the same as a packet prefix, except that the QUIC invariants are now maintained. As to encryption: block encryption generally works by xor=E2=80=99ing a =E2= =80=9Crandom=E2=80=9D value to the clear text. AES produces such a value from a counter or similar unique value per block but does not need the clear text data at all. The output of AES is simply XOR=E2=80=99ed with the clear text data (t= his can be different when encrypting multiple blocks). This means that if the block size is 128 bit you can easily encrypt 64 bytes by XOR=E2=80=99ing with the= first 64-bits of the AES output. But you likely want to zero extend instead due to auth tag: It is not safe to use block encryption alone. It must nearly always be associated with an authentication tag as with AES-GCM. Otherwise an attacker will quickly learn that, say, bit 53 and bit 32 affects routing and can trivially cause at least 1/4 packets to land somewhere else just be flipping either bit. A compact auth tag does not have to be very long for such a short message but it adds to the overall size requirement and complexity of the solution.It could be generated with CMAC that are two AES encryption rounds. (CMAC on connection ID could, BTW, also be used to very quickly reject invalid QUIC packets, which I have proposed earlier). The CMAC output will be one AES block, but it can be truncated depending on the security level required. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.16.21, Victor Vasiliev (vasilvv@google.com) wrote: Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --001a113edec0e2e912056288dda7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = EDIT: I didn=E2=80= =99t propose CMAC on connection ID - it needs to change, so it would be on = the packet number for the sake of fast rejection of invalid packets. The co= unter argument was that it is fast enough to check the auth tag of the enti= re message.

    Kind = Regards,
    Mik= kel Fahn=C3=B8e J=C3=B8rgensen


    On 12 January 2018 at 00.51.39, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    I can also see a need for larger connection ID=E2=80=99s for routing purposes in overlay networks, but I decided it was probably better to prefix the QUIC header in that case.

    It is worth noting that if you have a non-unique tuple of port-address pairs, you need the connection ID in every packet, and that can be a lot of overhead. So a large ID would likely isolate that version to a dedicated purpose, and then you might as well add a packet prefix.

    An alternative solution is to use the connection ID as an index into a routing table that has the real details, but this requires that early packets of the connection carry those details in a way that routers can pick up which probably isn=E2=80=99t practical.

    A more practical solution is to keep the connection ID as is to serve its primary purpose. A given protocol version could negotiate an extension the the clear text header. Even if those data are not directly following the connection ID, they can easily be picked up by router. This is essentially the same as a packet prefix, except that the QUIC invariants are now maintained.

    As to encryption: block encryption generally works by xor=E2=80=99ing a =E2=80=9Crandom=E2=80=9D value to the clear text. AES produces such a value= from a counter or similar unique value per block but does not need the clear text data at all. The output of AES is simply XOR=E2=80=99ed with the clear text data (this can be different when encrypting multiple blocks). This means that if the block size is 128 bit you can easily encrypt 64 bytes by XOR=E2=80=99ing with the first 64-bits of the AES output. But you likely want to zero extend instead due to auth tag:

    It is not safe to use block encryption alone. It must nearly always be associated with an authentication tag as with AES-GCM. Otherwise an attacker will quickly learn that, say, bit 53 and bit 32 affects routing and can trivially cause at least 1/4 packets to land somewhere else just be flipping either bit. A compact auth tag does not have to be very long for such a short message but it adds to the overall size requirement and complexity of the solution.It could be generated with CMAC that are two AES encryption rounds. (CMAC on connection ID could, BTW, also be used to very quickly reject invalid QUIC packets, which I have proposed earlier). The CMAC output will be one AES block, but it can be truncated depending on the security level required.


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


    On 12 January 2018 at 00.16.21, Victor Vasiliev (vasilvv@google.com) wro= te:

    Hi everyone,

    In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

    I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size.

    The basic idea is that you want to be able to:
    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing metadata.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs.
    There are two underlying issues here.=C2=A0 The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers.=C2=A0=C2=A0

    In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration.

    So, the problem we=E2=80=99re trying to solve is that the connection ID is too small.=C2=A0 There are two questions I believe the working group should answer at this point:
    1. Do we want to address this problem at this point in standardization process?
    2. If we don=E2=80=99t address this problem right now, how do we structure the standard in a way that we can extend the connection ID in the future?
    There are multiple ways to solve the problem of making connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs.= =C2=A0 Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it.

    There=E2=80=99s also a question of how much of connection IDs do middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.=C2=A0 We could go for both =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read connection IDs = at all options=E2=80=9D, but I think there=E2=80=99s also a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits and they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0 -- Victor.
     --001a113edec0e2e912056288dda7-- From nobody Thu Jan 11 15:57:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954F812EC6A for ; Thu, 11 Jan 2018 15:57:00 -0800 (PST) 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 xTyFfWtmPUL8 for ; Thu, 11 Jan 2018 15:56:57 -0800 (PST) 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 B9CD512EC5C for ; Thu, 11 Jan 2018 15:56:57 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0BNqvk7014575; Thu, 11 Jan 2018 23:56:54 GMT 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=bjsHKZfqxH0pmMpyBhOCec7ZDrcQuE0Xg6qd6pe8+eI=; b=B3oSztzZ4/LAtLI4pbf1PoBokZWeOkiwuQPU+o2jQWEbLFx5KBH5zBTWmWAlbBUZNu3H 0W7RSPLSionTTFAX6LSpzrUBkDfDzOMnmUEJL7Hk8PXpsISx+Y1tB4qEu9XSprWAJjN+ nn3XSCz969RtZ7NhFHKbyrGHnxXE5+mlr5XTa9ZtAQG7oNn2+wj6T/IvpYgDQqTSe/T7 RiyLSZAfbenTTW80V4L3F979oVQDzeboRau2379Q8fB1KNiwIC8mnQ6mDDE5QllelGE5 ptl2sJGkjBH6PKjMKCG7WTfyS34KRLQSxlnZsbg4ihn4FpETS6Mnnn+1EhIRIJP+4suU Fg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2fda9rrmt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 23:56:54 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0BNtdxY012341; Thu, 11 Jan 2018 18:56:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fatpe8k3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 18:56:53 -0500 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, 11 Jan 2018 18:56:52 -0500 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, 11 Jan 2018 18:56:52 -0500 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, 11 Jan 2018 18:56:52 -0500 From: "Lubashev, Igor" To: Victor Vasiliev , IETF QUIC WG Subject: RE: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizIxs65b7ysujkqedmh6APARjaNvVjxA Date: Thu, 11 Jan 2018 23:56:52 +0000 Message-ID: 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.88] Content-Type: multipart/alternative; boundary="_000_d2a6136f93654eb1a5c7970cfb41f7adusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=809 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110321 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=760 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801110320 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Jan 2018 23:57:01 -0000 --_000_d2a6136f93654eb1a5c7970cfb41f7adusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbnRlcmVzdGVkIGluIGV4cGxvcmluZyB0aGlzIHByb3Bvc2FsLCBzaW5jZSBpdCBhbGxv d3MgZm9yIG1vcmUgZmxleGlibGUgc2NoZW1lcyBvZiBlbmNvZGluZyByb3V0aW5nIG1ldGFkYXRh IGFuZCBhIGNoZWNrc3VtLiAgSSB3b3VsZCBhbHNvIGxpa2UgdG8gYmUgZXhwbGljaXQgYWJvdXQg dGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBpbiBhIHBhY2tldCBoZWFkZXIsIHRob3VnaCwgc2luY2Ug aXQgZ3JlYXRseSBzaW1wbGlmaWVzIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KDQogICogICBJZ29y DQpGcm9tOiBWaWN0b3IgVmFzaWxpZXYgW21haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb21dDQpTZW50 OiBUaHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNDQpUbzogSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPg0KU3ViamVjdDogSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6 ZQ0KDQpIaSBldmVyeW9uZSwNCg0KSW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUg Y29ubmVjdGlvbiBJRCBzaXplIGlzIGZpeGVkIHRvIGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBh bmQgdGhhdCBpcyBzZXQgYXMgYW4gaW52YXJpYW50IGluIHRoZSBwcm90b2NvbC4NCg0KSeKAmXZl IGxvb2tlZCBpbnRvIHBvc3NpYmlsaXR5IG9mIHVzaW5nIGEgY29ubmVjdGlvbiBJRCB0byBlbmNv ZGUgdGhlIHNwZWNpZmljIHNlcnZlciBkZXRhaWxzIGludG8gaXQgKHRvIHByb3ZpZGUgc3RhYmls aXR5IG9mIHRoZSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgbG9hZCBiYWxhbmNpbmcgY2hhbmdlcywg ZXNwZWNpYWxseSBCR1AgZmxhcHMgZm9yIGFueWNhc3QgSVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBh Ym91dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkga25ldyB3ZXJlIGludGVyZXN0ZWQgaW4gdGhp cy4gIEl0IHNlZW1zIGxpa2UgNjQgYml0cyBtaWdodCBiZSB0b28gc21hbGwgZm9yIHRoaXMgcHVy cG9zZSwgYW5kIHdlIG1pZ2h0IHdhbnQgdG8gbGVhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZXh0ZW5k IHRoZSBjb25uZWN0aW9uIElEIHNpemUuDQoNClRoZSBiYXNpYyBpZGVhIGlzIHRoYXQgeW91IHdh bnQgdG8gYmUgYWJsZSB0bzoNCg0KICAxLiAgU3RvcmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGlu IHRoZSBjb25uZWN0aW9uIElELg0KICAyLiAgSGF2ZSBzb21lIGVudHJvcHkgdGhhdCBhbGxvd3Mg ZGlzdGluZ3Vpc2ggdXNlcnMgd2l0aCBpZGVudGljYWwgcm91dGluZyBtZXRhZGF0YS4NCiAgMy4g IEhhdmUgYSBjaGVja3N1bSB0byBlbnN1cmUgdGhlIHZhbGlkaXR5IG9mIHJvdXRpbmcgaW5mb3Jt YXRpb24NCiAgNC4gIEVuY3J5cHQgdGhlIGluZm9ybWF0aW9uIGFib3ZlIHRvIHByZXZlbnQgZGlz Y2xvc2luZyB0aGUgcm91dGUgaW5mb3JtYXRpb24gYW5kIGFsbG93IGdlbmVyYXRpbmcgdW5jb3Jy ZWxhdGFibGUgY29ubmVjdGlvbiBJRHMuDQpUaGVyZSBhcmUgdHdvIHVuZGVybHlpbmcgaXNzdWVz IGhlcmUuICBUaGUgZmlyc3QgcHJvYmxlbSBpcyB0aGF0IGFsbCBvZiB0aGlzIGRvZXMgbm90IGZp dCB3ZWxsIGludG8gNjQgYml0cywgYW5kIHlvdSBoYXZlIHRvIHNlcmlvdXNseSBjb21wcm9taXNl IG9uIHRoZSBzdHJlbmd0aCBvZiB0aGUgY2hlY2tzdW0gKHdoaWNoIGlzIGJhZCBlc3BlY2lhbGx5 IGlmIHlvdSB3YW50IGl0IHRvIGJlIGEgTUFDIHJhdGhlciB0aGFuIGEgY2hlY2tzdW0pLiAgVGhl IHNlY29uZCBwcm9ibGVtIGlzIHRoYXQgZW5jcnlwdGluZyA2NC1iaXQgdmFsdWVzIGZhc3QgaXMg YWN0dWFsbHkgZmFpcmx5IGhhcmQgc2luY2UgdGhlIGJsb2NrIGNpcGhlcnMgZWFzaWx5IGF2YWls YWJsZSBpbiBoYXJkd2FyZSBoYXZlIDEyOC1iaXQgYmxvY2sgc2l6ZSwgYW5kIHRoZSBwZXJmb3Jt YW5jZSByZXF1aXJlbWVudHMgb24gbG9hZCBiYWxhbmNlcnMgYXJlIHRpZ2h0ZXIgdGhhbiBvbiBz ZXJ2ZXJzLg0KDQpJbiBvdGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElE IHByb3ZpZGVzIGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5saW5rYWJsZSBj b25uZWN0aW9uIElEcyBvbiBtaWdyYXRpb24uDQoNClNvLCB0aGUgcHJvYmxlbSB3ZeKAmXJlIHRy eWluZyB0byBzb2x2ZSBpcyB0aGF0IHRoZSBjb25uZWN0aW9uIElEIGlzIHRvbyBzbWFsbC4gIFRo ZXJlIGFyZSB0d28gcXVlc3Rpb25zIEkgYmVsaWV2ZSB0aGUgd29ya2luZyBncm91cCBzaG91bGQg YW5zd2VyIGF0IHRoaXMgcG9pbnQ6DQoNCiAgMS4gIERvIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGlz IHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBzdGFuZGFyZGl6YXRpb24gcHJvY2Vzcz8NCiAgMi4g IElmIHdlIGRvbuKAmXQgYWRkcmVzcyB0aGlzIHByb2JsZW0gcmlnaHQgbm93LCBob3cgZG8gd2Ug c3RydWN0dXJlIHRoZSBzdGFuZGFyZCBpbiBhIHdheSB0aGF0IHdlIGNhbiBleHRlbmQgdGhlIGNv bm5lY3Rpb24gSUQgaW4gdGhlIGZ1dHVyZT8NClRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvIHNv bHZlIHRoZSBwcm9ibGVtIG9mIG1ha2luZyBjb25uZWN0aW9uIElEIGxhcmdlci4gIE9uZSBpcyB0 byBqdXN0IGFkZCBleHRyYSBiaXQgdG8gdGhlIOKAnG9taXQgY29ubmVjdGlvbiBJROKAnSBmaWVs ZCB0byBhbGxvdyAxMjgtYml0IGNvbm5lY3Rpb24gSURzLiAgQW5vdGhlciBhcHByb2FjaCBpcyB0 byBhbGxvdyBjb25uZWN0aW9uIElEIHNpemUgdG8gYmUgZXhwbGljaXRseSBzcGVjaWZpZWQgYnkg dGhlIHNlcnZlciwgYW5kIHRoZW4gYXNzdW1lIHRoYXQgdGhlIGxvYWQgYmFsYW5jZXIga25vd3Mg dGhhdCBzaXplIGFuZCBubyBvbmUgZWxzZSBvbiB0aGUgcGF0aCBuZWVkcyB0byByZWFkIGl0Lg0K DQpUaGVyZeKAmXMgYWxzbyBhIHF1ZXN0aW9uIG9mIGhvdyBtdWNoIG9mIGNvbm5lY3Rpb24gSURz IGRvIG1pZGRsZWJveGVzIChleGNsdWRpbmcgbG9hZCBiYWxhbmNlcnMgYW5kIG90aGVyIGJveGVz IG93bmVkIGJ5IHRoZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIgY2xpZW50IG9yIHNlcnZlcikgbmVl ZCB0byBrbm93LiAgV2UgY291bGQgZ28gZm9yIGJvdGgg4oCcbWlkZGxlYm94ZXMgc2hvdWxkIGJl IGFsd2F5cyBhYmxlIHRvIHJlYWQgdGhlIGVudGlyZSBJROKAnSBhbmQg4oCcbWlkZGxlYm94ZXMg c2hvdWxkIG5vdCByZWFkIGNvbm5lY3Rpb24gSURzIGF0IGFsbCBvcHRpb25z4oCdLCBidXQgSSB0 aGluayB0aGVyZeKAmXMgYWxzbyBhIHJvb20gZm9yIG1vcmUgZmxleGlibGUgZm9ybXVsYXRpb25z IGxpa2Ug4oCcbWlkZGxlYm94ZXMgYWx3YXlzIGdldCBmaXJzdCA2NCBiaXRzIGFuZCB0aGV5IGhh dmUgdXNlZnVsIGVudHJvcHkgdG8gZGlzdGluZ3Vpc2ggY29ubmVjdGlvbnPigJ0uDQoNCiAgLS0g VmljdG9yLg0K --_000_d2a6136f93654eb1a5c7970cfb41f7adusma1exdag1mb5msgcorpak_ 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 b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozOTcyOTIyNTA7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjQxMDUyMDI2ODt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1MDg2NDU2 NDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xODgy MDY2NDQgLTMwNDk5NzQzNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE0MTg0ODEw OTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMDk0OTY5NTI7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIGludGVyZXN0ZWQgaW4g ZXhwbG9yaW5nIHRoaXMgcHJvcG9zYWwsIHNpbmNlIGl0IGFsbG93cyBmb3IgbW9yZSBmbGV4aWJs ZSBzY2hlbWVzIG9mIGVuY29kaW5nIHJvdXRpbmcgbWV0YWRhdGEgYW5kIGEgY2hlY2tzdW0uJm5i c3A7IEkgd291bGQgYWxzbyBsaWtlIHRvIGJlIGV4cGxpY2l0IGFib3V0IHRoZSBjb25uZWN0aW9u IElEIHNpemUgaW4gYSBwYWNrZXQgaGVhZGVyLCB0aG91Z2gsIHNpbmNlIGl0IGdyZWF0bHkNCiBz aW1wbGlmaWVzIHRoZSBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPklnb3I8bzpwPjwvbzpwPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFZpY3RvciBWYXNpbGlldiBbbWFpbHRvOnZhc2lsdnZAZ29v Z2xlLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDExLCAyMDE4IDY6 MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZTxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGV2ZXJ5b25lLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY3Vy cmVudCB2ZXJzaW9uIG9mIFFVSUMsIHRoZSBjb25uZWN0aW9uIElEIHNpemUgaXMgZml4ZWQgdG8g YmUgYSA2NC1iaXQgb3BhcXVlIGJsb2IsIGFuZCB0aGF0IGlzIHNldCBhcyBhbiBpbnZhcmlhbnQg aW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5J4oCZdmUgbG9va2VkIGludG8gcG9zc2liaWxpdHkgb2YgdXNpbmcgYSBj b25uZWN0aW9uIElEIHRvIGVuY29kZSB0aGUgc3BlY2lmaWMgc2VydmVyIGRldGFpbHMgaW50byBp dCAodG8gcHJvdmlkZSBzdGFiaWxpdHkgb2YgdGhlIGNvbm5lY3Rpb24gaW4gY2FzZSBvZiBsb2Fk IGJhbGFuY2luZyBjaGFuZ2VzLCBlc3BlY2lhbGx5IEJHUCBmbGFwcyBmb3IgYW55Y2FzdCBJUHMp LCBhbmQgaGF2ZSBjaGF0dGVkIGFib3V0DQogdGhpcyB3aXRoIG90aGVyIHBlb3BsZSBJIGtuZXcg d2VyZSBpbnRlcmVzdGVkIGluIHRoaXMuJm5ic3A7IEl0IHNlZW1zIGxpa2UgNjQgYml0cyBtaWdo dCBiZSB0b28gc21hbGwgZm9yIHRoaXMgcHVycG9zZSwgYW5kIHdlIG1pZ2h0IHdhbnQgdG8gbGVh dmUgYW4gb3Bwb3J0dW5pdHkgdG8gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIHNpemUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBiYXNp YyBpZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0bzo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpTdG9yZSBzb21l IHJvdXRpbmcgbWV0YWRhdGEgaW4gdGhlIGNvbm5lY3Rpb24gSUQuPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCkhhdmUgc29tZSBlbnRyb3B5IHRoYXQgYWxsb3dzIGRpc3Rpbmd1aXNoIHVzZXJzIHdp dGggaWRlbnRpY2FsIHJvdXRpbmcgbWV0YWRhdGEuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCkhh dmUgYSBjaGVja3N1bSB0byBlbnN1cmUgdGhlIHZhbGlkaXR5IG9mIHJvdXRpbmcgaW5mb3JtYXRp b248bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KRW5jcnlwdCB0aGUgaW5mb3JtYXRpb24gYWJvdmUg dG8gcHJldmVudCBkaXNjbG9zaW5nIHRoZSByb3V0ZSBpbmZvcm1hdGlvbiBhbmQgYWxsb3cgZ2Vu ZXJhdGluZyB1bmNvcnJlbGF0YWJsZSBjb25uZWN0aW9uIElEcy48bzpwPjwvbzpwPjwvbGk+PC9v bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB0d28gdW5k ZXJseWluZyBpc3N1ZXMgaGVyZS4mbmJzcDsgVGhlIGZpcnN0IHByb2JsZW0gaXMgdGhhdCBhbGwg b2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJpdHMsIGFuZCB5b3UgaGF2ZSB0byBz ZXJpb3VzbHkgY29tcHJvbWlzZSBvbiB0aGUgc3RyZW5ndGggb2YgdGhlIGNoZWNrc3VtICh3aGlj aCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ugd2FudCBpdCB0byBiZSBhIE1BQyByYXRoZXINCiB0 aGFuIGEgY2hlY2tzdW0pLiZuYnNwOyBUaGUgc2Vjb25kIHByb2JsZW0gaXMgdGhhdCBlbmNyeXB0 aW5nIDY0LWJpdCB2YWx1ZXMgZmFzdCBpcyBhY3R1YWxseSBmYWlybHkgaGFyZCBzaW5jZSB0aGUg YmxvY2sgY2lwaGVycyBlYXNpbHkgYXZhaWxhYmxlIGluIGhhcmR3YXJlIGhhdmUgMTI4LWJpdCBi bG9jayBzaXplLCBhbmQgdGhlIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvbiBsb2FkIGJhbGFu Y2VycyBhcmUgdGlnaHRlciB0aGFuIG9uIHNlcnZlcnMuJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG90aGVyIHdvcmRz LCBoYXZpbmcgYSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgcHJvdmlkZXMgZm9yIGFuIGVhc3kgc2Vj dXJlIHdheSB0byBnZW5lcmF0ZSB1bmxpbmthYmxlIGNvbm5lY3Rpb24gSURzIG9uIG1pZ3JhdGlv bi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U28sIHRoZSBwcm9ibGVtIHdl4oCZcmUgdHJ5aW5nIHRvIHNvbHZlIGlzIHRoYXQgdGhlIGNvbm5l Y3Rpb24gSUQgaXMgdG9vIHNtYWxsLiZuYnNwOyBUaGVyZSBhcmUgdHdvIHF1ZXN0aW9ucyBJIGJl bGlldmUgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFuc3dlciBhdCB0aGlzIHBvaW50OjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8y Ij4NCkRvIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBz dGFuZGFyZGl6YXRpb24gcHJvY2Vzcz88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSWYgd2UgZG9u 4oCZdCBhZGRyZXNzIHRoaXMgcHJvYmxlbSByaWdodCBub3csIGhvdyBkbyB3ZSBzdHJ1Y3R1cmUg dGhlIHN0YW5kYXJkIGluIGEgd2F5IHRoYXQgd2UgY2FuIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJ RCBpbiB0aGUgZnV0dXJlPzxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHBy b2JsZW0gb2YgbWFraW5nIGNvbm5lY3Rpb24gSUQgbGFyZ2VyLiZuYnNwOyBPbmUgaXMgdG8ganVz dCBhZGQgZXh0cmEgYml0IHRvIHRoZSDigJxvbWl0IGNvbm5lY3Rpb24gSUTigJ0gZmllbGQgdG8g YWxsb3cgMTI4LWJpdCBjb25uZWN0aW9uIElEcy4mbmJzcDsgQW5vdGhlciBhcHByb2FjaCBpcyB0 byBhbGxvdyBjb25uZWN0aW9uIElEIHNpemUgdG8gYmUgZXhwbGljaXRseQ0KIHNwZWNpZmllZCBi eSB0aGUgc2VydmVyLCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBrbm93 cyB0aGF0IHNpemUgYW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBwYXRoIG5lZWRzIHRvIHJlYWQgaXQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZXJl4oCZcyBhbHNvIGEgcXVlc3Rpb24gb2YgaG93IG11Y2ggb2YgY29ubmVjdGlvbiBJRHMgZG8g bWlkZGxlYm94ZXMgKGV4Y2x1ZGluZyBsb2FkIGJhbGFuY2VycyBhbmQgb3RoZXIgYm94ZXMgb3du ZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFzIGVpdGhlciBjbGllbnQgb3Igc2VydmVyKSBuZWVkIHRv IGtub3cuJm5ic3A7IFdlIGNvdWxkIGdvIGZvciBib3RoIOKAnG1pZGRsZWJveGVzIHNob3VsZCBi ZSBhbHdheXMgYWJsZSB0bw0KIHJlYWQgdGhlIGVudGlyZSBJROKAnSBhbmQg4oCcbWlkZGxlYm94 ZXMgc2hvdWxkIG5vdCByZWFkIGNvbm5lY3Rpb24gSURzIGF0IGFsbCBvcHRpb25z4oCdLCBidXQg SSB0aGluayB0aGVyZeKAmXMgYWxzbyBhIHJvb20gZm9yIG1vcmUgZmxleGlibGUgZm9ybXVsYXRp b25zIGxpa2Ug4oCcbWlkZGxlYm94ZXMgYWx3YXlzIGdldCBmaXJzdCA2NCBiaXRzIGFuZCB0aGV5 IGhhdmUgdXNlZnVsIGVudHJvcHkgdG8gZGlzdGluZ3Vpc2ggY29ubmVjdGlvbnPigJ0uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAt LSBWaWN0b3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_d2a6136f93654eb1a5c7970cfb41f7adusma1exdag1mb5msgcorpak_-- From nobody Thu Jan 11 16:25:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E041275F4 for ; Thu, 11 Jan 2018 16:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PukALtqk9OTF for ; Thu, 11 Jan 2018 16:25:28 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB43126D85 for ; Thu, 11 Jan 2018 16:25:28 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id b198so1296966iof.6 for ; Thu, 11 Jan 2018 16:25:28 -0800 (PST) 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=FPu71UIvAxFntyp+XQcdXHNX08OziNq0gpJWQpGE/as=; b=jSt4yUxSntFmD9maL1to2QILpn2CyDByN53B/+tdRw7qfn2VbxKjRFDZZ4Bn+Xl73Y pYtJM4k3h0Qk47H42+xhmHS4XMWofMiErw1VlMThPO3y4oRmupaLo6po3KzJiyuwsYb7 5q77dSKTftHlb4/cyQODPHvn28vMPJ5Nwf75NOkdKwT2bJ6fBothvadeReMe4UAGqgaU qF7icLaPla0X+7H46sWFgLNtGY0sPR3Fv7wkPKG72MgrXlZ4Jxkzh18ia2B6h68AnFjH tPloI8QSL1SWQGsNCenKLCcjrtdDpRrOY3o4TcQXbygy3qaGBX8j0tf6qzPmtHynTMwo besg== 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=FPu71UIvAxFntyp+XQcdXHNX08OziNq0gpJWQpGE/as=; b=EFHvlTwhydiKVKDuvK6C5HAqdpkYwRRu1m2RE90pdltzBFID7pTRHH4sqhoKabLiOi xqAi73y5vPaCk6fZk/LuyOnI/dxXscKlyAPsWHmRYi176sCmT4W3dQz/o82peldub3Wt a8M2MAD5005LQfNjg25kSXQiuGO64zR1d1SDn1kGUHhJpcKgBQoIz433cjX4vC0cx+YO pDh2B2l7b0rQrUI2neVIW2AXRbMTtfb2uD05KXngDVz/IVWvZCarbQNLbmgBXFR6e17q YoB4A1JU6O0dn0CdEhxCTzN3vHfdqQ5673NBwvvfAHEbx7m49I6BCNCqG3FLjqElaPjV ziOQ== X-Gm-Message-State: AKwxytesYyFil3hmJsjuPz9aC3hrN6qjKSHfHN/+BbY6p+B7bYWUIxSi 4E/eojvZ5yVKZFWDLqTTf5b7WedfEOSJwhZlKbs= X-Google-Smtp-Source: ACJfBoubfWc7rco0Byw5Chmaq8rz3tgbwP8cwsCiTGs7FFPRI0LeuJMIDv4asIhV6X9kJFcwm0qDwW9y1S81SYEreGg= X-Received: by 10.107.195.68 with SMTP id t65mr5898769iof.175.1515716728021; Thu, 11 Jan 2018 16:25:28 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 16:25:27 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 16:25:27 -0800 Message-ID: Subject: RE: Increasing QUIC connection ID size To: "Lubashev, Igor" , Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c188e6c2769860562894daa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 00:25:32 -0000 --94eb2c188e6c2769860562894daa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, on encryption of connection ID, this is not so simple. We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but it can be public. This means that it must be stored in th= e packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload. Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote: I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum. I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation. - Igor *From:* Victor Vasiliev [mailto:vasilvv@google.com] *Sent:* Thursday, January 11, 2018 6:16 PM *To:* IETF QUIC WG *Subject:* Increasing QUIC connection ID size Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --94eb2c188e6c2769860562894daa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Actually, on encrypt= ion of connection ID, this is not so simple.

    We must assume there is only a single key for many = connections because the router is not part of a key exchange. This unique v= alue or counter used for encrypting a single block cannot be the same for t= wo different connections ID=E2=80=99s, but it can be public. This means tha= t it must be stored in the packet header. And, as it turns out, random conn= ection ID chosen by a trusted source, can be used for such a unique value. = But then it must be used to encrypt and/or authenticate something else carr= ying the actual routing information. So now you start to really need some e= xtra payload.

    Alterna= tively the routing information is entirely random such as content hashed ro= uting. Then you only need to authenticate the routing data. You can do that= with a HMAC, and CMAC could probably also work. The additional benefit is = that you can probably get away with 64-bits for all routing information pos= sibly including the auth tag. Say 48 bits of routing data and 16 bits of au= th tag.

    Kind Rega= rds,
    Mikkel = Fahn=C3=B8e J=C3=B8rgensen


    = On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it= allows for more flexible schemes of encoding routing metadata and a checks= um.=C2=A0 I would also like to be explicit about the connection ID size in = a packet header, though, since it greatly simplifies the implementation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org<= /a>>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID si= ze is fixed to be a 64-bit opaque blob, and that is set as an invariant in = the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibility of using a conn= ection ID to encode the specific server details into it (to provide stabili= ty of the connection in case of load balancing changes, especially BGP flap= s for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like= 64 bits might be too small for this purpose, and we might want to leave an= opportunity to extend the connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing meta= data.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information a= nd allow generating uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The firs= t problem is that all of this does not fit well into 64 bits, and you have = to seriously compromise on the strength of the checksum (which is bad espec= ially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit value= s fast is actually fairly hard since the block ciphers easily available in = hardware have 128-bit block size, and the performance requirements on load = balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provi= des for an easy secure way to generate unlinkable connection IDs on migrati= on.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is tha= t the connection ID is too small.=C2=A0 There are two questions I believe t= he working group should answer at this point:

    1. Do we want to address this problem at this point in standardization process= ?
    2. If we don=E2=80=99t address this problem right now, how do we structure the= standard in a way that we can extend the connection ID in the future?
      3. =

    There are multiple ways to solve the problem of maki= ng connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80= =9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs.=C2=A0= Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that= size and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of conne= ction IDs do middleboxes (excluding load balancers and other boxes owned by= the same entity as either client or server) need to know.=C2=A0 We could g= o for both =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read conne= ction IDs at all options=E2=80=9D, but I think there=E2=80=99s also a room = for more flexible formulations like =E2=80=9Cmiddleboxes always get first 6= 4 bits and they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.

    --94eb2c188e6c2769860562894daa-- From nobody Thu Jan 11 16:45:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66B61270AB for ; Thu, 11 Jan 2018 16:45:22 -0800 (PST) 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=hZ042KJc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=VGozuShX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xcE-b6dz8cE for ; Thu, 11 Jan 2018 16:45:21 -0800 (PST) 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 F23FF126579 for ; Thu, 11 Jan 2018 16:45:20 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C0ifwn012619; Thu, 11 Jan 2018 16:45:19 -0800 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=ENEpyJZ0PmA4H6Nn++v30/t9qSiqGVT24A4PUx6UV4s=; b=hZ042KJceAoXbghiD4rbWLFenKTOqEgN7322e7MsLg2Ox9DbgBTGQlJJnQ+7oK8MwmzK 53B0LUlT6Xavk2UuP/vpiS49RDLWP6vxczk2jNcgDrcqzZec5WUDFZ+7E033O8P2w/QR OYi6x4a1a9hk37HmBqvnlBJuwFeTGU4MHm8= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fege78ged-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 16:45:19 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 11 Jan 2018 19:45:17 -0500 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=ENEpyJZ0PmA4H6Nn++v30/t9qSiqGVT24A4PUx6UV4s=; b=VGozuShXLGylXegBlkj8c270M0p5I31eo+xvPC9ZnoyU/AUxHn+ekDsS7KW6vh2wN6RMNkhSP46WcUOu6j7yaDqz2yiA/lBCGgBAg4VxtBIrZ4lo9LxQOQtwacab83YlNFfs1JVdyWKwVUwLf1A1YnjEDxET6OmSSujdwitbWKs= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 00:45:16 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 00:45:16 +0000 From: Roberto Peon To: Victor Vasiliev , IETF QUIC WG Subject: Re: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNu4LeA Date: Fri, 12 Jan 2018 00:45:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:47a8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:29NI+BH5CBHBc/eaSr7gDwP9QQEsSnIWg4KdYY02ZrzB1aYzEsac3+6pfcFgfi4ZLse+VAt0tADJN2+bdzy5A7P/Xo/BYo784D+dxyflghvbQ6nEmBDwc4PCSCs6g3WmjDc5wkxEj3x5X6Y6Tnq79fAP/02+duAkaOJUEejka/xYrtj3VQd8GNWYpbV9L4eAwPYpJZ3vNKSGc7shamjZMBBz5aQCAMwHSmOoyVjszX4Ug6+4BhN6cF41msPENbiC; 20:9BACC7M0uM3sGt2bLPjc3NZJnZMmitIP2E7GbT8x9iNd5KDTtUgL1aXGmrBy6JEts0PNuyNso3jFjHXXeGlIjrnsxDhrFN/nu0x8JgUJwT7lgmGM5s3E/b60MlrW2JhNfStCFsePnYP/etJa6hUA6IMJ6WsmjZsfRV5hqKqQGk8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4224d137-232b-4aa3-b852-08d55955bfae x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020074)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189; x-ms-traffictypediagnostic: SN6PR1501MB2189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(346002)(366004)(39380400002)(199004)(189003)(53754006)(99286004)(105586002)(5250100002)(316002)(6116002)(2900100001)(106356001)(53546011)(36756003)(478600001)(110136005)(86362001)(25786009)(76176011)(102836004)(8936002)(53936002)(6506007)(33656002)(14454004)(68736007)(5660300001)(2950100002)(97736004)(54896002)(3660700001)(83716003)(6306002)(81166006)(81156014)(6512007)(3280700002)(7736002)(229853002)(2906002)(6486002)(6436002)(8676002)(82746002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /vnUEnrMgrjtgj00JKg8UowKdO/0Ax2sjxP0F5wQGdESM7llirzWGlUaDze78LWlYgD2exeqBWqo9LGn9A5f4g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E23921304F0042D981E3F66CA4D6FBF2fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4224d137-232b-4aa3-b852-08d55955bfae X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 00:45:16.4690 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 00:45:23 -0000 --_000_E23921304F0042D981E3F66CA4D6FBF2fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGF2aW5nIHRoZSBzZXJ2ZXIgc3BlY2lmeSB0aGUgY29ubklELXNpemUgYXMgcGFydCBvZiB0aGUg Y29ubmVjdGlvbiBzZXR1cCt2ZXJzaW9uIG5lZ290aWF0aW9uIHdvdWxkIGNlcnRhaW5seSBiZSBn cmVhc2UteS4NCg0KQSBsYXJnZXIgY29ubklEIGhlbHBzIHRvIHNvbHZlIGEgbG90IG9mIEw0PC0+ TDcgcm91dGluZyBpc3N1ZXMsIGFncmVlZCwgcHJlLXN1cHBvc2luZyB0aGF0IHRoZSBzZXJ2ZXIg YWx3YXlzIHBpY2tzIHRoZSBuZXcvYWx0ZXJuYXRlIGNvbm4tSUQgZm9yIHRoZSBjbGllbnQuDQot PVINCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgVmlj dG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFy eSAxMSwgMjAxOCBhdCAzOjE2IFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0K U3ViamVjdDogSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZQ0KDQpIaSBldmVyeW9u ZSwNCg0KSW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVjdGlvbiBJRCBz aXplIGlzIGZpeGVkIHRvIGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhhdCBpcyBzZXQg YXMgYW4gaW52YXJpYW50IGluIHRoZSBwcm90b2NvbC4NCg0KSeKAmXZlIGxvb2tlZCBpbnRvIHBv c3NpYmlsaXR5IG9mIHVzaW5nIGEgY29ubmVjdGlvbiBJRCB0byBlbmNvZGUgdGhlIHNwZWNpZmlj IHNlcnZlciBkZXRhaWxzIGludG8gaXQgKHRvIHByb3ZpZGUgc3RhYmlsaXR5IG9mIHRoZSBjb25u ZWN0aW9uIGluIGNhc2Ugb2YgbG9hZCBiYWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBCR1Ag ZmxhcHMgZm9yIGFueWNhc3QgSVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91dCB0aGlzIHdpdGgg b3RoZXIgcGVvcGxlIEkga25ldyB3ZXJlIGludGVyZXN0ZWQgaW4gdGhpcy4gIEl0IHNlZW1zIGxp a2UgNjQgYml0cyBtaWdodCBiZSB0b28gc21hbGwgZm9yIHRoaXMgcHVycG9zZSwgYW5kIHdlIG1p Z2h0IHdhbnQgdG8gbGVhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZXh0ZW5kIHRoZSBjb25uZWN0aW9u IElEIHNpemUuDQoNClRoZSBiYXNpYyBpZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0 bzoNCg0KICAxLiAgU3RvcmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0aW9u IElELg0KICAyLiAgSGF2ZSBzb21lIGVudHJvcHkgdGhhdCBhbGxvd3MgZGlzdGluZ3Vpc2ggdXNl cnMgd2l0aCBpZGVudGljYWwgcm91dGluZyBtZXRhZGF0YS4NCiAgMy4gIEhhdmUgYSBjaGVja3N1 bSB0byBlbnN1cmUgdGhlIHZhbGlkaXR5IG9mIHJvdXRpbmcgaW5mb3JtYXRpb24NCiAgNC4gIEVu Y3J5cHQgdGhlIGluZm9ybWF0aW9uIGFib3ZlIHRvIHByZXZlbnQgZGlzY2xvc2luZyB0aGUgcm91 dGUgaW5mb3JtYXRpb24gYW5kIGFsbG93IGdlbmVyYXRpbmcgdW5jb3JyZWxhdGFibGUgY29ubmVj dGlvbiBJRHMuDQpUaGVyZSBhcmUgdHdvIHVuZGVybHlpbmcgaXNzdWVzIGhlcmUuICBUaGUgZmly c3QgcHJvYmxlbSBpcyB0aGF0IGFsbCBvZiB0aGlzIGRvZXMgbm90IGZpdCB3ZWxsIGludG8gNjQg Yml0cywgYW5kIHlvdSBoYXZlIHRvIHNlcmlvdXNseSBjb21wcm9taXNlIG9uIHRoZSBzdHJlbmd0 aCBvZiB0aGUgY2hlY2tzdW0gKHdoaWNoIGlzIGJhZCBlc3BlY2lhbGx5IGlmIHlvdSB3YW50IGl0 IHRvIGJlIGEgTUFDIHJhdGhlciB0aGFuIGEgY2hlY2tzdW0pLiAgVGhlIHNlY29uZCBwcm9ibGVt IGlzIHRoYXQgZW5jcnlwdGluZyA2NC1iaXQgdmFsdWVzIGZhc3QgaXMgYWN0dWFsbHkgZmFpcmx5 IGhhcmQgc2luY2UgdGhlIGJsb2NrIGNpcGhlcnMgZWFzaWx5IGF2YWlsYWJsZSBpbiBoYXJkd2Fy ZSBoYXZlIDEyOC1iaXQgYmxvY2sgc2l6ZSwgYW5kIHRoZSBwZXJmb3JtYW5jZSByZXF1aXJlbWVu dHMgb24gbG9hZCBiYWxhbmNlcnMgYXJlIHRpZ2h0ZXIgdGhhbiBvbiBzZXJ2ZXJzLg0KDQpJbiBv dGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElEIHByb3ZpZGVzIGZvciBh biBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5saW5rYWJsZSBjb25uZWN0aW9uIElEcyBv biBtaWdyYXRpb24uDQoNClNvLCB0aGUgcHJvYmxlbSB3ZeKAmXJlIHRyeWluZyB0byBzb2x2ZSBp cyB0aGF0IHRoZSBjb25uZWN0aW9uIElEIGlzIHRvbyBzbWFsbC4gIFRoZXJlIGFyZSB0d28gcXVl c3Rpb25zIEkgYmVsaWV2ZSB0aGUgd29ya2luZyBncm91cCBzaG91bGQgYW5zd2VyIGF0IHRoaXMg cG9pbnQ6DQoNCiAgMS4gIERvIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gYXQgdGhp cyBwb2ludCBpbiBzdGFuZGFyZGl6YXRpb24gcHJvY2Vzcz8NCiAgMi4gIElmIHdlIGRvbuKAmXQg YWRkcmVzcyB0aGlzIHByb2JsZW0gcmlnaHQgbm93LCBob3cgZG8gd2Ugc3RydWN0dXJlIHRoZSBz dGFuZGFyZCBpbiBhIHdheSB0aGF0IHdlIGNhbiBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQgaW4g dGhlIGZ1dHVyZT8NClRoZXJlIGFyZSBtdWx0aXBsZSB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVt IG9mIG1ha2luZyBjb25uZWN0aW9uIElEIGxhcmdlci4gIE9uZSBpcyB0byBqdXN0IGFkZCBleHRy YSBiaXQgdG8gdGhlIOKAnG9taXQgY29ubmVjdGlvbiBJROKAnSBmaWVsZCB0byBhbGxvdyAxMjgt Yml0IGNvbm5lY3Rpb24gSURzLiAgQW5vdGhlciBhcHByb2FjaCBpcyB0byBhbGxvdyBjb25uZWN0 aW9uIElEIHNpemUgdG8gYmUgZXhwbGljaXRseSBzcGVjaWZpZWQgYnkgdGhlIHNlcnZlciwgYW5k IHRoZW4gYXNzdW1lIHRoYXQgdGhlIGxvYWQgYmFsYW5jZXIga25vd3MgdGhhdCBzaXplIGFuZCBu byBvbmUgZWxzZSBvbiB0aGUgcGF0aCBuZWVkcyB0byByZWFkIGl0Lg0KDQpUaGVyZeKAmXMgYWxz byBhIHF1ZXN0aW9uIG9mIGhvdyBtdWNoIG9mIGNvbm5lY3Rpb24gSURzIGRvIG1pZGRsZWJveGVz IChleGNsdWRpbmcgbG9hZCBiYWxhbmNlcnMgYW5kIG90aGVyIGJveGVzIG93bmVkIGJ5IHRoZSBz YW1lIGVudGl0eSBhcyBlaXRoZXIgY2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiAgV2Ug Y291bGQgZ28gZm9yIGJvdGgg4oCcbWlkZGxlYm94ZXMgc2hvdWxkIGJlIGFsd2F5cyBhYmxlIHRv IHJlYWQgdGhlIGVudGlyZSBJROKAnSBhbmQg4oCcbWlkZGxlYm94ZXMgc2hvdWxkIG5vdCByZWFk IGNvbm5lY3Rpb24gSURzIGF0IGFsbCBvcHRpb25z4oCdLCBidXQgSSB0aGluayB0aGVyZeKAmXMg YWxzbyBhIHJvb20gZm9yIG1vcmUgZmxleGlibGUgZm9ybXVsYXRpb25zIGxpa2Ug4oCcbWlkZGxl Ym94ZXMgYWx3YXlzIGdldCBmaXJzdCA2NCBiaXRzIGFuZCB0aGV5IGhhdmUgdXNlZnVsIGVudHJv cHkgdG8gZGlzdGluZ3Vpc2ggY29ubmVjdGlvbnPigJ0uDQoNCiAgLS0gVmljdG9yLg0K --_000_E23921304F0042D981E3F66CA4D6FBF2fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <772E915FB2414143B4B64AF9757D6D4A@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxp c3QtaWQ6ODU1MjY0MTQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTI1Njk1NzYzNDt9DQpA bGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxODgwMzEyMTkxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTkzNTEwNjk2NDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIHRoZSBzZXJ2ZXIg c3BlY2lmeSB0aGUgY29ubklELXNpemUgYXMgcGFydCBvZiB0aGUgY29ubmVjdGlvbiBzZXR1cCYj NDM7dmVyc2lvbiBuZWdvdGlhdGlvbiB3b3VsZCBjZXJ0YWlubHkgYmUgZ3JlYXNlLXkuPGJyPg0K PGJyPg0KQSBsYXJnZXIgY29ubklEIGhlbHBzIHRvIHNvbHZlIGEgbG90IG9mIEw0Jmx0Oy0mZ3Q7 TDcgcm91dGluZyBpc3N1ZXMsIGFncmVlZCwgcHJlLXN1cHBvc2luZyB0aGF0IHRoZSBzZXJ2ZXIg YWx3YXlzIHBpY2tzIHRoZSBuZXcvYWx0ZXJuYXRlIGNvbm4tSUQgZm9yIHRoZSBjbGllbnQuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIFZpY3RvciBWYXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCBhdCAzOjE2IFBN PGJyPg0KPGI+VG86IDwvYj5JRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDogPC9iPkluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBldmVyeW9uZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVj dGlvbiBJRCBzaXplIGlzIGZpeGVkIHRvIGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhh dCBpcyBzZXQgYXMgYW4gaW52YXJpYW50IGluIHRoZSBwcm90b2NvbC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZlIGxvb2tlZCBpbnRv IHBvc3NpYmlsaXR5IG9mIHVzaW5nIGEgY29ubmVjdGlvbiBJRCB0byBlbmNvZGUgdGhlIHNwZWNp ZmljIHNlcnZlciBkZXRhaWxzIGludG8gaXQgKHRvIHByb3ZpZGUgc3RhYmlsaXR5IG9mIHRoZSBj b25uZWN0aW9uIGluIGNhc2Ugb2YgbG9hZCBiYWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBC R1AgZmxhcHMgZm9yIGFueWNhc3QgSVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91dA0KIHRoaXMg d2l0aCBvdGhlciBwZW9wbGUgSSBrbmV3IHdlcmUgaW50ZXJlc3RlZCBpbiB0aGlzLiZuYnNwOyBJ dCBzZWVtcyBsaWtlIDY0IGJpdHMgbWlnaHQgYmUgdG9vIHNtYWxsIGZvciB0aGlzIHB1cnBvc2Us IGFuZCB3ZSBtaWdodCB3YW50IHRvIGxlYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUg Y29ubmVjdGlvbiBJRCBzaXplLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgYmFzaWMgaWRlYSBpcyB0aGF0IHlvdSB3YW50IHRvIGJlIGFi bGUgdG86PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9 IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzEiPg0KU3RvcmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0 aW9uIElELjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpIYXZlIHNvbWUgZW50cm9weSB0aGF0IGFs bG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50aWNhbCByb3V0aW5nIG1ldGFkYXRhLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvMSI+DQpIYXZlIGEgY2hlY2tzdW0gdG8gZW5zdXJlIHRoZSB2YWxp ZGl0eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCkVuY3J5 cHQgdGhlIGluZm9ybWF0aW9uIGFib3ZlIHRvIHByZXZlbnQgZGlzY2xvc2luZyB0aGUgcm91dGUg aW5mb3JtYXRpb24gYW5kIGFsbG93IGdlbmVyYXRpbmcgdW5jb3JyZWxhdGFibGUgY29ubmVjdGlv biBJRHMuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGVyZSBhcmUgdHdvIHVuZGVybHlpbmcgaXNzdWVzIGhlcmUuJm5ic3A7IFRoZSBm aXJzdCBwcm9ibGVtIGlzIHRoYXQgYWxsIG9mIHRoaXMgZG9lcyBub3QgZml0IHdlbGwgaW50byA2 NCBiaXRzLCBhbmQgeW91IGhhdmUgdG8gc2VyaW91c2x5IGNvbXByb21pc2Ugb24gdGhlIHN0cmVu Z3RoIG9mIHRoZSBjaGVja3N1bSAod2hpY2ggaXMgYmFkIGVzcGVjaWFsbHkgaWYgeW91IHdhbnQg aXQgdG8gYmUgYSBNQUMgcmF0aGVyDQogdGhhbiBhIGNoZWNrc3VtKS4mbmJzcDsgVGhlIHNlY29u ZCBwcm9ibGVtIGlzIHRoYXQgZW5jcnlwdGluZyA2NC1iaXQgdmFsdWVzIGZhc3QgaXMgYWN0dWFs bHkgZmFpcmx5IGhhcmQgc2luY2UgdGhlIGJsb2NrIGNpcGhlcnMgZWFzaWx5IGF2YWlsYWJsZSBp biBoYXJkd2FyZSBoYXZlIDEyOC1iaXQgYmxvY2sgc2l6ZSwgYW5kIHRoZSBwZXJmb3JtYW5jZSBy ZXF1aXJlbWVudHMgb24gbG9hZCBiYWxhbmNlcnMgYXJlIHRpZ2h0ZXIgdGhhbiBvbiBzZXJ2ZXJz LiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBvdGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElE IHByb3ZpZGVzIGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5saW5rYWJsZSBj b25uZWN0aW9uIElEcyBvbiBtaWdyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCB0aGUgcHJvYmxlbSB3ZeKAmXJlIHRyeWluZyB0 byBzb2x2ZSBpcyB0aGF0IHRoZSBjb25uZWN0aW9uIElEIGlzIHRvbyBzbWFsbC4mbmJzcDsgVGhl cmUgYXJlIHR3byBxdWVzdGlvbnMgSSBiZWxpZXZlIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBh bnN3ZXIgYXQgdGhpcyBwb2ludDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBz dGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQpEbyB3ZSB3YW50IHRvIGFkZHJlc3MgdGhpcyBw cm9ibGVtIGF0IHRoaXMgcG9pbnQgaW4gc3RhbmRhcmRpemF0aW9uIHByb2Nlc3M/PG86cD48L286 cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8yIj4NCklmIHdlIGRvbuKAmXQgYWRkcmVzcyB0aGlzIHByb2JsZW0gcmlnaHQg bm93LCBob3cgZG8gd2Ugc3RydWN0dXJlIHRoZSBzdGFuZGFyZCBpbiBhIHdheSB0aGF0IHdlIGNh biBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQgaW4gdGhlIGZ1dHVyZT88bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBtdWx0 aXBsZSB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIG1ha2luZyBjb25uZWN0aW9uIElEIGxh cmdlci4mbmJzcDsgT25lIGlzIHRvIGp1c3QgYWRkIGV4dHJhIGJpdCB0byB0aGUg4oCcb21pdCBj b25uZWN0aW9uIElE4oCdIGZpZWxkIHRvIGFsbG93IDEyOC1iaXQgY29ubmVjdGlvbiBJRHMuJm5i c3A7IEFub3RoZXIgYXBwcm9hY2ggaXMgdG8gYWxsb3cgY29ubmVjdGlvbiBJRCBzaXplIHRvIGJl IGV4cGxpY2l0bHkNCiBzcGVjaWZpZWQgYnkgdGhlIHNlcnZlciwgYW5kIHRoZW4gYXNzdW1lIHRo YXQgdGhlIGxvYWQgYmFsYW5jZXIga25vd3MgdGhhdCBzaXplIGFuZCBubyBvbmUgZWxzZSBvbiB0 aGUgcGF0aCBuZWVkcyB0byByZWFkIGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZeKAmXMgYWxzbyBhIHF1ZXN0aW9uIG9mIGhvdyBt dWNoIG9mIGNvbm5lY3Rpb24gSURzIGRvIG1pZGRsZWJveGVzIChleGNsdWRpbmcgbG9hZCBiYWxh bmNlcnMgYW5kIG90aGVyIGJveGVzIG93bmVkIGJ5IHRoZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIg Y2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiZuYnNwOyBXZSBjb3VsZCBnbyBmb3IgYm90 aCDigJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3YXlzIGFibGUgdG8NCiByZWFkIHRoZSBlbnRp cmUgSUTigJ0gYW5kIOKAnG1pZGRsZWJveGVzIHNob3VsZCBub3QgcmVhZCBjb25uZWN0aW9uIElE cyBhdCBhbGwgb3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGFsc28gYSByb29tIGZv ciBtb3JlIGZsZXhpYmxlIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1pZGRsZWJveGVzIGFsd2F5cyBn ZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRvIGRpc3Rpbmd1 aXNoIGNvbm5lY3Rpb25z4oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLS0gVmljdG9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E23921304F0042D981E3F66CA4D6FBF2fbcom_-- From nobody Thu Jan 11 16:52:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F13126C22 for ; Thu, 11 Jan 2018 16:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 IcEmiUUpG27O for ; Thu, 11 Jan 2018 16:52:54 -0800 (PST) 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 8C10D126579 for ; Thu, 11 Jan 2018 16:52:54 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id t201so1858671ywf.1 for ; Thu, 11 Jan 2018 16:52:54 -0800 (PST) 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=r4wJJNdBTD4VccX1aAZlwtnwTPJTYvtypv+BlSMFTlU=; b=CdkKiFJncfz7Gi6gzXcvMNEqci32Y6SUwo+H9BLQdFyA7QQphGRrXWs9foZBfZyvz3 3Pwfab6BfxB+iu5TpFDc9CDAmI+lDGwKhRqMeNlxLE740z8pzeur48HZtAda5H/OkhUx W0GxdQ93iFIR8JdNHYvN57or1UGV+5SqJUXn9t/7mnEZ9kqV1BDCVvRtsGMenPhf3Ru3 C/01IE8Un4CYLtRTK6g5n3OAq+pAC3PekH0MHdUkJkwh9O9YgeGeZkcO9YR+H6giYbzX Jcn+vdyTSADvH1rfyUUF8gLs9I01NKWqn8/9ty+E1B0s3/ogu5cqgwJ3A3KUXx12BL85 yuUg== 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=r4wJJNdBTD4VccX1aAZlwtnwTPJTYvtypv+BlSMFTlU=; b=L5uxTR74rgxGp+MZ4Nh41yqj28Z77PTnPlG70AYDDC2vLxpA7SGlSnffOHZBZK0qxP XnFk+pp3mMy2yp+xhIO05NC2lu4jD569Kw0v459VBh4dw+bMxCJVptO6Ap4ZEXyT9lB2 1rrUFvXsxUxdbemDQDcRRC7TUIE46flSTNco+2amoMJd9fWJz8IDVy6VBJsBMGyni3ji wPeuog5B1mfSJjZSFyik8WsWofX0Hm/uHpoKgLi7mvKuPB6ClU7o95sZsNeVk4oX5UhD 8tcVin+8L/7+S9Q6cY+EpcZKxZ7olEYpkYt9LuOdD0saebtqlvVBxMr+wKLLPfZiZzpN qpWw== X-Gm-Message-State: AKGB3mKnGT08jZO7tbO4hxWdFDKiMSJ9bwYQwFuDi+a2TL67GppN98yg bNIJNBE1TSPccDinIXN9x+jydfEcg7zt3ug7hUT4qQ== X-Google-Smtp-Source: ACJfBoss3PtpXQTHvEOj6qweBSZZIOqjmzpPqGKitQNCoIMVr8MvDGdXma58HwS79GlL+muMMu47vs60sNuTbReicFk= X-Received: by 10.129.68.40 with SMTP id r40mr12217411ywa.371.1515718373422; Thu, 11 Jan 2018 16:52:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Thu, 11 Jan 2018 16:52:52 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 11 Jan 2018 16:52:52 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Roberto Peon Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="f403045ed28c3ad179056289af88" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 00:52:57 -0000 --f403045ed28c3ad179056289af88 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Roberto, I'm not convinced that we need something as heavy-weight as this... specifically, flow control so far has been in the receiver's control, which is also the thing that owns the resource it is trying to limit exhaustion of. This moves it out to the sender, which would require a receiver to now commit memory based on what a sender believes is important. Reasoning about this seems non-trivial. I worry about how all this degree of freedom will get abused, and potential sharp edges. If we can ensure priority consumption of the shared resource, that seems adequate to resolve the problem on hand. Do you think something more is required? - jana On Wed, Jan 10, 2018 at 12:26 PM, Roberto Peon wrote: > Another option: > Allow a flow-control =E2=80=98override=E2=80=99 which allows a receiver t= o state that they > really want data on a particular stream, and ignore the global flow contr= ol > for this. > > How you=E2=80=99d do it: > A receiver can send a flow-control override for a stream. This includes > the stream id to which the global window temporarily does not apply, the > receiver=E2=80=99s current stream flow-control offset, and the offset the= receiver > would wish to be able to receive. > A receiver must continue to (re)send the override (i.e. rexmit) until it > is ack=E2=80=99d. It cannot send other flow-control for that stream until= the > override is ack=E2=80=99d. > Thus: > global-flow-control-override: = , > > > The sender (which receives the override) credits the global flow control > with the difference between the data sent beyond the receivers > currently-known flow-control offset upon receipt of the override. > This synchronizes the global state between the receiver and the sender. > The sender can then send the data on the stream (without touching any > other flow control data). > > Why: > This allows for a receiver to resolve priority inversions which would > otherwise lead to deadlock, even when the data/dep leading to this was no= t > known to the transport. This extends beyond such issues beyond just heade= r > compression. > > Since the global flow-control exists to protect the app from resource > exhaustion, this poses no additional risk to the application. > Simply increasing the global flow control provides less strong > guarantees=E2=80=94any stream might consume it, which doesn=E2=80=99t res= olve the dep > inversion. Rejiggering priorities can help to resolve this, but would > require the sender to send priorities to the client, which is problematic > w.r.t.races and just a web of ick. > > Having a custom frame type is also a less strong guarantee as it requires > the knowledge that the dep exists to be present at the time of sending, > which is often impossible. > > -=3DR > > On 1/9/18, 10:17 PM, "QUIC on behalf of Martin Thomson" < > quic-bounces@ietf.org on behalf of martin.thomson@gmail.com> wrote: > > Building a complex application protocol on top of QUIC continues to > produce surprises. > > Today in the header compression design team meeting we discussed a > deadlocking issue that I think warrants sharing with the larger group= . > This has implications for how people build a QUIC transport layer. I= t > might need changes to the API that is exposed by that layer. > > This isn't really that new, but I don't think we've properly addresse= d > the problem. > > > ## The Basic Problem > > If a protocol creates a dependency between streams, there is a > potential for flow control to deadlock. > > Say that I send X on stream 3 and Y on stream 7. Processing Y > requires that X is processed first. > > X cannot be sent due to flow control but Y is sent. This is always > possible even if X is appropriately prioritized. The receiver then > leaves Y in its receive buffer until X is received. > > The receiver cannot give flow control credit for consuming Y because > it can't consume Y until X is sent. But the sender needs flow contro= l > credit to send X. We are deadlocked. > > It doesn't matter whether the stream or connection flow control is > causing the problem, either produces the same result. > > (To give some background on this, we were considering a preface to > header blocks that identified the header table state that was > necessary to process the header block. This would allow for > concurrent population of the header table and sending message that > depended on the header table state that is under construction. A > receiver would read the identifier and then leave the remainder of th= e > header block in the receive buffer until the header table was ready.) > > > ## Options > > It seems like there are a few decent options for managing this. Thes= e > are what occurred to me (there are almost certainly more options): > > 1. Don't do that. We might concede in this case that seeking the > incremental improvement to compression efficiency isn't worth the > risk. That is, we might make a general statement that this sort of > inter-stream blocking is a bad idea. > > 2. Force receivers to consume data or reset streams in the case of > unfulfilled dependencies. The former seems like it might be too much > like magical thinking, in the sense that it requires that receivers > conjure more memory up, but if the receiver were required to read Y > and release the flow control credit, then all would be fine. For > instance, we could require that the receiver reset a stream if it > couldn't read and handle data. It seems like a bad arrangement > though: you either have to allocate more memory than you would like o= r > suffer the time and opportunity cost of having to do Y over. > > 3. Create an exception for flow control. This is what Google QUIC > does for its headers stream. Roberto observed that we could > alternatively create a frame type that was excluded from flow control= . > If this were used for data that had dependencies, then it would be > impossible to deadlock. It would be similarly difficult to account > for memory allocation, though if it were possible to process on > receipt, then this *might* work. We'd have to do something to addres= s > out-of-order delivery though. It's possible that the stream > abstraction is not appropriate in this case. > > 4. Block the problem at the source. It was suggested that in cases > where there is a potential dependency, then it can't be a problem if > the transport refused to accept data that it didn't have flow control > credit for. Writes to the transport would consume flow control credi= t > immediately. That way applications would only be able to write X if > there was a chance that it would be delivered. Applications that hav= e > ordering requirements can ensure that Y is written after X is accepte= d > by the transport and thereby avoid the deadlock. Writes might block > rather than fail, if the API wasn't into the whole non-blocking I/O > thing. The transport might still have to buffer X for other reasons, > like congestion control, but it can guarantee that flow control isn't > going to block delivery. > > > ## My Preference > > Right now, I'm inclined toward option 4. Option 1 seems a little too > much of a constraint. Protocols create this sort of inter-dependency > naturally. > > There's a certain purity in having the flow control exert back > pressure all the way to the next layer up. Not being able to build a > transport with unconstrained writes is potentially creating > undesirable externalities on transport users. Now they have to worry > about flow control as well. Personally, I'm inclined to say that thi= s > is something that application protocols and their users should be > exposed to. We've seen with the JS streams API that it's valuable to > have back pressure available at the application layer and also how it > is possible to do that relatively elegantly. > > I'm almost certain that I haven't thought about all the potential > alternatives. I wonder if there isn't some experience with this > problem in SCTP that might lend some insights. > > > > --f403045ed28c3ad179056289af88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Roberto,

    I'm not convinced that we = need something as heavy-weight as this... specifically, flow control so far= has been in the receiver's control, which is also the thing that owns = the resource it is trying to limit exhaustion of. This moves it out to the = sender, which would require a receiver to now commit memory based on what a= sender believes is important. Reasoning about this seems non-trivial. I wo= rry about how all this degree of freedom will get abused, and potential sha= rp edges.

    If we can ensure priority consumption of= the shared resource, that seems adequate to resolve the problem on hand. D= o you think something more is required?

    - jana

    On Wed, Ja= n 10, 2018 at 12:26 PM, Roberto Peon <fenix@fb.com> wrote:
    Another option:
    Allow a flow-control =E2=80=98override=E2=80=99 which allows a receiver to = state that they really want data on a particular stream, and ignore the glo= bal flow control for this.

    How you=E2=80=99d do it:
    A receiver can send a flow-control override for a stream. This includes the= stream id to which the global window temporarily does not apply, the recei= ver=E2=80=99s current stream flow-control offset, and the offset the receiv= er would wish to be able to receive.
    A receiver must continue to (re)send the override (i.e. rexmit) until it is= ack=E2=80=99d. It cannot send other flow-control for that stream until the= override is ack=E2=80=99d.
    Thus:
    =C2=A0 global-flow-control-override: <stream-id> <current-flow-con= trol-offset>, <override-flow-control-offset>

    The sender (which receives the override) credits the global flow control wi= th the difference between the data sent beyond the receivers currently-know= n flow-control offset upon receipt of the override.
    This synchronizes the global state between the receiver and the sender.
    The sender can then send the data on the stream (without touching any other= flow control data).

    Why:
    This allows for a receiver to resolve priority inversions which would other= wise lead to deadlock, even when the data/dep leading to this was not known= to the transport. This extends beyond such issues beyond just header compr= ession.

    Since the global flow-control exists to protect the app from resource exhau= stion, this poses no additional risk to the application.
    Simply increasing the global flow control provides less strong guarantees= =E2=80=94any stream might consume it, which doesn=E2=80=99t resolve the dep= inversion. Rejiggering priorities can help to resolve this, but would requ= ire the sender to send priorities to the client, which is problematic w.r.t= .races and just a web of ick.

    Having a custom frame type is also a less strong guarantee as it requires t= he knowledge that the dep exists to be present at the time of sending, whic= h is often impossible.

    -=3DR

    On 1/9/18, 10:17 PM, "QUIC on behalf of Martin Thomson" <quic-bounces@ietf.org<= /a> on behalf of martin.thomson@gmail.com> wrote:

    =C2=A0 =C2=A0 Building a complex application protocol on top of QUIC contin= ues to
    =C2=A0 =C2=A0 produce surprises.

    =C2=A0 =C2=A0 Today in the header compression design team meeting we discus= sed a
    =C2=A0 =C2=A0 deadlocking issue that I think warrants sharing with the larg= er group.
    =C2=A0 =C2=A0 This has implications for how people build a QUIC transport l= ayer.=C2=A0 It
    =C2=A0 =C2=A0 might need changes to the API that is exposed by that layer.<= br>
    =C2=A0 =C2=A0 This isn't really that new, but I don't think we'= ve properly addressed
    =C2=A0 =C2=A0 the problem.


    =C2=A0 =C2=A0 ## The Basic Problem

    =C2=A0 =C2=A0 If a protocol creates a dependency between streams, there is = a
    =C2=A0 =C2=A0 potential for flow control to deadlock.

    =C2=A0 =C2=A0 Say that I send X on stream 3 and Y on stream 7.=C2=A0 Proces= sing Y
    =C2=A0 =C2=A0 requires that X is processed first.

    =C2=A0 =C2=A0 X cannot be sent due to flow control but Y is sent.=C2=A0 Thi= s is always
    =C2=A0 =C2=A0 possible even if X is appropriately prioritized.=C2=A0 The re= ceiver then
    =C2=A0 =C2=A0 leaves Y in its receive buffer until X is received.

    =C2=A0 =C2=A0 The receiver cannot give flow control credit for consuming Y = because
    =C2=A0 =C2=A0 it can't consume Y until X is sent.=C2=A0 But the sender = needs flow control
    =C2=A0 =C2=A0 credit to send X.=C2=A0 We are deadlocked.

    =C2=A0 =C2=A0 It doesn't matter whether the stream or connection flow c= ontrol is
    =C2=A0 =C2=A0 causing the problem, either produces the same result.

    =C2=A0 =C2=A0 (To give some background on this, we were considering a prefa= ce to
    =C2=A0 =C2=A0 header blocks that identified the header table state that was=
    =C2=A0 =C2=A0 necessary to process the header block.=C2=A0 This would allow= for
    =C2=A0 =C2=A0 concurrent population of the header table and sending message= that
    =C2=A0 =C2=A0 depended on the header table state that is under construction= .=C2=A0 A
    =C2=A0 =C2=A0 receiver would read the identifier and then leave the remaind= er of the
    =C2=A0 =C2=A0 header block in the receive buffer until the header table was= ready.)


    =C2=A0 =C2=A0 ## Options

    =C2=A0 =C2=A0 It seems like there are a few decent options for managing thi= s.=C2=A0 These
    =C2=A0 =C2=A0 are what occurred to me (there are almost certainly more opti= ons):

    =C2=A0 =C2=A0 1. Don't do that.=C2=A0 We might concede in this case tha= t seeking the
    =C2=A0 =C2=A0 incremental improvement to compression efficiency isn't w= orth the
    =C2=A0 =C2=A0 risk.=C2=A0 That is, we might make a general statement that t= his sort of
    =C2=A0 =C2=A0 inter-stream blocking is a bad idea.

    =C2=A0 =C2=A0 2. Force receivers to consume data or reset streams in the ca= se of
    =C2=A0 =C2=A0 unfulfilled dependencies.=C2=A0 The former seems like it migh= t be too much
    =C2=A0 =C2=A0 like magical thinking, in the sense that it requires that rec= eivers
    =C2=A0 =C2=A0 conjure more memory up, but if the receiver were required to = read Y
    =C2=A0 =C2=A0 and release the flow control credit, then all would be fine.= =C2=A0 For
    =C2=A0 =C2=A0 instance, we could require that the receiver reset a stream i= f it
    =C2=A0 =C2=A0 couldn't read and handle data.=C2=A0 It seems like a bad = arrangement
    =C2=A0 =C2=A0 though: you either have to allocate more memory than you woul= d like or
    =C2=A0 =C2=A0 suffer the time and opportunity cost of having to do Y over.<= br>
    =C2=A0 =C2=A0 3. Create an exception for flow control.=C2=A0 This is what G= oogle QUIC
    =C2=A0 =C2=A0 does for its headers stream.=C2=A0 Roberto observed that we c= ould
    =C2=A0 =C2=A0 alternatively create a frame type that was excluded from flow= control.
    =C2=A0 =C2=A0 If this were used for data that had dependencies, then it wou= ld be
    =C2=A0 =C2=A0 impossible to deadlock.=C2=A0 It would be similarly difficult= to account
    =C2=A0 =C2=A0 for memory allocation, though if it were possible to process = on
    =C2=A0 =C2=A0 receipt, then this *might* work.=C2=A0 We'd have to do so= mething to address
    =C2=A0 =C2=A0 out-of-order delivery though.=C2=A0 It's possible that th= e stream
    =C2=A0 =C2=A0 abstraction is not appropriate in this case.

    =C2=A0 =C2=A0 4. Block the problem at the source.=C2=A0 It was suggested th= at in cases
    =C2=A0 =C2=A0 where there is a potential dependency, then it can't be a= problem if
    =C2=A0 =C2=A0 the transport refused to accept data that it didn't have = flow control
    =C2=A0 =C2=A0 credit for.=C2=A0 Writes to the transport would consume flow = control credit
    =C2=A0 =C2=A0 immediately.=C2=A0 That way applications would only be able t= o write X if
    =C2=A0 =C2=A0 there was a chance that it would be delivered.=C2=A0 Applicat= ions that have
    =C2=A0 =C2=A0 ordering requirements can ensure that Y is written after X is= accepted
    =C2=A0 =C2=A0 by the transport and thereby avoid the deadlock.=C2=A0 Writes= might block
    =C2=A0 =C2=A0 rather than fail, if the API wasn't into the whole non-bl= ocking I/O
    =C2=A0 =C2=A0 thing.=C2=A0 The transport might still have to buffer X for o= ther reasons,
    =C2=A0 =C2=A0 like congestion control, but it can guarantee that flow contr= ol isn't
    =C2=A0 =C2=A0 going to block delivery.


    =C2=A0 =C2=A0 ## My Preference

    =C2=A0 =C2=A0 Right now, I'm inclined toward option 4. Option 1 seems a= little too
    =C2=A0 =C2=A0 much of a constraint.=C2=A0 Protocols create this sort of int= er-dependency
    =C2=A0 =C2=A0 naturally.

    =C2=A0 =C2=A0 There's a certain purity in having the flow control exert= back
    =C2=A0 =C2=A0 pressure all the way to the next layer up.=C2=A0 Not being ab= le to build a
    =C2=A0 =C2=A0 transport with unconstrained writes is potentially creating =C2=A0 =C2=A0 undesirable externalities on transport users.=C2=A0 Now they = have to worry
    =C2=A0 =C2=A0 about flow control as well.=C2=A0 Personally, I'm incline= d to say that this
    =C2=A0 =C2=A0 is something that application protocols and their users shoul= d be
    =C2=A0 =C2=A0 exposed to.=C2=A0 We've seen with the JS streams API that= it's valuable to
    =C2=A0 =C2=A0 have back pressure available at the application layer and als= o how it
    =C2=A0 =C2=A0 is possible to do that relatively elegantly.

    =C2=A0 =C2=A0 I'm almost certain that I haven't thought about all t= he potential
    =C2=A0 =C2=A0 alternatives.=C2=A0 I wonder if there isn't some experien= ce with this
    =C2=A0 =C2=A0 problem in SCTP that might lend some insights.




    --f403045ed28c3ad179056289af88-- From nobody Thu Jan 11 16:55:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED34126C22 for ; Thu, 11 Jan 2018 16:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5GOr1sdtoHOx for ; Thu, 11 Jan 2018 16:55:12 -0800 (PST) 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 15E77126579 for ; Thu, 11 Jan 2018 16:55:12 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C0qIq7003274; Fri, 12 Jan 2018 00:55:08 GMT 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=AbbtmnwWnLtZ+0K8JjLPGV51P/IqHBo0xrhQ2CjUILM=; b=T61ZDvldjmzVRxqBuQ0NWv4Ljtqdx8WwULCA2R7Enq50Ba+pfzzicgXJVTZ8FnNyT+IO ZtqzY0IbhyH+MG9yPKFhUqAf6e0V1GQGFxsvqzjj/vqVXD3E05pun6pFz54O3LjgmKQw MIB5HCsjbuNPjy1/tT+UuMXT7cPN2/p9Hjhc6qtzEtSxssgVGxMIzOttzszYp0njKTr2 ZElFxVPyFyijcuxOZhbOi8mF5MBhltciw2Jo9t8xUjos7POWwIG/TzhAJZshxNhTQQjz d/m/h8sOsYYhftxq+faKQFsoBiptFOJfa5AF1gKGo/KJciC5RCn4PsVd6wCqS6wSxCD6 nQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2fda9fhmn7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 00:55:08 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0C0oqiZ025981; Thu, 11 Jan 2018 19:55:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2fd6pcpnr0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 19:55:06 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 Jan 2018 19:55:05 -0500 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, 11 Jan 2018 19:55:04 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev , IETF QUIC WG Subject: RE: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizIxs65b7ysujkqedmh6APARjaNvVjxAgABe4YD//7N2cA== Date: Fri, 12 Jan 2018 00:55:03 +0000 Message-ID: <1bf50145082642f1add41595c73ec4a1@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.88] Content-Type: multipart/alternative; boundary="_000_1bf50145082642f1add41595c73ec4a1usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=981 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120009 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=932 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120010 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 00:55:15 -0000 --_000_1bf50145082642f1add41595c73ec4a1usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgaWRlYSBpcyB0aGF0IHRoZSBrZXkgdXNlZCB0byBlbmNyeXB0IGNvbm5lY3Rp b24gSUQgaXMga25vd24gdG8gYm90aCB0aGUgc2VydmVyIGFuZCB0aGUgcm91dGVyLiAgVGhhdCBr ZXkgd291bGQgbmVlZCB0byBiZSByb3RhdGVkIHBlcmlvZGljYWxseSwgYW5kIHRoZSByb3V0ZXIg d291bGQgbmVlZCB0byB1bmRlcnN0YW5kIHdoaWNoIGtleSB3YXMgdXNlZCBmb3IgdGhpcyBwYXJ0 aWN1bGFyIGNvbm5lY3Rpb24sIGJ1dCB0aGF0IGNhbiBiZSBzb2x2ZWQuDQoNCkZyb206IE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA3OjI1IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGls dWJhc2hlQGFrYW1haS5jb20+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT47 IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBJbmNyZWFzaW5nIFFV SUMgY29ubmVjdGlvbiBJRCBzaXplDQoNCkFjdHVhbGx5LCBvbiBlbmNyeXB0aW9uIG9mIGNvbm5l Y3Rpb24gSUQsIHRoaXMgaXMgbm90IHNvIHNpbXBsZS4NCg0KV2UgbXVzdCBhc3N1bWUgdGhlcmUg aXMgb25seSBhIHNpbmdsZSBrZXkgZm9yIG1hbnkgY29ubmVjdGlvbnMgYmVjYXVzZSB0aGUgcm91 dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5IGV4Y2hhbmdlLiBUaGlzIHVuaXF1ZSB2YWx1ZSBvciBj b3VudGVyIHVzZWQgZm9yIGVuY3J5cHRpbmcgYSBzaW5nbGUgYmxvY2sgY2Fubm90IGJlIHRoZSBz YW1lIGZvciB0d28gZGlmZmVyZW50IGNvbm5lY3Rpb25zIElE4oCZcywgYnV0IGl0IGNhbiBiZSBw dWJsaWMuIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJlIHN0b3JlZCBpbiB0aGUgcGFja2V0IGhl YWRlci4gQW5kLCBhcyBpdCB0dXJucyBvdXQsIHJhbmRvbSBjb25uZWN0aW9uIElEIGNob3NlbiBi eSBhIHRydXN0ZWQgc291cmNlLCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBhIHVuaXF1ZSB2YWx1ZS4g QnV0IHRoZW4gaXQgbXVzdCBiZSB1c2VkIHRvIGVuY3J5cHQgYW5kL29yIGF1dGhlbnRpY2F0ZSBz b21ldGhpbmcgZWxzZSBjYXJyeWluZyB0aGUgYWN0dWFsIHJvdXRpbmcgaW5mb3JtYXRpb24uIFNv IG5vdyB5b3Ugc3RhcnQgdG8gcmVhbGx5IG5lZWQgc29tZSBleHRyYSBwYXlsb2FkLg0KDQpBbHRl cm5hdGl2ZWx5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGlzIGVudGlyZWx5IHJhbmRvbSBzdWNo IGFzIGNvbnRlbnQgaGFzaGVkIHJvdXRpbmcuIFRoZW4geW91IG9ubHkgbmVlZCB0byBhdXRoZW50 aWNhdGUgdGhlIHJvdXRpbmcgZGF0YS4gWW91IGNhbiBkbyB0aGF0IHdpdGggYSBITUFDLCBhbmQg Q01BQyBjb3VsZCBwcm9iYWJseSBhbHNvIHdvcmsuIFRoZSBhZGRpdGlvbmFsIGJlbmVmaXQgaXMg dGhhdCB5b3UgY2FuIHByb2JhYmx5IGdldCBhd2F5IHdpdGggNjQtYml0cyBmb3IgYWxsIHJvdXRp bmcgaW5mb3JtYXRpb24gcG9zc2libHkgaW5jbHVkaW5nIHRoZSBhdXRoIHRhZy4gU2F5IDQ4IGJp dHMgb2Ygcm91dGluZyBkYXRhIGFuZCAxNiBiaXRzIG9mIGF1dGggdGFnLg0KDQpLaW5kIFJlZ2Fy ZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gMTIgSmFudWFyeSAyMDE4IGF0 IDAwLjU3LjIxLCBMdWJhc2hldiwgSWdvciAoaWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1 YmFzaGVAYWthbWFpLmNvbT4pIHdyb3RlOg0KSSBhbSBpbnRlcmVzdGVkIGluIGV4cGxvcmluZyB0 aGlzIHByb3Bvc2FsLCBzaW5jZSBpdCBhbGxvd3MgZm9yIG1vcmUgZmxleGlibGUgc2NoZW1lcyBv ZiBlbmNvZGluZyByb3V0aW5nIG1ldGFkYXRhIGFuZCBhIGNoZWNrc3VtLiAgSSB3b3VsZCBhbHNv IGxpa2UgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBpbiBhIHBh Y2tldCBoZWFkZXIsIHRob3VnaCwgc2luY2UgaXQgZ3JlYXRseSBzaW1wbGlmaWVzIHRoZSBpbXBs ZW1lbnRhdGlvbi4NCg0KDQogICogICBJZ29yDQpGcm9tOiBWaWN0b3IgVmFzaWxpZXYgW21haWx0 bzp2YXNpbHZ2QGdvb2dsZS5jb208bWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbT5dDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWlj QGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IEluY3JlYXNpbmcgUVVJ QyBjb25uZWN0aW9uIElEIHNpemUNCg0KSGkgZXZlcnlvbmUsDQoNCkluIHRoZSBjdXJyZW50IHZl cnNpb24gb2YgUVVJQywgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBpcyBmaXhlZCB0byBiZSBhIDY0 LWJpdCBvcGFxdWUgYmxvYiwgYW5kIHRoYXQgaXMgc2V0IGFzIGFuIGludmFyaWFudCBpbiB0aGUg cHJvdG9jb2wuDQoNCknigJl2ZSBsb29rZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2luZyBhIGNv bm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBpbnRvIGl0 ICh0byBwcm92aWRlIHN0YWJpbGl0eSBvZiB0aGUgY29ubmVjdGlvbiBpbiBjYXNlIG9mIGxvYWQg YmFsYW5jaW5nIGNoYW5nZXMsIGVzcGVjaWFsbHkgQkdQIGZsYXBzIGZvciBhbnljYXN0IElQcyks IGFuZCBoYXZlIGNoYXR0ZWQgYWJvdXQgdGhpcyB3aXRoIG90aGVyIHBlb3BsZSBJIGtuZXcgd2Vy ZSBpbnRlcmVzdGVkIGluIHRoaXMuICBJdCBzZWVtcyBsaWtlIDY0IGJpdHMgbWlnaHQgYmUgdG9v IHNtYWxsIGZvciB0aGlzIHB1cnBvc2UsIGFuZCB3ZSBtaWdodCB3YW50IHRvIGxlYXZlIGFuIG9w cG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBzaXplLg0KDQpUaGUgYmFzaWMg aWRlYSBpcyB0aGF0IHlvdSB3YW50IHRvIGJlIGFibGUgdG86DQoNCiAgMS4gIFN0b3JlIHNvbWUg cm91dGluZyBtZXRhZGF0YSBpbiB0aGUgY29ubmVjdGlvbiBJRC4NCiAgMi4gIEhhdmUgc29tZSBl bnRyb3B5IHRoYXQgYWxsb3dzIGRpc3Rpbmd1aXNoIHVzZXJzIHdpdGggaWRlbnRpY2FsIHJvdXRp bmcgbWV0YWRhdGEuDQogIDMuICBIYXZlIGEgY2hlY2tzdW0gdG8gZW5zdXJlIHRoZSB2YWxpZGl0 eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uDQogIDQuICBFbmNyeXB0IHRoZSBpbmZvcm1hdGlvbiBh Ym92ZSB0byBwcmV2ZW50IGRpc2Nsb3NpbmcgdGhlIHJvdXRlIGluZm9ybWF0aW9uIGFuZCBhbGxv dyBnZW5lcmF0aW5nIHVuY29ycmVsYXRhYmxlIGNvbm5lY3Rpb24gSURzLg0KVGhlcmUgYXJlIHR3 byB1bmRlcmx5aW5nIGlzc3VlcyBoZXJlLiAgVGhlIGZpcnN0IHByb2JsZW0gaXMgdGhhdCBhbGwg b2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJpdHMsIGFuZCB5b3UgaGF2ZSB0byBz ZXJpb3VzbHkgY29tcHJvbWlzZSBvbiB0aGUgc3RyZW5ndGggb2YgdGhlIGNoZWNrc3VtICh3aGlj aCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ugd2FudCBpdCB0byBiZSBhIE1BQyByYXRoZXIgdGhh biBhIGNoZWNrc3VtKS4gIFRoZSBzZWNvbmQgcHJvYmxlbSBpcyB0aGF0IGVuY3J5cHRpbmcgNjQt Yml0IHZhbHVlcyBmYXN0IGlzIGFjdHVhbGx5IGZhaXJseSBoYXJkIHNpbmNlIHRoZSBibG9jayBj aXBoZXJzIGVhc2lseSBhdmFpbGFibGUgaW4gaGFyZHdhcmUgaGF2ZSAxMjgtYml0IGJsb2NrIHNp emUsIGFuZCB0aGUgcGVyZm9ybWFuY2UgcmVxdWlyZW1lbnRzIG9uIGxvYWQgYmFsYW5jZXJzIGFy ZSB0aWdodGVyIHRoYW4gb24gc2VydmVycy4NCg0KSW4gb3RoZXIgd29yZHMsIGhhdmluZyBhIDEy OC1iaXQgY29ubmVjdGlvbiBJRCBwcm92aWRlcyBmb3IgYW4gZWFzeSBzZWN1cmUgd2F5IHRvIGdl bmVyYXRlIHVubGlua2FibGUgY29ubmVjdGlvbiBJRHMgb24gbWlncmF0aW9uLg0KDQpTbywgdGhl IHByb2JsZW0gd2XigJlyZSB0cnlpbmcgdG8gc29sdmUgaXMgdGhhdCB0aGUgY29ubmVjdGlvbiBJ RCBpcyB0b28gc21hbGwuICBUaGVyZSBhcmUgdHdvIHF1ZXN0aW9ucyBJIGJlbGlldmUgdGhlIHdv cmtpbmcgZ3JvdXAgc2hvdWxkIGFuc3dlciBhdCB0aGlzIHBvaW50Og0KDQogIDEuICBEbyB3ZSB3 YW50IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtIGF0IHRoaXMgcG9pbnQgaW4gc3RhbmRhcmRpemF0 aW9uIHByb2Nlc3M/DQogIDIuICBJZiB3ZSBkb27igJl0IGFkZHJlc3MgdGhpcyBwcm9ibGVtIHJp Z2h0IG5vdywgaG93IGRvIHdlIHN0cnVjdHVyZSB0aGUgc3RhbmRhcmQgaW4gYSB3YXkgdGhhdCB3 ZSBjYW4gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIGluIHRoZSBmdXR1cmU/DQpUaGVyZSBhcmUg bXVsdGlwbGUgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBtYWtpbmcgY29ubmVjdGlvbiBJ RCBsYXJnZXIuICBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEgYml0IHRvIHRoZSDigJxvbWl0IGNv bm5lY3Rpb24gSUTigJ0gZmllbGQgdG8gYWxsb3cgMTI4LWJpdCBjb25uZWN0aW9uIElEcy4gIEFu b3RoZXIgYXBwcm9hY2ggaXMgdG8gYWxsb3cgY29ubmVjdGlvbiBJRCBzaXplIHRvIGJlIGV4cGxp Y2l0bHkgc3BlY2lmaWVkIGJ5IHRoZSBzZXJ2ZXIsIGFuZCB0aGVuIGFzc3VtZSB0aGF0IHRoZSBs b2FkIGJhbGFuY2VyIGtub3dzIHRoYXQgc2l6ZSBhbmQgbm8gb25lIGVsc2Ugb24gdGhlIHBhdGgg bmVlZHMgdG8gcmVhZCBpdC4NCg0KVGhlcmXigJlzIGFsc28gYSBxdWVzdGlvbiBvZiBob3cgbXVj aCBvZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVib3hlcyAoZXhjbHVkaW5nIGxvYWQgYmFsYW5j ZXJzIGFuZCBvdGhlciBib3hlcyBvd25lZCBieSB0aGUgc2FtZSBlbnRpdHkgYXMgZWl0aGVyIGNs aWVudCBvciBzZXJ2ZXIpIG5lZWQgdG8ga25vdy4gIFdlIGNvdWxkIGdvIGZvciBib3RoIOKAnG1p ZGRsZWJveGVzIHNob3VsZCBiZSBhbHdheXMgYWJsZSB0byByZWFkIHRoZSBlbnRpcmUgSUTigJ0g YW5kIOKAnG1pZGRsZWJveGVzIHNob3VsZCBub3QgcmVhZCBjb25uZWN0aW9uIElEcyBhdCBhbGwg b3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGFsc28gYSByb29tIGZvciBtb3JlIGZs ZXhpYmxlIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1pZGRsZWJveGVzIGFsd2F5cyBnZXQgZmlyc3Qg NjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRvIGRpc3Rpbmd1aXNoIGNvbm5l Y3Rpb25z4oCdLg0KDQogIC0tIFZpY3Rvci4NCg== --_000_1bf50145082642f1add41595c73ec4a1usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRp di5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTM1MDMyMDU5Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczo3Njc4MzAzNTY7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjY5NzAyNTY2Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczo5NDA1NzkxODY7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6 NjQzMDQ5NzI4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDcyMDk4NjA0O30NCkBsaXN0IGwy OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTg4ODI5NDI1OTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTY4NDE4Njc4MCA4ODcxNTA5MTggNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0 aGUgaWRlYSBpcyB0aGF0IHRoZSBrZXkgdXNlZCB0byBlbmNyeXB0IGNvbm5lY3Rpb24gSUQgaXMg a25vd24gdG8gYm90aCB0aGUgc2VydmVyIGFuZCB0aGUgcm91dGVyLiZuYnNwOyBUaGF0IGtleSB3 b3VsZCBuZWVkIHRvIGJlIHJvdGF0ZWQgcGVyaW9kaWNhbGx5LCBhbmQgdGhlIHJvdXRlciB3b3Vs ZCBuZWVkIHRvIHVuZGVyc3RhbmQgd2hpY2gga2V5IHdhcyB1c2VkIGZvciB0aGlzIHBhcnRpY3Vs YXIgY29ubmVjdGlvbiwNCiBidXQgdGhhdCBjYW4gYmUgc29sdmVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNzoyNSBQTTxicj4NCjxi PlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBWaWN0 b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xlLmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7 cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEluY3JlYXNpbmcgUVVJ QyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFjdHVh bGx5LCBvbiBlbmNyeXB0aW9uIG9mIGNvbm5lY3Rpb24gSUQsIHRoaXMgaXMgbm90IHNvIHNpbXBs ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2UgbXVzdCBhc3N1bWUgdGhl cmUgaXMgb25seSBhIHNpbmdsZSBrZXkgZm9yIG1hbnkgY29ubmVjdGlvbnMgYmVjYXVzZSB0aGUg cm91dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5IGV4Y2hhbmdlLiBUaGlzIHVuaXF1ZSB2YWx1ZSBv ciBjb3VudGVyIHVzZWQgZm9yIGVuY3J5cHRpbmcgYSBzaW5nbGUNCiBibG9jayBjYW5ub3QgYmUg dGhlIHNhbWUgZm9yIHR3byBkaWZmZXJlbnQgY29ubmVjdGlvbnMgSUTigJlzLCBidXQgaXQgY2Fu IGJlIHB1YmxpYy4gVGhpcyBtZWFucyB0aGF0IGl0IG11c3QgYmUgc3RvcmVkIGluIHRoZSBwYWNr ZXQgaGVhZGVyLiBBbmQsIGFzIGl0IHR1cm5zIG91dCwgcmFuZG9tIGNvbm5lY3Rpb24gSUQgY2hv c2VuIGJ5IGEgdHJ1c3RlZCBzb3VyY2UsIGNhbiBiZSB1c2VkIGZvciBzdWNoIGEgdW5pcXVlIHZh bHVlLiBCdXQgdGhlbg0KIGl0IG11c3QgYmUgdXNlZCB0byBlbmNyeXB0IGFuZC9vciBhdXRoZW50 aWNhdGUgc29tZXRoaW5nIGVsc2UgY2FycnlpbmcgdGhlIGFjdHVhbCByb3V0aW5nIGluZm9ybWF0 aW9uLiBTbyBub3cgeW91IHN0YXJ0IHRvIHJlYWxseSBuZWVkIHNvbWUgZXh0cmEgcGF5bG9hZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QWx0ZXJuYXRpdmVseSB0aGUgcm91 dGluZyBpbmZvcm1hdGlvbiBpcyBlbnRpcmVseSByYW5kb20gc3VjaCBhcyBjb250ZW50IGhhc2hl ZCByb3V0aW5nLiBUaGVuIHlvdSBvbmx5IG5lZWQgdG8gYXV0aGVudGljYXRlIHRoZSByb3V0aW5n IGRhdGEuIFlvdSBjYW4gZG8gdGhhdCB3aXRoIGEgSE1BQywNCiBhbmQgQ01BQyBjb3VsZCBwcm9i YWJseSBhbHNvIHdvcmsuIFRoZSBhZGRpdGlvbmFsIGJlbmVmaXQgaXMgdGhhdCB5b3UgY2FuIHBy b2JhYmx5IGdldCBhd2F5IHdpdGggNjQtYml0cyBmb3IgYWxsIHJvdXRpbmcgaW5mb3JtYXRpb24g cG9zc2libHkgaW5jbHVkaW5nIHRoZSBhdXRoIHRhZy4gU2F5IDQ4IGJpdHMgb2Ygcm91dGluZyBk YXRhIGFuZCAxNiBiaXRzIG9mIGF1dGggdGFnLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxNTcxNjEzNzIwMzMzMzg4OCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5N aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+T24gMTIgSmFudWFyeSAyMDE4IGF0IDAwLjU3LjIxLCBMdWJhc2hldiwgSWdvciAoPGEgaHJl Zj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+KSB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gaW50ZXJlc3RlZCBpbiBl eHBsb3JpbmcgdGhpcyBwcm9wb3NhbCwgc2luY2UgaXQgYWxsb3dzIGZvciBtb3JlIGZsZXhpYmxl IHNjaGVtZXMgb2YgZW5jb2Rpbmcgcm91dGluZyBtZXRhZGF0YQ0KIGFuZCBhIGNoZWNrc3VtLiZu YnNwOyBJIHdvdWxkIGFsc28gbGlrZSB0byBiZSBleHBsaWNpdCBhYm91dCB0aGUgY29ubmVjdGlv biBJRCBzaXplIGluIGEgcGFja2V0IGhlYWRlciwgdGhvdWdoLCBzaW5jZSBpdCBncmVhdGx5IHNp bXBsaWZpZXMgdGhlIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J Z29yPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4g VmljdG9yIFZhc2lsaWV2IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNv bSI+dmFzaWx2dkBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0 OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgZXZlcnlvbmUsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGN1cnJlbnQg dmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVjdGlvbiBJRCBzaXplIGlzIGZpeGVkIHRvIGJlIGEg NjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhhdCBpcyBzZXQgYXMNCiBhbiBpbnZhcmlhbnQgaW4g dGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPknigJl2ZSBsb29rZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2luZyBhIGNvbm5l Y3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBpbnRvIGl0ICh0 byBwcm92aWRlDQogc3RhYmlsaXR5IG9mIHRoZSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgbG9hZCBi YWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBCR1AgZmxhcHMgZm9yIGFueWNhc3QgSVBzKSwg YW5kIGhhdmUgY2hhdHRlZCBhYm91dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkga25ldyB3ZXJl IGludGVyZXN0ZWQgaW4gdGhpcy4mbmJzcDsgSXQgc2VlbXMgbGlrZSA2NCBiaXRzIG1pZ2h0IGJl IHRvbyBzbWFsbCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudA0KIHRvIGxlYXZl IGFuIG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBzaXplLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBiYXNpYyBp ZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0bzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlN0b3JlIHNvbWUgcm91dGluZyBtZXRhZGF0YSBpbiB0aGUgY29ubmVjdGlv biBJRC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5I YXZlIHNvbWUgZW50cm9weSB0aGF0IGFsbG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50 aWNhbCByb3V0aW5nIG1ldGFkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkhhdmUgYSBjaGVja3N1bSB0byBlbnN1cmUgdGhlIHZhbGlkaXR5IG9m IHJvdXRpbmcgaW5mb3JtYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5FbmNyeXB0IHRoZSBpbmZvcm1hdGlvbiBhYm92ZSB0byBwcmV2ZW50IGRp c2Nsb3NpbmcgdGhlIHJvdXRlIGluZm9ybWF0aW9uIGFuZCBhbGxvdyBnZW5lcmF0aW5nIHVuY29y cmVsYXRhYmxlIGNvbm5lY3Rpb24gSURzLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC9vbD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZXJlIGFyZSB0d28gdW5kZXJseWluZyBpc3N1ZXMgaGVyZS4mbmJzcDsgVGhlIGZpcnN0IHByb2Js ZW0gaXMgdGhhdCBhbGwgb2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJpdHMsIGFu ZA0KIHlvdSBoYXZlIHRvIHNlcmlvdXNseSBjb21wcm9taXNlIG9uIHRoZSBzdHJlbmd0aCBvZiB0 aGUgY2hlY2tzdW0gKHdoaWNoIGlzIGJhZCBlc3BlY2lhbGx5IGlmIHlvdSB3YW50IGl0IHRvIGJl IGEgTUFDIHJhdGhlciB0aGFuIGEgY2hlY2tzdW0pLiZuYnNwOyBUaGUgc2Vjb25kIHByb2JsZW0g aXMgdGhhdCBlbmNyeXB0aW5nIDY0LWJpdCB2YWx1ZXMgZmFzdCBpcyBhY3R1YWxseSBmYWlybHkg aGFyZCBzaW5jZSB0aGUgYmxvY2sgY2lwaGVycyBlYXNpbHkgYXZhaWxhYmxlDQogaW4gaGFyZHdh cmUgaGF2ZSAxMjgtYml0IGJsb2NrIHNpemUsIGFuZCB0aGUgcGVyZm9ybWFuY2UgcmVxdWlyZW1l bnRzIG9uIGxvYWQgYmFsYW5jZXJzIGFyZSB0aWdodGVyIHRoYW4gb24gc2VydmVycy4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5JbiBvdGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElEIHByb3ZpZGVz IGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5saW5rYWJsZSBjb25uZWN0aW9u DQogSURzIG9uIG1pZ3JhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5TbywgdGhlIHByb2JsZW0gd2XigJlyZSB0cnlpbmcgdG8gc29sdmUg aXMgdGhhdCB0aGUgY29ubmVjdGlvbiBJRCBpcyB0b28gc21hbGwuJm5ic3A7IFRoZXJlIGFyZSB0 d28gcXVlc3Rpb25zIEkgYmVsaWV2ZQ0KIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhbnN3ZXIg YXQgdGhpcyBwb2ludDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wg c3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRvIHdlIHdh bnQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBzdGFuZGFyZGl6YXRp b24gcHJvY2Vzcz88bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JZiB3ZSBkb27igJl0IGFkZHJlc3MgdGhpcyBwcm9ibGVtIHJpZ2h0IG5vdywgaG93IGRv IHdlIHN0cnVjdHVyZSB0aGUgc3RhbmRhcmQgaW4gYSB3YXkgdGhhdCB3ZSBjYW4gZXh0ZW5kIHRo ZSBjb25uZWN0aW9uIElEIGluIHRoZSBmdXR1cmU/PG86cD48L286cD48L3NwYW4+PC9saT48L29s Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgbWFraW5n IGNvbm5lY3Rpb24gSUQgbGFyZ2VyLiZuYnNwOyBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEgYml0 IHRvIHRoZQ0KIOKAnG9taXQgY29ubmVjdGlvbiBJROKAnSBmaWVsZCB0byBhbGxvdyAxMjgtYml0 IGNvbm5lY3Rpb24gSURzLiZuYnNwOyBBbm90aGVyIGFwcHJvYWNoIGlzIHRvIGFsbG93IGNvbm5l Y3Rpb24gSUQgc2l6ZSB0byBiZSBleHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUgc2VydmVyLCBh bmQgdGhlbiBhc3N1bWUgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0IHNpemUgYW5k IG5vIG9uZSBlbHNlIG9uIHRoZSBwYXRoIG5lZWRzIHRvIHJlYWQgaXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmXigJlzIGFsc28gYSBx dWVzdGlvbiBvZiBob3cgbXVjaCBvZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVib3hlcyAoZXhj bHVkaW5nIGxvYWQgYmFsYW5jZXJzIGFuZCBvdGhlciBib3hlcw0KIG93bmVkIGJ5IHRoZSBzYW1l IGVudGl0eSBhcyBlaXRoZXIgY2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiZuYnNwOyBX ZSBjb3VsZCBnbyBmb3IgYm90aCDigJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3YXlzIGFibGUg dG8gcmVhZCB0aGUgZW50aXJlIElE4oCdIGFuZCDigJxtaWRkbGVib3hlcyBzaG91bGQgbm90IHJl YWQgY29ubmVjdGlvbiBJRHMgYXQgYWxsIG9wdGlvbnPigJ0sIGJ1dCBJIHRoaW5rIHRoZXJl4oCZ cyBhbHNvIGEgcm9vbSBmb3IgbW9yZSBmbGV4aWJsZQ0KIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1p ZGRsZWJveGVzIGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBl bnRyb3B5IHRvIGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAtLSBWaWN0b3IuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1bf50145082642f1add41595c73ec4a1usma1exdag1mb5msgcorpak_-- From nobody Thu Jan 11 17:00:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D67E126C26 for ; Thu, 11 Jan 2018 17:00:28 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 obFN30UuzjFY for ; Thu, 11 Jan 2018 17:00:26 -0800 (PST) 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 EAC67126579 for ; Thu, 11 Jan 2018 17:00:25 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id v139so1860072ywg.4 for ; Thu, 11 Jan 2018 17:00:25 -0800 (PST) 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=gGz1SyHa8fAR3rH+9EMa6CyYRjfxIsfe5tXqOvnvA3Y=; b=lptzNUZDk50ThBjDtNdG2Y1kp1Egrqz4vivApx4CS1zr5CBSNhV8aXhz0yFsU0Z2IQ +ArqdnuTgjLXIasZ0Elxaau20nk04UzscZ0SWihNojzDicK9zTx2zfVPdMN/pG/ROf4M eEcGCIBHRfK1CWDd1rFupkx1cZzNXar3zlTSQOfgrLSAn8zSs+WsieONp+vOpGZgdRhp nhGBdvmQLBBmLAalvYffHfEmK2RNZrbA+YQdq6r0S0lhqiT2S/A7LYztzX07MdCuJyNI DrW4j1PCP/2IetUmnEclOSVM1QJZIXbKmlxDal8ki0QypCYFTSFynfEV8EWyxYZWOOoj Gc3g== 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=gGz1SyHa8fAR3rH+9EMa6CyYRjfxIsfe5tXqOvnvA3Y=; b=d2jU45LDQ7lLkcYvw6tlyv/HLeZ7oB8lbAMR3A5eXeuc7lsIlQOSo+74uqjlFaKUtG tXJsRtKTM99xAVpIkdIcDm6d5EqHUNveelHZu5ZHmi3Un8fl4F+aZf97xKc7bABSWWj8 xXe/4OCC/pnUDkc1Y8l1YzPY1US5PBiEBOtOhTl/hRoLb7oJlZPz72mPZuFHPerDo+hk 0VmsOWEITRL2gixVl8ivqBw1KEvh/4v6C1FC+onxe/jcYbBfJzQVpi9/9Ulaf8pngNJs kZXe7WszD2ONbpFHC4Gqsz6Mf8iAehfK/abUO9nPu9XdPRJuXK2e8yIVbkVuiupP1bdI IhaA== X-Gm-Message-State: AKwxytem887WcD3gMm4PitepC8t+bVgGJpVNxmB2G3YhHRXi3vVSAGRc oWIgleWg1EfbLXbcVuuB8AtX5kjHfUwaZdJFhpwGag== X-Google-Smtp-Source: ACJfBotll6jAAN5aajY1hlnFQBma6YK7FCYUKtZd5ywl8hISPTEiZJtniG+SsqD6Ayb1kGdiY1dzLAbYPZgn1DYchE4= X-Received: by 10.129.146.130 with SMTP id j124mr3076841ywg.256.1515718824368; Thu, 11 Jan 2018 17:00:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Thu, 11 Jan 2018 17:00:23 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 11 Jan 2018 17:00:23 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Roberto Peon Cc: Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114c4c101cd2a5056289cad0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:00:28 -0000 --001a114c4c101cd2a5056289cad0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Having thought about this a bit, I like the idea of encrypting CIDs. The strongest argument for me is that we really want unlinkable CIDs, and crypto is a quite simple way of generating such CIDs. Encrypted CIDs also allows for a simple solution to the problem of generating server-chosen CIDs that route back to the same server, since any structure in the plaintext is not visible in the CID that is sent on the wire. Crypto in 128 bits is readily available, making it less expensive for hardware (load balancers) to do it per packet, so using 128 bits seems like a good idea. On Thu, Jan 11, 2018 at 4:45 PM, Roberto Peon wrote: > Having the server specify the connID-size as part of the connection > setup+version negotiation would certainly be grease-y. > > A larger connID helps to solve a lot of L4<->L7 routing issues, agreed, > pre-supposing that the server always picks the new/alternate conn-ID for > the client. > > -=3DR > > > > *From: *QUIC on behalf of Victor Vasiliev < > vasilvv@google.com> > *Date: *Thursday, January 11, 2018 at 3:16 PM > *To: *IETF QUIC WG > *Subject: *Increasing QUIC connection ID size > > > > Hi everyone, > > > > In the current version of QUIC, the connection ID size is fixed to be a > 64-bit opaque blob, and that is set as an invariant in the protocol. > > > > I=E2=80=99ve looked into possibility of using a connection ID to encode t= he > specific server details into it (to provide stability of the connection i= n > case of load balancing changes, especially BGP flaps for anycast IPs), an= d > have chatted about this with other people I knew were interested in this. > It seems like 64 bits might be too small for this purpose, and we might > want to leave an opportunity to extend the connection ID size. > > > > The basic idea is that you want to be able to: > > 1. Store some routing metadata in the connection ID. > 2. Have some entropy that allows distinguish users with identical > routing metadata. > 3. Have a checksum to ensure the validity of routing information > 4. Encrypt the information above to prevent disclosing the route > information and allow generating uncorrelatable connection IDs. > > There are two underlying issues here. The first problem is that all of > this does not fit well into 64 bits, and you have to seriously compromise > on the strength of the checksum (which is bad especially if you want it t= o > be a MAC rather than a checksum). The second problem is that encrypting > 64-bit values fast is actually fairly hard since the block ciphers easily > available in hardware have 128-bit block size, and the performance > requirements on load balancers are tighter than on servers. > > > > In other words, having a 128-bit connection ID provides for an easy secur= e > way to generate unlinkable connection IDs on migration. > > > > So, the problem we=E2=80=99re trying to solve is that the connection ID i= s too > small. There are two questions I believe the working group should answer > at this point: > > 1. Do we want to address this problem at this point in standardization > process? > 2. If we don=E2=80=99t address this problem right now, how do we struc= ture the > standard in a way that we can extend the connection ID in the future? > > There are multiple ways to solve the problem of making connection ID > larger. One is to just add extra bit to the =E2=80=9Comit connection ID= =E2=80=9D field to > allow 128-bit connection IDs. Another approach is to allow connection ID > size to be explicitly specified by the server, and then assume that the > load balancer knows that size and no one else on the path needs to read i= t. > > > > There=E2=80=99s also a question of how much of connection IDs do middlebo= xes > (excluding load balancers and other boxes owned by the same entity as > either client or server) need to know. We could go for both =E2=80=9Cmid= dleboxes > should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleb= oxes should not > read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s = also a room for > more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 = bits and > they have useful entropy to distinguish connections=E2=80=9D. > > > > -- Victor. > --001a114c4c101cd2a5056289cad0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Having thought about this a bit, I like the idea of encryp= ting CIDs. The strongest argument for me is that we really want unlinkable = CIDs, and crypto is a quite simple way of generating such CIDs.=C2=A0 Encry= pted CIDs also allows for a simple solution to the problem of generating se= rver-chosen CIDs that route back to the same server, since any structure in= the plaintext is not visible in the CID that is sent on the wire.

    =
    Crypto in 128 bits is readily availabl= e, making it less expensive for hardware (load balancers) to do it per pack= et, so using 128 bits seems like a good idea.

    On Thu, Jan 11, 2018 at = 4:45 PM, Roberto Peon <fenix@fb.com> wrote:

    Having the server specify the connID-size as part of= the connection setup+version negotiation would certainly be grease-y.

    A larger connID helps to solve a lot of L4<->L7 routing issues, agree= d, pre-supposing that the server always picks the new/alternate conn-ID for= the client.

    -=3DR

    =C2=A0

    From= : QUIC <quic-bounces@ietf.org> on behalf of Victor Vasiliev <vasilvv@google.com>
    Date: Thursday, January 11, 2018 at 3:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID si= ze is fixed to be a 64-bit opaque blob, and that is set as an invariant in = the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibility of using a conn= ection ID to encode the specific server details into it (to provide stabili= ty of the connection in case of load balancing changes, especially BGP flap= s for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like= 64 bits might be too small for this purpose, and we might want to leave an= opportunity to extend the connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing meta= data.
    3. Have a checksum to ensure the validity of routing information=
    4. Encrypt the information above to prevent disclosing the route information a= nd allow generating uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The firs= t problem is that all of this does not fit well into 64 bits, and you have = to seriously compromise on the strength of the checksum (which is bad espec= ially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit value= s fast is actually fairly hard since the block ciphers easily available in = hardware have 128-bit block size, and the performance requirements on load = balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provi= des for an easy secure way to generate unlinkable connection IDs on migrati= on.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is tha= t the connection ID is too small.=C2=A0 There are two questions I believe t= he working group should answer at this point:

    1. Do we want to address this problem at this point in standardization process= ?
    2. If we don=E2=80=99t address this problem right now, how do we structure the= standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of maki= ng connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80= =9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs.=C2=A0= Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that= size and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of conne= ction IDs do middleboxes (excluding load balancers and other boxes owned by= the same entity as either client or server) need to know.=C2=A0 We could g= o for both =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read conne= ction IDs at all options=E2=80=9D, but I think there=E2=80=99s also a room = for more flexible formulations like =E2=80=9Cmiddleboxes always get first 6= 4 bits and they have useful entropy to distinguish connections=E2=80=9D.=

    =C2=A0

    =C2=A0 -- Victor.


    --001a114c4c101cd2a5056289cad0-- From nobody Thu Jan 11 17:03:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1DD12D574 for ; Thu, 11 Jan 2018 17:03:17 -0800 (PST) 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=jEOqgADj; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=C2cGqkF8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQdDc7vWf2WY for ; Thu, 11 Jan 2018 17:03:13 -0800 (PST) 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 96755126579 for ; Thu, 11 Jan 2018 17:03:13 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C0vQuv006176; Thu, 11 Jan 2018 17:03:10 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=IoB/uvzXSTk4sPbtrVtLUo1pn9FvMIk+pILaZZBy9hQ=; b=jEOqgADjTi5kqKEgcZOlAQIUeyAZLl2FaSnfqdI3wdNRycArayNhdLeqzgXBKBDhZlkh VXVbzTE7p0NAl/lt4xr7FSyQI7ImyglzvFeu6wsde36BHx6Ib6HkrSAUiL5c6IGCRQ75 NCoQSomUsoyX2z1SuE2b6x+T7YuM7FaDM2M= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fehrhg99c-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 17:03:09 -0800 Received: from NAM03-CO1-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.361.1; Thu, 11 Jan 2018 20:03:07 -0500 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=IoB/uvzXSTk4sPbtrVtLUo1pn9FvMIk+pILaZZBy9hQ=; b=C2cGqkF8KN299YSRbI90CUk49sE+xpzRXTpMdks6YeZ14Ec+E7SNsI5mThXp7PAWCSYNpPuwPE+2LTWUzPLRaQaHPIu7OlZEO6U3zmzQpcJ4cvMlpIgxpMYp+sW8AMAAxYJW321poxbaziDKuAfgBhV2fD/wddbPcOhy1xU8o0Q= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 01:02:52 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 01:02:53 +0000 From: Roberto Peon To: Jana Iyengar CC: Martin Thomson , QUIC WG Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNtCOaAgAJivQD//3yugA== Date: Fri, 12 Jan 2018 01:02:53 +0000 Message-ID: <18061ACE-08F7-4219-81E6-0B73BBC56170@fb.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:47a8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:7Xaf7/PkdWiyyfCYrPTkhUVcRte6jjasKl+Op33kiAy/NxJ6OcvwMKV0qmXDvFMYTBSvX/aTFpOz4TJhJouGtXWUUfbfjta8dWqnwX/7vspacKrI4TyqCYICmV/RBlHK/cV/9cN54uNNjO50slpO/E6dun73JPTmZx14HAcwYVe201UA+YMNLPoNaEFxCVR3Hs1tkMp1R+6gxE4Mm980rb2VvZIaCYPBwd7s+wEjWv4K2KbS3wtHKSLHkLA2LSWd; 20:BqXmqVy89FAM1dlxSoAjDM/hkJr5Jk5Gi/yMUmFlq6MqzWlUd2NTlmWv6Ncc8bpv0nM3Gn5Wcecb01JXkBFDipuqyFhXBhniLWkSZEN23mbSXf2nM/EeJ/YJgKCAqPlrBBSRL3F4bDm/6E3XdjmJJiDfcY2Sl8lNsGOTw2IkObY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 45c49279-c451-490e-1f1e-08d559583576 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020074)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189; x-ms-traffictypediagnostic: SN6PR1501MB2189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(39860400002)(396003)(376002)(54094003)(189003)(24454002)(199004)(97736004)(6306002)(81166006)(236005)(54896002)(83716003)(3660700001)(5660300001)(68736007)(2950100002)(6916009)(2906002)(8676002)(6436002)(82746002)(6246003)(6486002)(4326008)(7736002)(81156014)(3280700002)(6512007)(229853002)(86362001)(59450400001)(5250100002)(54906003)(316002)(3480700004)(99286004)(105586002)(478600001)(36756003)(6116002)(2900100001)(106356001)(53546011)(33656002)(6506007)(39060400002)(14454004)(53936002)(25786009)(76176011)(102836004)(8936002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: JTbshcY1uHvcWrPA89CYESAQu264aRmAk73cupLIiOmfKrfAzwlUAKeAV7slIlGFeovnlxhGLJ0as4ifDrpgyg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_18061ACE08F7421981E60B73BBC56170fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 45c49279-c451-490e-1f1e-08d559583576 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 01:02:53.0783 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:03:18 -0000 --_000_18061ACE08F7421981E60B73BBC56170fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHJlY2VpdmVyIHdvdWxkIGJlIHRoZSBvbmUgdG8gcHJvdmlkZSB0aGUgb3ZlcnJpZGU7IFRo ZSBzZW5kZXIgY291bGQgaGludCB0byB0aGUgcmVjZWl2ZXIgdGhhdCBpdCBzaG91bGQgd2lzaCB0 aGlzIGJ5IHNpZ25hbGluZyBpdCBpcyBibG9ja2VkIChvciBkZWFkbG9ja2VkKSBvbiBmbG93IGNv bnRyb2wuDQotPVINCg0KRnJvbTogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkRhdGU6 IFRodXJzZGF5LCBKYW51YXJ5IDExLCAyMDE4IGF0IDQ6NTMgUE0NClRvOiBSb2JlcnRvIFBlb24g PGZlbml4QGZiLmNvbT4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwu Y29tPiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBEZWFkbG9ja2luZyBp biB0aGUgdHJhbnNwb3J0DQoNClJvYmVydG8sDQoNCkknbSBub3QgY29udmluY2VkIHRoYXQgd2Ug bmVlZCBzb21ldGhpbmcgYXMgaGVhdnktd2VpZ2h0IGFzIHRoaXMuLi4gc3BlY2lmaWNhbGx5LCBm bG93IGNvbnRyb2wgc28gZmFyIGhhcyBiZWVuIGluIHRoZSByZWNlaXZlcidzIGNvbnRyb2wsIHdo aWNoIGlzIGFsc28gdGhlIHRoaW5nIHRoYXQgb3ducyB0aGUgcmVzb3VyY2UgaXQgaXMgdHJ5aW5n IHRvIGxpbWl0IGV4aGF1c3Rpb24gb2YuIFRoaXMgbW92ZXMgaXQgb3V0IHRvIHRoZSBzZW5kZXIs IHdoaWNoIHdvdWxkIHJlcXVpcmUgYSByZWNlaXZlciB0byBub3cgY29tbWl0IG1lbW9yeSBiYXNl ZCBvbiB3aGF0IGEgc2VuZGVyIGJlbGlldmVzIGlzIGltcG9ydGFudC4gUmVhc29uaW5nIGFib3V0 IHRoaXMgc2VlbXMgbm9uLXRyaXZpYWwuIEkgd29ycnkgYWJvdXQgaG93IGFsbCB0aGlzIGRlZ3Jl ZSBvZiBmcmVlZG9tIHdpbGwgZ2V0IGFidXNlZCwgYW5kIHBvdGVudGlhbCBzaGFycCBlZGdlcy4N Cg0KSWYgd2UgY2FuIGVuc3VyZSBwcmlvcml0eSBjb25zdW1wdGlvbiBvZiB0aGUgc2hhcmVkIHJl c291cmNlLCB0aGF0IHNlZW1zIGFkZXF1YXRlIHRvIHJlc29sdmUgdGhlIHByb2JsZW0gb24gaGFu ZC4gRG8geW91IHRoaW5rIHNvbWV0aGluZyBtb3JlIGlzIHJlcXVpcmVkPw0KDQotIGphbmENCg0K T24gV2VkLCBKYW4gMTAsIDIwMTggYXQgMTI6MjYgUE0sIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIu Y29tPG1haWx0bzpmZW5peEBmYi5jb20+PiB3cm90ZToNCkFub3RoZXIgb3B0aW9uOg0KQWxsb3cg YSBmbG93LWNvbnRyb2wg4oCYb3ZlcnJpZGXigJkgd2hpY2ggYWxsb3dzIGEgcmVjZWl2ZXIgdG8g c3RhdGUgdGhhdCB0aGV5IHJlYWxseSB3YW50IGRhdGEgb24gYSBwYXJ0aWN1bGFyIHN0cmVhbSwg YW5kIGlnbm9yZSB0aGUgZ2xvYmFsIGZsb3cgY29udHJvbCBmb3IgdGhpcy4NCg0KSG93IHlvdeKA mWQgZG8gaXQ6DQpBIHJlY2VpdmVyIGNhbiBzZW5kIGEgZmxvdy1jb250cm9sIG92ZXJyaWRlIGZv ciBhIHN0cmVhbS4gVGhpcyBpbmNsdWRlcyB0aGUgc3RyZWFtIGlkIHRvIHdoaWNoIHRoZSBnbG9i YWwgd2luZG93IHRlbXBvcmFyaWx5IGRvZXMgbm90IGFwcGx5LCB0aGUgcmVjZWl2ZXLigJlzIGN1 cnJlbnQgc3RyZWFtIGZsb3ctY29udHJvbCBvZmZzZXQsIGFuZCB0aGUgb2Zmc2V0IHRoZSByZWNl aXZlciB3b3VsZCB3aXNoIHRvIGJlIGFibGUgdG8gcmVjZWl2ZS4NCkEgcmVjZWl2ZXIgbXVzdCBj b250aW51ZSB0byAocmUpc2VuZCB0aGUgb3ZlcnJpZGUgKGkuZS4gcmV4bWl0KSB1bnRpbCBpdCBp cyBhY2vigJlkLiBJdCBjYW5ub3Qgc2VuZCBvdGhlciBmbG93LWNvbnRyb2wgZm9yIHRoYXQgc3Ry ZWFtIHVudGlsIHRoZSBvdmVycmlkZSBpcyBhY2vigJlkLg0KVGh1czoNCiAgZ2xvYmFsLWZsb3ct Y29udHJvbC1vdmVycmlkZTogPHN0cmVhbS1pZD4gPGN1cnJlbnQtZmxvdy1jb250cm9sLW9mZnNl dD4sIDxvdmVycmlkZS1mbG93LWNvbnRyb2wtb2Zmc2V0Pg0KDQpUaGUgc2VuZGVyICh3aGljaCBy ZWNlaXZlcyB0aGUgb3ZlcnJpZGUpIGNyZWRpdHMgdGhlIGdsb2JhbCBmbG93IGNvbnRyb2wgd2l0 aCB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBkYXRhIHNlbnQgYmV5b25kIHRoZSByZWNlaXZl cnMgY3VycmVudGx5LWtub3duIGZsb3ctY29udHJvbCBvZmZzZXQgdXBvbiByZWNlaXB0IG9mIHRo ZSBvdmVycmlkZS4NClRoaXMgc3luY2hyb25pemVzIHRoZSBnbG9iYWwgc3RhdGUgYmV0d2VlbiB0 aGUgcmVjZWl2ZXIgYW5kIHRoZSBzZW5kZXIuDQpUaGUgc2VuZGVyIGNhbiB0aGVuIHNlbmQgdGhl IGRhdGEgb24gdGhlIHN0cmVhbSAod2l0aG91dCB0b3VjaGluZyBhbnkgb3RoZXIgZmxvdyBjb250 cm9sIGRhdGEpLg0KDQpXaHk6DQpUaGlzIGFsbG93cyBmb3IgYSByZWNlaXZlciB0byByZXNvbHZl IHByaW9yaXR5IGludmVyc2lvbnMgd2hpY2ggd291bGQgb3RoZXJ3aXNlIGxlYWQgdG8gZGVhZGxv Y2ssIGV2ZW4gd2hlbiB0aGUgZGF0YS9kZXAgbGVhZGluZyB0byB0aGlzIHdhcyBub3Qga25vd24g dG8gdGhlIHRyYW5zcG9ydC4gVGhpcyBleHRlbmRzIGJleW9uZCBzdWNoIGlzc3VlcyBiZXlvbmQg anVzdCBoZWFkZXIgY29tcHJlc3Npb24uDQoNClNpbmNlIHRoZSBnbG9iYWwgZmxvdy1jb250cm9s IGV4aXN0cyB0byBwcm90ZWN0IHRoZSBhcHAgZnJvbSByZXNvdXJjZSBleGhhdXN0aW9uLCB0aGlz IHBvc2VzIG5vIGFkZGl0aW9uYWwgcmlzayB0byB0aGUgYXBwbGljYXRpb24uDQpTaW1wbHkgaW5j cmVhc2luZyB0aGUgZ2xvYmFsIGZsb3cgY29udHJvbCBwcm92aWRlcyBsZXNzIHN0cm9uZyBndWFy YW50ZWVz4oCUYW55IHN0cmVhbSBtaWdodCBjb25zdW1lIGl0LCB3aGljaCBkb2VzbuKAmXQgcmVz b2x2ZSB0aGUgZGVwIGludmVyc2lvbi4gUmVqaWdnZXJpbmcgcHJpb3JpdGllcyBjYW4gaGVscCB0 byByZXNvbHZlIHRoaXMsIGJ1dCB3b3VsZCByZXF1aXJlIHRoZSBzZW5kZXIgdG8gc2VuZCBwcmlv cml0aWVzIHRvIHRoZSBjbGllbnQsIHdoaWNoIGlzIHByb2JsZW1hdGljIHcuci50LnJhY2VzIGFu ZCBqdXN0IGEgd2ViIG9mIGljay4NCg0KSGF2aW5nIGEgY3VzdG9tIGZyYW1lIHR5cGUgaXMgYWxz byBhIGxlc3Mgc3Ryb25nIGd1YXJhbnRlZSBhcyBpdCByZXF1aXJlcyB0aGUga25vd2xlZGdlIHRo YXQgdGhlIGRlcCBleGlzdHMgdG8gYmUgcHJlc2VudCBhdCB0aGUgdGltZSBvZiBzZW5kaW5nLCB3 aGljaCBpcyBvZnRlbiBpbXBvc3NpYmxlLg0KDQotPVINCg0KT24gMS85LzE4LCAxMDoxNyBQTSwg IlFVSUMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uIiA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQog ICAgQnVpbGRpbmcgYSBjb21wbGV4IGFwcGxpY2F0aW9uIHByb3RvY29sIG9uIHRvcCBvZiBRVUlD IGNvbnRpbnVlcyB0bw0KICAgIHByb2R1Y2Ugc3VycHJpc2VzLg0KDQogICAgVG9kYXkgaW4gdGhl IGhlYWRlciBjb21wcmVzc2lvbiBkZXNpZ24gdGVhbSBtZWV0aW5nIHdlIGRpc2N1c3NlZCBhDQog ICAgZGVhZGxvY2tpbmcgaXNzdWUgdGhhdCBJIHRoaW5rIHdhcnJhbnRzIHNoYXJpbmcgd2l0aCB0 aGUgbGFyZ2VyIGdyb3VwLg0KICAgIFRoaXMgaGFzIGltcGxpY2F0aW9ucyBmb3IgaG93IHBlb3Bs ZSBidWlsZCBhIFFVSUMgdHJhbnNwb3J0IGxheWVyLiAgSXQNCiAgICBtaWdodCBuZWVkIGNoYW5n ZXMgdG8gdGhlIEFQSSB0aGF0IGlzIGV4cG9zZWQgYnkgdGhhdCBsYXllci4NCg0KICAgIFRoaXMg aXNuJ3QgcmVhbGx5IHRoYXQgbmV3LCBidXQgSSBkb24ndCB0aGluayB3ZSd2ZSBwcm9wZXJseSBh ZGRyZXNzZWQNCiAgICB0aGUgcHJvYmxlbS4NCg0KDQogICAgIyMgVGhlIEJhc2ljIFByb2JsZW0N Cg0KICAgIElmIGEgcHJvdG9jb2wgY3JlYXRlcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiBzdHJlYW1z LCB0aGVyZSBpcyBhDQogICAgcG90ZW50aWFsIGZvciBmbG93IGNvbnRyb2wgdG8gZGVhZGxvY2su DQoNCiAgICBTYXkgdGhhdCBJIHNlbmQgWCBvbiBzdHJlYW0gMyBhbmQgWSBvbiBzdHJlYW0gNy4g IFByb2Nlc3NpbmcgWQ0KICAgIHJlcXVpcmVzIHRoYXQgWCBpcyBwcm9jZXNzZWQgZmlyc3QuDQoN CiAgICBYIGNhbm5vdCBiZSBzZW50IGR1ZSB0byBmbG93IGNvbnRyb2wgYnV0IFkgaXMgc2VudC4g IFRoaXMgaXMgYWx3YXlzDQogICAgcG9zc2libGUgZXZlbiBpZiBYIGlzIGFwcHJvcHJpYXRlbHkg cHJpb3JpdGl6ZWQuICBUaGUgcmVjZWl2ZXIgdGhlbg0KICAgIGxlYXZlcyBZIGluIGl0cyByZWNl aXZlIGJ1ZmZlciB1bnRpbCBYIGlzIHJlY2VpdmVkLg0KDQogICAgVGhlIHJlY2VpdmVyIGNhbm5v dCBnaXZlIGZsb3cgY29udHJvbCBjcmVkaXQgZm9yIGNvbnN1bWluZyBZIGJlY2F1c2UNCiAgICBp dCBjYW4ndCBjb25zdW1lIFkgdW50aWwgWCBpcyBzZW50LiAgQnV0IHRoZSBzZW5kZXIgbmVlZHMg ZmxvdyBjb250cm9sDQogICAgY3JlZGl0IHRvIHNlbmQgWC4gIFdlIGFyZSBkZWFkbG9ja2VkLg0K DQogICAgSXQgZG9lc24ndCBtYXR0ZXIgd2hldGhlciB0aGUgc3RyZWFtIG9yIGNvbm5lY3Rpb24g ZmxvdyBjb250cm9sIGlzDQogICAgY2F1c2luZyB0aGUgcHJvYmxlbSwgZWl0aGVyIHByb2R1Y2Vz IHRoZSBzYW1lIHJlc3VsdC4NCg0KICAgIChUbyBnaXZlIHNvbWUgYmFja2dyb3VuZCBvbiB0aGlz LCB3ZSB3ZXJlIGNvbnNpZGVyaW5nIGEgcHJlZmFjZSB0bw0KICAgIGhlYWRlciBibG9ja3MgdGhh dCBpZGVudGlmaWVkIHRoZSBoZWFkZXIgdGFibGUgc3RhdGUgdGhhdCB3YXMNCiAgICBuZWNlc3Nh cnkgdG8gcHJvY2VzcyB0aGUgaGVhZGVyIGJsb2NrLiAgVGhpcyB3b3VsZCBhbGxvdyBmb3INCiAg ICBjb25jdXJyZW50IHBvcHVsYXRpb24gb2YgdGhlIGhlYWRlciB0YWJsZSBhbmQgc2VuZGluZyBt ZXNzYWdlIHRoYXQNCiAgICBkZXBlbmRlZCBvbiB0aGUgaGVhZGVyIHRhYmxlIHN0YXRlIHRoYXQg aXMgdW5kZXIgY29uc3RydWN0aW9uLiAgQQ0KICAgIHJlY2VpdmVyIHdvdWxkIHJlYWQgdGhlIGlk ZW50aWZpZXIgYW5kIHRoZW4gbGVhdmUgdGhlIHJlbWFpbmRlciBvZiB0aGUNCiAgICBoZWFkZXIg YmxvY2sgaW4gdGhlIHJlY2VpdmUgYnVmZmVyIHVudGlsIHRoZSBoZWFkZXIgdGFibGUgd2FzIHJl YWR5LikNCg0KDQogICAgIyMgT3B0aW9ucw0KDQogICAgSXQgc2VlbXMgbGlrZSB0aGVyZSBhcmUg YSBmZXcgZGVjZW50IG9wdGlvbnMgZm9yIG1hbmFnaW5nIHRoaXMuICBUaGVzZQ0KICAgIGFyZSB3 aGF0IG9jY3VycmVkIHRvIG1lICh0aGVyZSBhcmUgYWxtb3N0IGNlcnRhaW5seSBtb3JlIG9wdGlv bnMpOg0KDQogICAgMS4gRG9uJ3QgZG8gdGhhdC4gIFdlIG1pZ2h0IGNvbmNlZGUgaW4gdGhpcyBj YXNlIHRoYXQgc2Vla2luZyB0aGUNCiAgICBpbmNyZW1lbnRhbCBpbXByb3ZlbWVudCB0byBjb21w cmVzc2lvbiBlZmZpY2llbmN5IGlzbid0IHdvcnRoIHRoZQ0KICAgIHJpc2suICBUaGF0IGlzLCB3 ZSBtaWdodCBtYWtlIGEgZ2VuZXJhbCBzdGF0ZW1lbnQgdGhhdCB0aGlzIHNvcnQgb2YNCiAgICBp bnRlci1zdHJlYW0gYmxvY2tpbmcgaXMgYSBiYWQgaWRlYS4NCg0KICAgIDIuIEZvcmNlIHJlY2Vp dmVycyB0byBjb25zdW1lIGRhdGEgb3IgcmVzZXQgc3RyZWFtcyBpbiB0aGUgY2FzZSBvZg0KICAg IHVuZnVsZmlsbGVkIGRlcGVuZGVuY2llcy4gIFRoZSBmb3JtZXIgc2VlbXMgbGlrZSBpdCBtaWdo dCBiZSB0b28gbXVjaA0KICAgIGxpa2UgbWFnaWNhbCB0aGlua2luZywgaW4gdGhlIHNlbnNlIHRo YXQgaXQgcmVxdWlyZXMgdGhhdCByZWNlaXZlcnMNCiAgICBjb25qdXJlIG1vcmUgbWVtb3J5IHVw LCBidXQgaWYgdGhlIHJlY2VpdmVyIHdlcmUgcmVxdWlyZWQgdG8gcmVhZCBZDQogICAgYW5kIHJl bGVhc2UgdGhlIGZsb3cgY29udHJvbCBjcmVkaXQsIHRoZW4gYWxsIHdvdWxkIGJlIGZpbmUuICBG b3INCiAgICBpbnN0YW5jZSwgd2UgY291bGQgcmVxdWlyZSB0aGF0IHRoZSByZWNlaXZlciByZXNl dCBhIHN0cmVhbSBpZiBpdA0KICAgIGNvdWxkbid0IHJlYWQgYW5kIGhhbmRsZSBkYXRhLiAgSXQg c2VlbXMgbGlrZSBhIGJhZCBhcnJhbmdlbWVudA0KICAgIHRob3VnaDogeW91IGVpdGhlciBoYXZl IHRvIGFsbG9jYXRlIG1vcmUgbWVtb3J5IHRoYW4geW91IHdvdWxkIGxpa2Ugb3INCiAgICBzdWZm ZXIgdGhlIHRpbWUgYW5kIG9wcG9ydHVuaXR5IGNvc3Qgb2YgaGF2aW5nIHRvIGRvIFkgb3Zlci4N Cg0KICAgIDMuIENyZWF0ZSBhbiBleGNlcHRpb24gZm9yIGZsb3cgY29udHJvbC4gIFRoaXMgaXMg d2hhdCBHb29nbGUgUVVJQw0KICAgIGRvZXMgZm9yIGl0cyBoZWFkZXJzIHN0cmVhbS4gIFJvYmVy dG8gb2JzZXJ2ZWQgdGhhdCB3ZSBjb3VsZA0KICAgIGFsdGVybmF0aXZlbHkgY3JlYXRlIGEgZnJh bWUgdHlwZSB0aGF0IHdhcyBleGNsdWRlZCBmcm9tIGZsb3cgY29udHJvbC4NCiAgICBJZiB0aGlz IHdlcmUgdXNlZCBmb3IgZGF0YSB0aGF0IGhhZCBkZXBlbmRlbmNpZXMsIHRoZW4gaXQgd291bGQg YmUNCiAgICBpbXBvc3NpYmxlIHRvIGRlYWRsb2NrLiAgSXQgd291bGQgYmUgc2ltaWxhcmx5IGRp ZmZpY3VsdCB0byBhY2NvdW50DQogICAgZm9yIG1lbW9yeSBhbGxvY2F0aW9uLCB0aG91Z2ggaWYg aXQgd2VyZSBwb3NzaWJsZSB0byBwcm9jZXNzIG9uDQogICAgcmVjZWlwdCwgdGhlbiB0aGlzICpt aWdodCogd29yay4gIFdlJ2QgaGF2ZSB0byBkbyBzb21ldGhpbmcgdG8gYWRkcmVzcw0KICAgIG91 dC1vZi1vcmRlciBkZWxpdmVyeSB0aG91Z2guICBJdCdzIHBvc3NpYmxlIHRoYXQgdGhlIHN0cmVh bQ0KICAgIGFic3RyYWN0aW9uIGlzIG5vdCBhcHByb3ByaWF0ZSBpbiB0aGlzIGNhc2UuDQoNCiAg ICA0LiBCbG9jayB0aGUgcHJvYmxlbSBhdCB0aGUgc291cmNlLiAgSXQgd2FzIHN1Z2dlc3RlZCB0 aGF0IGluIGNhc2VzDQogICAgd2hlcmUgdGhlcmUgaXMgYSBwb3RlbnRpYWwgZGVwZW5kZW5jeSwg dGhlbiBpdCBjYW4ndCBiZSBhIHByb2JsZW0gaWYNCiAgICB0aGUgdHJhbnNwb3J0IHJlZnVzZWQg dG8gYWNjZXB0IGRhdGEgdGhhdCBpdCBkaWRuJ3QgaGF2ZSBmbG93IGNvbnRyb2wNCiAgICBjcmVk aXQgZm9yLiAgV3JpdGVzIHRvIHRoZSB0cmFuc3BvcnQgd291bGQgY29uc3VtZSBmbG93IGNvbnRy b2wgY3JlZGl0DQogICAgaW1tZWRpYXRlbHkuICBUaGF0IHdheSBhcHBsaWNhdGlvbnMgd291bGQg b25seSBiZSBhYmxlIHRvIHdyaXRlIFggaWYNCiAgICB0aGVyZSB3YXMgYSBjaGFuY2UgdGhhdCBp dCB3b3VsZCBiZSBkZWxpdmVyZWQuICBBcHBsaWNhdGlvbnMgdGhhdCBoYXZlDQogICAgb3JkZXJp bmcgcmVxdWlyZW1lbnRzIGNhbiBlbnN1cmUgdGhhdCBZIGlzIHdyaXR0ZW4gYWZ0ZXIgWCBpcyBh Y2NlcHRlZA0KICAgIGJ5IHRoZSB0cmFuc3BvcnQgYW5kIHRoZXJlYnkgYXZvaWQgdGhlIGRlYWRs b2NrLiAgV3JpdGVzIG1pZ2h0IGJsb2NrDQogICAgcmF0aGVyIHRoYW4gZmFpbCwgaWYgdGhlIEFQ SSB3YXNuJ3QgaW50byB0aGUgd2hvbGUgbm9uLWJsb2NraW5nIEkvTw0KICAgIHRoaW5nLiAgVGhl IHRyYW5zcG9ydCBtaWdodCBzdGlsbCBoYXZlIHRvIGJ1ZmZlciBYIGZvciBvdGhlciByZWFzb25z LA0KICAgIGxpa2UgY29uZ2VzdGlvbiBjb250cm9sLCBidXQgaXQgY2FuIGd1YXJhbnRlZSB0aGF0 IGZsb3cgY29udHJvbCBpc24ndA0KICAgIGdvaW5nIHRvIGJsb2NrIGRlbGl2ZXJ5Lg0KDQoNCiAg ICAjIyBNeSBQcmVmZXJlbmNlDQoNCiAgICBSaWdodCBub3csIEknbSBpbmNsaW5lZCB0b3dhcmQg b3B0aW9uIDQuIE9wdGlvbiAxIHNlZW1zIGEgbGl0dGxlIHRvbw0KICAgIG11Y2ggb2YgYSBjb25z dHJhaW50LiAgUHJvdG9jb2xzIGNyZWF0ZSB0aGlzIHNvcnQgb2YgaW50ZXItZGVwZW5kZW5jeQ0K ICAgIG5hdHVyYWxseS4NCg0KICAgIFRoZXJlJ3MgYSBjZXJ0YWluIHB1cml0eSBpbiBoYXZpbmcg dGhlIGZsb3cgY29udHJvbCBleGVydCBiYWNrDQogICAgcHJlc3N1cmUgYWxsIHRoZSB3YXkgdG8g dGhlIG5leHQgbGF5ZXIgdXAuICBOb3QgYmVpbmcgYWJsZSB0byBidWlsZCBhDQogICAgdHJhbnNw b3J0IHdpdGggdW5jb25zdHJhaW5lZCB3cml0ZXMgaXMgcG90ZW50aWFsbHkgY3JlYXRpbmcNCiAg ICB1bmRlc2lyYWJsZSBleHRlcm5hbGl0aWVzIG9uIHRyYW5zcG9ydCB1c2Vycy4gIE5vdyB0aGV5 IGhhdmUgdG8gd29ycnkNCiAgICBhYm91dCBmbG93IGNvbnRyb2wgYXMgd2VsbC4gIFBlcnNvbmFs bHksIEknbSBpbmNsaW5lZCB0byBzYXkgdGhhdCB0aGlzDQogICAgaXMgc29tZXRoaW5nIHRoYXQg YXBwbGljYXRpb24gcHJvdG9jb2xzIGFuZCB0aGVpciB1c2VycyBzaG91bGQgYmUNCiAgICBleHBv c2VkIHRvLiAgV2UndmUgc2VlbiB3aXRoIHRoZSBKUyBzdHJlYW1zIEFQSSB0aGF0IGl0J3MgdmFs dWFibGUgdG8NCiAgICBoYXZlIGJhY2sgcHJlc3N1cmUgYXZhaWxhYmxlIGF0IHRoZSBhcHBsaWNh dGlvbiBsYXllciBhbmQgYWxzbyBob3cgaXQNCiAgICBpcyBwb3NzaWJsZSB0byBkbyB0aGF0IHJl bGF0aXZlbHkgZWxlZ2FudGx5Lg0KDQogICAgSSdtIGFsbW9zdCBjZXJ0YWluIHRoYXQgSSBoYXZl bid0IHRob3VnaHQgYWJvdXQgYWxsIHRoZSBwb3RlbnRpYWwNCiAgICBhbHRlcm5hdGl2ZXMuICBJ IHdvbmRlciBpZiB0aGVyZSBpc24ndCBzb21lIGV4cGVyaWVuY2Ugd2l0aCB0aGlzDQogICAgcHJv YmxlbSBpbiBTQ1RQIHRoYXQgbWlnaHQgbGVuZCBzb21lIGluc2lnaHRzLg0KDQoNCg0K --_000_18061ACE08F7421981E60B73BBC56170fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHJlY2VpdmVyIHdvdWxkIGJlIHRoZSBvbmUgdG8gcHJvdmlkZSB0 aGUgb3ZlcnJpZGU7IFRoZSBzZW5kZXIgY291bGQgaGludCB0byB0aGUgcmVjZWl2ZXIgdGhhdCBp dCBzaG91bGQgd2lzaCB0aGlzIGJ5IHNpZ25hbGluZyBpdCBpcyBibG9ja2VkIChvciBkZWFkbG9j a2VkKSBvbiBmbG93IGNvbnRyb2wuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkphbmEgSXll bmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlRodXJzZGF5LCBK YW51YXJ5IDExLCAyMDE4IGF0IDQ6NTMgUE08YnI+DQo8Yj5UbzogPC9iPlJvYmVydG8gUGVvbiAm bHQ7ZmVuaXhAZmIuY29tJmd0Ozxicj4NCjxiPkNjOiA8L2I+TWFydGluIFRob21zb24gJmx0O21h cnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDssIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBEZWFkbG9ja2luZyBpbiB0aGUgdHJhbnNwb3J0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Sb2JlcnRvLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkknbSBub3QgY29udmluY2VkIHRoYXQgd2UgbmVlZCBzb21ldGhpbmcgYXMgaGVhdnktd2VpZ2h0 IGFzIHRoaXMuLi4gc3BlY2lmaWNhbGx5LCBmbG93IGNvbnRyb2wgc28gZmFyIGhhcyBiZWVuIGlu IHRoZSByZWNlaXZlcidzIGNvbnRyb2wsIHdoaWNoIGlzIGFsc28gdGhlIHRoaW5nIHRoYXQgb3du cyB0aGUgcmVzb3VyY2UgaXQgaXMgdHJ5aW5nIHRvIGxpbWl0IGV4aGF1c3Rpb24gb2YuIFRoaXMg bW92ZXMgaXQNCiBvdXQgdG8gdGhlIHNlbmRlciwgd2hpY2ggd291bGQgcmVxdWlyZSBhIHJlY2Vp dmVyIHRvIG5vdyBjb21taXQgbWVtb3J5IGJhc2VkIG9uIHdoYXQgYSBzZW5kZXIgYmVsaWV2ZXMg aXMgaW1wb3J0YW50LiBSZWFzb25pbmcgYWJvdXQgdGhpcyBzZWVtcyBub24tdHJpdmlhbC4gSSB3 b3JyeSBhYm91dCBob3cgYWxsIHRoaXMgZGVncmVlIG9mIGZyZWVkb20gd2lsbCBnZXQgYWJ1c2Vk LCBhbmQgcG90ZW50aWFsIHNoYXJwIGVkZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBjYW4gZW5zdXJlIHByaW9yaXR5IGNvbnN1 bXB0aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2UsIHRoYXQgc2VlbXMgYWRlcXVhdGUgdG8gcmVz b2x2ZSB0aGUgcHJvYmxlbSBvbiBoYW5kLiBEbyB5b3UgdGhpbmsgc29tZXRoaW5nIG1vcmUgaXMg cmVxdWlyZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgSmFuIDEwLCAyMDE4IGF0IDEyOjI2IFBNLCBSb2JlcnRvIFBlb24g Jmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5mZW5peEBm Yi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Bbm90aGVyIG9wdGlvbjo8YnI+DQpBbGxvdyBhIGZsb3ctY29udHJvbCDi gJhvdmVycmlkZeKAmSB3aGljaCBhbGxvd3MgYSByZWNlaXZlciB0byBzdGF0ZSB0aGF0IHRoZXkg cmVhbGx5IHdhbnQgZGF0YSBvbiBhIHBhcnRpY3VsYXIgc3RyZWFtLCBhbmQgaWdub3JlIHRoZSBn bG9iYWwgZmxvdyBjb250cm9sIGZvciB0aGlzLjxicj4NCjxicj4NCkhvdyB5b3XigJlkIGRvIGl0 Ojxicj4NCkEgcmVjZWl2ZXIgY2FuIHNlbmQgYSBmbG93LWNvbnRyb2wgb3ZlcnJpZGUgZm9yIGEg c3RyZWFtLiBUaGlzIGluY2x1ZGVzIHRoZSBzdHJlYW0gaWQgdG8gd2hpY2ggdGhlIGdsb2JhbCB3 aW5kb3cgdGVtcG9yYXJpbHkgZG9lcyBub3QgYXBwbHksIHRoZSByZWNlaXZlcuKAmXMgY3VycmVu dCBzdHJlYW0gZmxvdy1jb250cm9sIG9mZnNldCwgYW5kIHRoZSBvZmZzZXQgdGhlIHJlY2VpdmVy IHdvdWxkIHdpc2ggdG8gYmUgYWJsZSB0byByZWNlaXZlLjxicj4NCkEgcmVjZWl2ZXIgbXVzdCBj b250aW51ZSB0byAocmUpc2VuZCB0aGUgb3ZlcnJpZGUgKGkuZS4gcmV4bWl0KSB1bnRpbCBpdCBp cyBhY2vigJlkLiBJdCBjYW5ub3Qgc2VuZCBvdGhlciBmbG93LWNvbnRyb2wgZm9yIHRoYXQgc3Ry ZWFtIHVudGlsIHRoZSBvdmVycmlkZSBpcyBhY2vigJlkLjxicj4NClRodXM6PGJyPg0KJm5ic3A7 IGdsb2JhbC1mbG93LWNvbnRyb2wtb3ZlcnJpZGU6ICZsdDtzdHJlYW0taWQmZ3Q7ICZsdDtjdXJy ZW50LWZsb3ctY29udHJvbC1vZmZzZXQmZ3Q7LCAmbHQ7b3ZlcnJpZGUtZmxvdy1jb250cm9sLW9m ZnNldCZndDs8YnI+DQo8YnI+DQpUaGUgc2VuZGVyICh3aGljaCByZWNlaXZlcyB0aGUgb3ZlcnJp ZGUpIGNyZWRpdHMgdGhlIGdsb2JhbCBmbG93IGNvbnRyb2wgd2l0aCB0aGUgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBkYXRhIHNlbnQgYmV5b25kIHRoZSByZWNlaXZlcnMgY3VycmVudGx5LWtub3du IGZsb3ctY29udHJvbCBvZmZzZXQgdXBvbiByZWNlaXB0IG9mIHRoZSBvdmVycmlkZS48YnI+DQpU aGlzIHN5bmNocm9uaXplcyB0aGUgZ2xvYmFsIHN0YXRlIGJldHdlZW4gdGhlIHJlY2VpdmVyIGFu ZCB0aGUgc2VuZGVyLjxicj4NClRoZSBzZW5kZXIgY2FuIHRoZW4gc2VuZCB0aGUgZGF0YSBvbiB0 aGUgc3RyZWFtICh3aXRob3V0IHRvdWNoaW5nIGFueSBvdGhlciBmbG93IGNvbnRyb2wgZGF0YSku PGJyPg0KPGJyPg0KV2h5Ojxicj4NClRoaXMgYWxsb3dzIGZvciBhIHJlY2VpdmVyIHRvIHJlc29s dmUgcHJpb3JpdHkgaW52ZXJzaW9ucyB3aGljaCB3b3VsZCBvdGhlcndpc2UgbGVhZCB0byBkZWFk bG9jaywgZXZlbiB3aGVuIHRoZSBkYXRhL2RlcCBsZWFkaW5nIHRvIHRoaXMgd2FzIG5vdCBrbm93 biB0byB0aGUgdHJhbnNwb3J0LiBUaGlzIGV4dGVuZHMgYmV5b25kIHN1Y2ggaXNzdWVzIGJleW9u ZCBqdXN0IGhlYWRlciBjb21wcmVzc2lvbi48YnI+DQo8YnI+DQpTaW5jZSB0aGUgZ2xvYmFsIGZs b3ctY29udHJvbCBleGlzdHMgdG8gcHJvdGVjdCB0aGUgYXBwIGZyb20gcmVzb3VyY2UgZXhoYXVz dGlvbiwgdGhpcyBwb3NlcyBubyBhZGRpdGlvbmFsIHJpc2sgdG8gdGhlIGFwcGxpY2F0aW9uLjxi cj4NClNpbXBseSBpbmNyZWFzaW5nIHRoZSBnbG9iYWwgZmxvdyBjb250cm9sIHByb3ZpZGVzIGxl c3Mgc3Ryb25nIGd1YXJhbnRlZXPigJRhbnkgc3RyZWFtIG1pZ2h0IGNvbnN1bWUgaXQsIHdoaWNo IGRvZXNu4oCZdCByZXNvbHZlIHRoZSBkZXAgaW52ZXJzaW9uLiBSZWppZ2dlcmluZyBwcmlvcml0 aWVzIGNhbiBoZWxwIHRvIHJlc29sdmUgdGhpcywgYnV0IHdvdWxkIHJlcXVpcmUgdGhlIHNlbmRl ciB0byBzZW5kIHByaW9yaXRpZXMgdG8gdGhlIGNsaWVudCwgd2hpY2gNCiBpcyBwcm9ibGVtYXRp YyB3LnIudC5yYWNlcyBhbmQganVzdCBhIHdlYiBvZiBpY2suPGJyPg0KPGJyPg0KSGF2aW5nIGEg Y3VzdG9tIGZyYW1lIHR5cGUgaXMgYWxzbyBhIGxlc3Mgc3Ryb25nIGd1YXJhbnRlZSBhcyBpdCBy ZXF1aXJlcyB0aGUga25vd2xlZGdlIHRoYXQgdGhlIGRlcCBleGlzdHMgdG8gYmUgcHJlc2VudCBh dCB0aGUgdGltZSBvZiBzZW5kaW5nLCB3aGljaCBpcyBvZnRlbiBpbXBvc3NpYmxlLjxicj4NCjxz cGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tPVI8 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDEvOS8xOCwgMTA6 MTcgUE0sICZxdW90O1FVSUMgb24gYmVoYWxmIG9mIE1hcnRpbiBUaG9tc29uJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5v cmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbSI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBCdWlsZGluZyBhIGNvbXBsZXggYXBwbGljYXRpb24gcHJvdG9jb2wgb24g dG9wIG9mIFFVSUMgY29udGludWVzIHRvPGJyPg0KJm5ic3A7ICZuYnNwOyBwcm9kdWNlIHN1cnBy aXNlcy48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRvZGF5IGluIHRoZSBoZWFkZXIgY29tcHJl c3Npb24gZGVzaWduIHRlYW0gbWVldGluZyB3ZSBkaXNjdXNzZWQgYTxicj4NCiZuYnNwOyAmbmJz cDsgZGVhZGxvY2tpbmcgaXNzdWUgdGhhdCBJIHRoaW5rIHdhcnJhbnRzIHNoYXJpbmcgd2l0aCB0 aGUgbGFyZ2VyIGdyb3VwLjxicj4NCiZuYnNwOyAmbmJzcDsgVGhpcyBoYXMgaW1wbGljYXRpb25z IGZvciBob3cgcGVvcGxlIGJ1aWxkIGEgUVVJQyB0cmFuc3BvcnQgbGF5ZXIuJm5ic3A7IEl0PGJy Pg0KJm5ic3A7ICZuYnNwOyBtaWdodCBuZWVkIGNoYW5nZXMgdG8gdGhlIEFQSSB0aGF0IGlzIGV4 cG9zZWQgYnkgdGhhdCBsYXllci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgaXNuJ3Qg cmVhbGx5IHRoYXQgbmV3LCBidXQgSSBkb24ndCB0aGluayB3ZSd2ZSBwcm9wZXJseSBhZGRyZXNz ZWQ8YnI+DQombmJzcDsgJm5ic3A7IHRoZSBwcm9ibGVtLjxicj4NCjxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgIyMgVGhlIEJhc2ljIFByb2JsZW08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IElm IGEgcHJvdG9jb2wgY3JlYXRlcyBhIGRlcGVuZGVuY3kgYmV0d2VlbiBzdHJlYW1zLCB0aGVyZSBp cyBhPGJyPg0KJm5ic3A7ICZuYnNwOyBwb3RlbnRpYWwgZm9yIGZsb3cgY29udHJvbCB0byBkZWFk bG9jay48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFNheSB0aGF0IEkgc2VuZCBYIG9uIHN0cmVh bSAzIGFuZCBZIG9uIHN0cmVhbSA3LiZuYnNwOyBQcm9jZXNzaW5nIFk8YnI+DQombmJzcDsgJm5i c3A7IHJlcXVpcmVzIHRoYXQgWCBpcyBwcm9jZXNzZWQgZmlyc3QuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBYIGNhbm5vdCBiZSBzZW50IGR1ZSB0byBmbG93IGNvbnRyb2wgYnV0IFkgaXMgc2Vu dC4mbmJzcDsgVGhpcyBpcyBhbHdheXM8YnI+DQombmJzcDsgJm5ic3A7IHBvc3NpYmxlIGV2ZW4g aWYgWCBpcyBhcHByb3ByaWF0ZWx5IHByaW9yaXRpemVkLiZuYnNwOyBUaGUgcmVjZWl2ZXIgdGhl bjxicj4NCiZuYnNwOyAmbmJzcDsgbGVhdmVzIFkgaW4gaXRzIHJlY2VpdmUgYnVmZmVyIHVudGls IFggaXMgcmVjZWl2ZWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGUgcmVjZWl2ZXIgY2Fu bm90IGdpdmUgZmxvdyBjb250cm9sIGNyZWRpdCBmb3IgY29uc3VtaW5nIFkgYmVjYXVzZTxicj4N CiZuYnNwOyAmbmJzcDsgaXQgY2FuJ3QgY29uc3VtZSBZIHVudGlsIFggaXMgc2VudC4mbmJzcDsg QnV0IHRoZSBzZW5kZXIgbmVlZHMgZmxvdyBjb250cm9sPGJyPg0KJm5ic3A7ICZuYnNwOyBjcmVk aXQgdG8gc2VuZCBYLiZuYnNwOyBXZSBhcmUgZGVhZGxvY2tlZC48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IEl0IGRvZXNuJ3QgbWF0dGVyIHdoZXRoZXIgdGhlIHN0cmVhbSBvciBjb25uZWN0aW9u IGZsb3cgY29udHJvbCBpczxicj4NCiZuYnNwOyAmbmJzcDsgY2F1c2luZyB0aGUgcHJvYmxlbSwg ZWl0aGVyIHByb2R1Y2VzIHRoZSBzYW1lIHJlc3VsdC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7 IChUbyBnaXZlIHNvbWUgYmFja2dyb3VuZCBvbiB0aGlzLCB3ZSB3ZXJlIGNvbnNpZGVyaW5nIGEg cHJlZmFjZSB0bzxicj4NCiZuYnNwOyAmbmJzcDsgaGVhZGVyIGJsb2NrcyB0aGF0IGlkZW50aWZp ZWQgdGhlIGhlYWRlciB0YWJsZSBzdGF0ZSB0aGF0IHdhczxicj4NCiZuYnNwOyAmbmJzcDsgbmVj ZXNzYXJ5IHRvIHByb2Nlc3MgdGhlIGhlYWRlciBibG9jay4mbmJzcDsgVGhpcyB3b3VsZCBhbGxv dyBmb3I8YnI+DQombmJzcDsgJm5ic3A7IGNvbmN1cnJlbnQgcG9wdWxhdGlvbiBvZiB0aGUgaGVh ZGVyIHRhYmxlIGFuZCBzZW5kaW5nIG1lc3NhZ2UgdGhhdDxicj4NCiZuYnNwOyAmbmJzcDsgZGVw ZW5kZWQgb24gdGhlIGhlYWRlciB0YWJsZSBzdGF0ZSB0aGF0IGlzIHVuZGVyIGNvbnN0cnVjdGlv bi4mbmJzcDsgQTxicj4NCiZuYnNwOyAmbmJzcDsgcmVjZWl2ZXIgd291bGQgcmVhZCB0aGUgaWRl bnRpZmllciBhbmQgdGhlbiBsZWF2ZSB0aGUgcmVtYWluZGVyIG9mIHRoZTxicj4NCiZuYnNwOyAm bmJzcDsgaGVhZGVyIGJsb2NrIGluIHRoZSByZWNlaXZlIGJ1ZmZlciB1bnRpbCB0aGUgaGVhZGVy IHRhYmxlIHdhcyByZWFkeS4pPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAjIyBPcHRp b25zPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJdCBzZWVtcyBsaWtlIHRoZXJlIGFyZSBhIGZl dyBkZWNlbnQgb3B0aW9ucyBmb3IgbWFuYWdpbmcgdGhpcy4mbmJzcDsgVGhlc2U8YnI+DQombmJz cDsgJm5ic3A7IGFyZSB3aGF0IG9jY3VycmVkIHRvIG1lICh0aGVyZSBhcmUgYWxtb3N0IGNlcnRh aW5seSBtb3JlIG9wdGlvbnMpOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMS4gRG9uJ3QgZG8g dGhhdC4mbmJzcDsgV2UgbWlnaHQgY29uY2VkZSBpbiB0aGlzIGNhc2UgdGhhdCBzZWVraW5nIHRo ZTxicj4NCiZuYnNwOyAmbmJzcDsgaW5jcmVtZW50YWwgaW1wcm92ZW1lbnQgdG8gY29tcHJlc3Np b24gZWZmaWNpZW5jeSBpc24ndCB3b3J0aCB0aGU8YnI+DQombmJzcDsgJm5ic3A7IHJpc2suJm5i c3A7IFRoYXQgaXMsIHdlIG1pZ2h0IG1ha2UgYSBnZW5lcmFsIHN0YXRlbWVudCB0aGF0IHRoaXMg c29ydCBvZjxicj4NCiZuYnNwOyAmbmJzcDsgaW50ZXItc3RyZWFtIGJsb2NraW5nIGlzIGEgYmFk IGlkZWEuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAyLiBGb3JjZSByZWNlaXZlcnMgdG8gY29u c3VtZSBkYXRhIG9yIHJlc2V0IHN0cmVhbXMgaW4gdGhlIGNhc2Ugb2Y8YnI+DQombmJzcDsgJm5i c3A7IHVuZnVsZmlsbGVkIGRlcGVuZGVuY2llcy4mbmJzcDsgVGhlIGZvcm1lciBzZWVtcyBsaWtl IGl0IG1pZ2h0IGJlIHRvbyBtdWNoPGJyPg0KJm5ic3A7ICZuYnNwOyBsaWtlIG1hZ2ljYWwgdGhp bmtpbmcsIGluIHRoZSBzZW5zZSB0aGF0IGl0IHJlcXVpcmVzIHRoYXQgcmVjZWl2ZXJzPGJyPg0K Jm5ic3A7ICZuYnNwOyBjb25qdXJlIG1vcmUgbWVtb3J5IHVwLCBidXQgaWYgdGhlIHJlY2VpdmVy IHdlcmUgcmVxdWlyZWQgdG8gcmVhZCBZPGJyPg0KJm5ic3A7ICZuYnNwOyBhbmQgcmVsZWFzZSB0 aGUgZmxvdyBjb250cm9sIGNyZWRpdCwgdGhlbiBhbGwgd291bGQgYmUgZmluZS4mbmJzcDsgRm9y PGJyPg0KJm5ic3A7ICZuYnNwOyBpbnN0YW5jZSwgd2UgY291bGQgcmVxdWlyZSB0aGF0IHRoZSBy ZWNlaXZlciByZXNldCBhIHN0cmVhbSBpZiBpdDxicj4NCiZuYnNwOyAmbmJzcDsgY291bGRuJ3Qg cmVhZCBhbmQgaGFuZGxlIGRhdGEuJm5ic3A7IEl0IHNlZW1zIGxpa2UgYSBiYWQgYXJyYW5nZW1l bnQ8YnI+DQombmJzcDsgJm5ic3A7IHRob3VnaDogeW91IGVpdGhlciBoYXZlIHRvIGFsbG9jYXRl IG1vcmUgbWVtb3J5IHRoYW4geW91IHdvdWxkIGxpa2Ugb3I8YnI+DQombmJzcDsgJm5ic3A7IHN1 ZmZlciB0aGUgdGltZSBhbmQgb3Bwb3J0dW5pdHkgY29zdCBvZiBoYXZpbmcgdG8gZG8gWSBvdmVy Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMy4gQ3JlYXRlIGFuIGV4Y2VwdGlvbiBmb3IgZmxv dyBjb250cm9sLiZuYnNwOyBUaGlzIGlzIHdoYXQgR29vZ2xlIFFVSUM8YnI+DQombmJzcDsgJm5i c3A7IGRvZXMgZm9yIGl0cyBoZWFkZXJzIHN0cmVhbS4mbmJzcDsgUm9iZXJ0byBvYnNlcnZlZCB0 aGF0IHdlIGNvdWxkPGJyPg0KJm5ic3A7ICZuYnNwOyBhbHRlcm5hdGl2ZWx5IGNyZWF0ZSBhIGZy YW1lIHR5cGUgdGhhdCB3YXMgZXhjbHVkZWQgZnJvbSBmbG93IGNvbnRyb2wuPGJyPg0KJm5ic3A7 ICZuYnNwOyBJZiB0aGlzIHdlcmUgdXNlZCBmb3IgZGF0YSB0aGF0IGhhZCBkZXBlbmRlbmNpZXMs IHRoZW4gaXQgd291bGQgYmU8YnI+DQombmJzcDsgJm5ic3A7IGltcG9zc2libGUgdG8gZGVhZGxv Y2suJm5ic3A7IEl0IHdvdWxkIGJlIHNpbWlsYXJseSBkaWZmaWN1bHQgdG8gYWNjb3VudDxicj4N CiZuYnNwOyAmbmJzcDsgZm9yIG1lbW9yeSBhbGxvY2F0aW9uLCB0aG91Z2ggaWYgaXQgd2VyZSBw b3NzaWJsZSB0byBwcm9jZXNzIG9uPGJyPg0KJm5ic3A7ICZuYnNwOyByZWNlaXB0LCB0aGVuIHRo aXMgKm1pZ2h0KiB3b3JrLiZuYnNwOyBXZSdkIGhhdmUgdG8gZG8gc29tZXRoaW5nIHRvIGFkZHJl c3M8YnI+DQombmJzcDsgJm5ic3A7IG91dC1vZi1vcmRlciBkZWxpdmVyeSB0aG91Z2guJm5ic3A7 IEl0J3MgcG9zc2libGUgdGhhdCB0aGUgc3RyZWFtPGJyPg0KJm5ic3A7ICZuYnNwOyBhYnN0cmFj dGlvbiBpcyBub3QgYXBwcm9wcmlhdGUgaW4gdGhpcyBjYXNlLjxicj4NCjxicj4NCiZuYnNwOyAm bmJzcDsgNC4gQmxvY2sgdGhlIHByb2JsZW0gYXQgdGhlIHNvdXJjZS4mbmJzcDsgSXQgd2FzIHN1 Z2dlc3RlZCB0aGF0IGluIGNhc2VzPGJyPg0KJm5ic3A7ICZuYnNwOyB3aGVyZSB0aGVyZSBpcyBh IHBvdGVudGlhbCBkZXBlbmRlbmN5LCB0aGVuIGl0IGNhbid0IGJlIGEgcHJvYmxlbSBpZjxicj4N CiZuYnNwOyAmbmJzcDsgdGhlIHRyYW5zcG9ydCByZWZ1c2VkIHRvIGFjY2VwdCBkYXRhIHRoYXQg aXQgZGlkbid0IGhhdmUgZmxvdyBjb250cm9sPGJyPg0KJm5ic3A7ICZuYnNwOyBjcmVkaXQgZm9y LiZuYnNwOyBXcml0ZXMgdG8gdGhlIHRyYW5zcG9ydCB3b3VsZCBjb25zdW1lIGZsb3cgY29udHJv bCBjcmVkaXQ8YnI+DQombmJzcDsgJm5ic3A7IGltbWVkaWF0ZWx5LiZuYnNwOyBUaGF0IHdheSBh cHBsaWNhdGlvbnMgd291bGQgb25seSBiZSBhYmxlIHRvIHdyaXRlIFggaWY8YnI+DQombmJzcDsg Jm5ic3A7IHRoZXJlIHdhcyBhIGNoYW5jZSB0aGF0IGl0IHdvdWxkIGJlIGRlbGl2ZXJlZC4mbmJz cDsgQXBwbGljYXRpb25zIHRoYXQgaGF2ZTxicj4NCiZuYnNwOyAmbmJzcDsgb3JkZXJpbmcgcmVx dWlyZW1lbnRzIGNhbiBlbnN1cmUgdGhhdCBZIGlzIHdyaXR0ZW4gYWZ0ZXIgWCBpcyBhY2NlcHRl ZDxicj4NCiZuYnNwOyAmbmJzcDsgYnkgdGhlIHRyYW5zcG9ydCBhbmQgdGhlcmVieSBhdm9pZCB0 aGUgZGVhZGxvY2suJm5ic3A7IFdyaXRlcyBtaWdodCBibG9jazxicj4NCiZuYnNwOyAmbmJzcDsg cmF0aGVyIHRoYW4gZmFpbCwgaWYgdGhlIEFQSSB3YXNuJ3QgaW50byB0aGUgd2hvbGUgbm9uLWJs b2NraW5nIEkvTzxicj4NCiZuYnNwOyAmbmJzcDsgdGhpbmcuJm5ic3A7IFRoZSB0cmFuc3BvcnQg bWlnaHQgc3RpbGwgaGF2ZSB0byBidWZmZXIgWCBmb3Igb3RoZXIgcmVhc29ucyw8YnI+DQombmJz cDsgJm5ic3A7IGxpa2UgY29uZ2VzdGlvbiBjb250cm9sLCBidXQgaXQgY2FuIGd1YXJhbnRlZSB0 aGF0IGZsb3cgY29udHJvbCBpc24ndDxicj4NCiZuYnNwOyAmbmJzcDsgZ29pbmcgdG8gYmxvY2sg ZGVsaXZlcnkuPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAjIyBNeSBQcmVmZXJlbmNl PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBSaWdodCBub3csIEknbSBpbmNsaW5lZCB0b3dhcmQg b3B0aW9uIDQuIE9wdGlvbiAxIHNlZW1zIGEgbGl0dGxlIHRvbzxicj4NCiZuYnNwOyAmbmJzcDsg bXVjaCBvZiBhIGNvbnN0cmFpbnQuJm5ic3A7IFByb3RvY29scyBjcmVhdGUgdGhpcyBzb3J0IG9m IGludGVyLWRlcGVuZGVuY3k8YnI+DQombmJzcDsgJm5ic3A7IG5hdHVyYWxseS48YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7IFRoZXJlJ3MgYSBjZXJ0YWluIHB1cml0eSBpbiBoYXZpbmcgdGhlIGZs b3cgY29udHJvbCBleGVydCBiYWNrPGJyPg0KJm5ic3A7ICZuYnNwOyBwcmVzc3VyZSBhbGwgdGhl IHdheSB0byB0aGUgbmV4dCBsYXllciB1cC4mbmJzcDsgTm90IGJlaW5nIGFibGUgdG8gYnVpbGQg YTxicj4NCiZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHdpdGggdW5jb25zdHJhaW5lZCB3cml0ZXMg aXMgcG90ZW50aWFsbHkgY3JlYXRpbmc8YnI+DQombmJzcDsgJm5ic3A7IHVuZGVzaXJhYmxlIGV4 dGVybmFsaXRpZXMgb24gdHJhbnNwb3J0IHVzZXJzLiZuYnNwOyBOb3cgdGhleSBoYXZlIHRvIHdv cnJ5PGJyPg0KJm5ic3A7ICZuYnNwOyBhYm91dCBmbG93IGNvbnRyb2wgYXMgd2VsbC4mbmJzcDsg UGVyc29uYWxseSwgSSdtIGluY2xpbmVkIHRvIHNheSB0aGF0IHRoaXM8YnI+DQombmJzcDsgJm5i c3A7IGlzIHNvbWV0aGluZyB0aGF0IGFwcGxpY2F0aW9uIHByb3RvY29scyBhbmQgdGhlaXIgdXNl cnMgc2hvdWxkIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyBleHBvc2VkIHRvLiZuYnNwOyBXZSd2ZSBz ZWVuIHdpdGggdGhlIEpTIHN0cmVhbXMgQVBJIHRoYXQgaXQncyB2YWx1YWJsZSB0bzxicj4NCiZu YnNwOyAmbmJzcDsgaGF2ZSBiYWNrIHByZXNzdXJlIGF2YWlsYWJsZSBhdCB0aGUgYXBwbGljYXRp b24gbGF5ZXIgYW5kIGFsc28gaG93IGl0PGJyPg0KJm5ic3A7ICZuYnNwOyBpcyBwb3NzaWJsZSB0 byBkbyB0aGF0IHJlbGF0aXZlbHkgZWxlZ2FudGx5Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg SSdtIGFsbW9zdCBjZXJ0YWluIHRoYXQgSSBoYXZlbid0IHRob3VnaHQgYWJvdXQgYWxsIHRoZSBw b3RlbnRpYWw8YnI+DQombmJzcDsgJm5ic3A7IGFsdGVybmF0aXZlcy4mbmJzcDsgSSB3b25kZXIg aWYgdGhlcmUgaXNuJ3Qgc29tZSBleHBlcmllbmNlIHdpdGggdGhpczxicj4NCiZuYnNwOyAmbmJz cDsgcHJvYmxlbSBpbiBTQ1RQIHRoYXQgbWlnaHQgbGVuZCBzb21lIGluc2lnaHRzLjxicj4NCjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_18061ACE08F7421981E60B73BBC56170fbcom_-- From nobody Thu Jan 11 17:05:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3661270AB for ; Thu, 11 Jan 2018 17:05:22 -0800 (PST) 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=duGyblJt; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kMUeQJ+5 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNXcrHfmCJj8 for ; Thu, 11 Jan 2018 17:05:20 -0800 (PST) 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 42910127058 for ; Thu, 11 Jan 2018 17:05:20 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C15E5Z011930; Thu, 11 Jan 2018 17:05:15 -0800 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=FbbBKSA8HllyEi5506xj5h4Hj6BpxOguV3vDHodNsWk=; b=duGyblJtSB6T+Lgtnama5i2B7PDjF1pZdRM+ruz+j/fGmPzEzT0F1DcYwO4Nll4kXR4H i+VAFwZxUO5Sns/e6tnojv3qvtEuxjkePHiDa4CI4EK8kFqvlFGAO8AqswWoyiyP4nKJ CCVymkbdzzRdnCUQ4lnOVouQd3Mr/8ft4iI= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fehrhg9gu-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 17:05:14 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 11 Jan 2018 20:05:04 -0500 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=FbbBKSA8HllyEi5506xj5h4Hj6BpxOguV3vDHodNsWk=; b=kMUeQJ+5cerggUCQsV2QDPS3wFcWFiclgw2Zrs+pKJeqsD3HRUCp/bzAVZ0if3W1F17deNZsZc92kGcT1qevIjGzfL8cz1S3j6EcjcpOghbLWNAOiMbJ15QTcsuZZVhJ/xGdnTKKs7lMtD7pZmKMd3/V1p+AgpJPMRjoDrvC8EM= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 01:05:02 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 01:05:02 +0000 From: Roberto Peon To: "Lubashev, Igor" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev , IETF QUIC WG Subject: Re: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNvWU8AgAAH/ICAAAhFgP//fKwA Date: Fri, 12 Jan 2018 01:05:02 +0000 Message-ID: <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:41fc] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:S1dOVPTFXOu6iACgh9h066KpgN27/wwBXIU1YM0opE/Ik2uqm5zS2SQ+NrqGBNU/z5VWfc92BXYpNXJVB2fMTRt38Dqdf/2qnXsYzI5SLmzRM/Hp+cNl2e7WFfvR0tQIOqURUFGUOS/LYpoE0Yf1YCyT+Mzy1LNu0HQDqATY95qzZjdJRHLKvl89BtNfelikiE8MAIhJsvlrIkQu+lpAcm0Ofd1XGHezdpBd9w5hIFnnyeeHMKlKLPBq4kHAJl1n; 20:+hrA2NDw+L8IXaKEdeo5qsrwn58iv4ZDmknlPnS4EqasVqBFgIlXTQVNVYJ7FCXr8foQUXObfAfwJ8qZkBmdwvuPe5w3kzJZfWcmlqE3mNAaX01d0ispwutwtc35O/BRVWmVmV1v6CilaOi4wD9yGMz/UCKfip/uZYdhx8sDT5g= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cba463ff-aa75-4f09-b276-08d5595882ad x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020074)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189; x-ms-traffictypediagnostic: SN6PR1501MB2189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(39860400002)(396003)(376002)(53754006)(189003)(24454002)(199004)(97736004)(6306002)(81166006)(236005)(54896002)(83716003)(3660700001)(5660300001)(68736007)(2950100002)(2906002)(8676002)(6436002)(82746002)(6246003)(6486002)(7736002)(81156014)(3280700002)(6512007)(229853002)(86362001)(110136005)(59450400001)(5250100002)(316002)(99286004)(105586002)(478600001)(36756003)(6116002)(2900100001)(106356001)(53546011)(561944003)(33656002)(6506007)(39060400002)(14454004)(53936002)(25786009)(76176011)(102836004)(8936002)(93886005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +8Gfu5eVzCNE0bn64DXLxyqV8CEArXdydxQA1y0ThH0EXKlQ9RrO90ugz7Rg+M+DCwOyfEqj9jeEufVikQsovg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_21333E2AAA5D4D9983153468242493DFfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cba463ff-aa75-4f09-b276-08d5595882ad X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 01:05:02.6427 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:05:22 -0000 --_000_21333E2AAA5D4D9983153468242493DFfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdC9hZ3JlZWQuIFRoZSBMNCDigJhyb3V0ZXLigJkgbXVzdCBiZSBhYmxlIHRvIGRlY3J5 cHQvaW50ZXJwcmV0IHRoZSBkYXRhIGluIG9yZGVyIHRvIGFjdCB1cG9uIGl0LiBUaGlzIHJlcXVp cmVzIHNoYXJpbmcgb2Ygc29tZSBrZXkgbWF0ZXJpYWwuDQotPVINCg0KRnJvbTogUVVJQyA8cXVp Yy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgIkx1YmFzaGV2LCBJZ29yIiA8aWx1YmFz aGVAYWthbWFpLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDExLCAyMDE4IGF0IDQ6NTUg UE0NClRvOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+LCBW aWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xlLmNvbT4sIElFVEYgUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXpl DQoNCkkgdGhpbmsgdGhlIGlkZWEgaXMgdGhhdCB0aGUga2V5IHVzZWQgdG8gZW5jcnlwdCBjb25u ZWN0aW9uIElEIGlzIGtub3duIHRvIGJvdGggdGhlIHNlcnZlciBhbmQgdGhlIHJvdXRlci4gIFRo YXQga2V5IHdvdWxkIG5lZWQgdG8gYmUgcm90YXRlZCBwZXJpb2RpY2FsbHksIGFuZCB0aGUgcm91 dGVyIHdvdWxkIG5lZWQgdG8gdW5kZXJzdGFuZCB3aGljaCBrZXkgd2FzIHVzZWQgZm9yIHRoaXMg cGFydGljdWxhciBjb25uZWN0aW9uLCBidXQgdGhhdCBjYW4gYmUgc29sdmVkLg0KDQpGcm9tOiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNzoyNSBQTQ0KVG86IEx1YmFzaGV2LCBJZ29y IDxpbHViYXNoZUBha2FtYWkuY29tPjsgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5j b20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogSW5jcmVhc2lu ZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZQ0KDQpBY3R1YWxseSwgb24gZW5jcnlwdGlvbiBvZiBj b25uZWN0aW9uIElELCB0aGlzIGlzIG5vdCBzbyBzaW1wbGUuDQoNCldlIG11c3QgYXNzdW1lIHRo ZXJlIGlzIG9ubHkgYSBzaW5nbGUga2V5IGZvciBtYW55IGNvbm5lY3Rpb25zIGJlY2F1c2UgdGhl IHJvdXRlciBpcyBub3QgcGFydCBvZiBhIGtleSBleGNoYW5nZS4gVGhpcyB1bmlxdWUgdmFsdWUg b3IgY291bnRlciB1c2VkIGZvciBlbmNyeXB0aW5nIGEgc2luZ2xlIGJsb2NrIGNhbm5vdCBiZSB0 aGUgc2FtZSBmb3IgdHdvIGRpZmZlcmVudCBjb25uZWN0aW9ucyBJROKAmXMsIGJ1dCBpdCBjYW4g YmUgcHVibGljLiBUaGlzIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBzdG9yZWQgaW4gdGhlIHBhY2tl dCBoZWFkZXIuIEFuZCwgYXMgaXQgdHVybnMgb3V0LCByYW5kb20gY29ubmVjdGlvbiBJRCBjaG9z ZW4gYnkgYSB0cnVzdGVkIHNvdXJjZSwgY2FuIGJlIHVzZWQgZm9yIHN1Y2ggYSB1bmlxdWUgdmFs dWUuIEJ1dCB0aGVuIGl0IG11c3QgYmUgdXNlZCB0byBlbmNyeXB0IGFuZC9vciBhdXRoZW50aWNh dGUgc29tZXRoaW5nIGVsc2UgY2FycnlpbmcgdGhlIGFjdHVhbCByb3V0aW5nIGluZm9ybWF0aW9u LiBTbyBub3cgeW91IHN0YXJ0IHRvIHJlYWxseSBuZWVkIHNvbWUgZXh0cmEgcGF5bG9hZC4NCg0K QWx0ZXJuYXRpdmVseSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBpcyBlbnRpcmVseSByYW5kb20g c3VjaCBhcyBjb250ZW50IGhhc2hlZCByb3V0aW5nLiBUaGVuIHlvdSBvbmx5IG5lZWQgdG8gYXV0 aGVudGljYXRlIHRoZSByb3V0aW5nIGRhdGEuIFlvdSBjYW4gZG8gdGhhdCB3aXRoIGEgSE1BQywg YW5kIENNQUMgY291bGQgcHJvYmFibHkgYWxzbyB3b3JrLiBUaGUgYWRkaXRpb25hbCBiZW5lZml0 IGlzIHRoYXQgeW91IGNhbiBwcm9iYWJseSBnZXQgYXdheSB3aXRoIDY0LWJpdHMgZm9yIGFsbCBy b3V0aW5nIGluZm9ybWF0aW9uIHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgYXV0aCB0YWcuIFNheSA0 OCBiaXRzIG9mIHJvdXRpbmcgZGF0YSBhbmQgMTYgYml0cyBvZiBhdXRoIHRhZy4NCg0KS2luZCBS ZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDEyIEphbnVhcnkgMjAx OCBhdCAwMC41Ny4yMSwgTHViYXNoZXYsIElnb3IgKGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRv OmlsdWJhc2hlQGFrYW1haS5jb20+KSB3cm90ZToNCkkgYW0gaW50ZXJlc3RlZCBpbiBleHBsb3Jp bmcgdGhpcyBwcm9wb3NhbCwgc2luY2UgaXQgYWxsb3dzIGZvciBtb3JlIGZsZXhpYmxlIHNjaGVt ZXMgb2YgZW5jb2Rpbmcgcm91dGluZyBtZXRhZGF0YSBhbmQgYSBjaGVja3N1bS4gIEkgd291bGQg YWxzbyBsaWtlIHRvIGJlIGV4cGxpY2l0IGFib3V0IHRoZSBjb25uZWN0aW9uIElEIHNpemUgaW4g YSBwYWNrZXQgaGVhZGVyLCB0aG91Z2gsIHNpbmNlIGl0IGdyZWF0bHkgc2ltcGxpZmllcyB0aGUg aW1wbGVtZW50YXRpb24uDQoNCg0KICAqICAgSWdvcg0KRnJvbTogVmljdG9yIFZhc2lsaWV2IFtt YWlsdG86dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+XQ0KU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNjoxNiBQTQ0KVG86IElFVEYgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBJbmNyZWFzaW5n IFFVSUMgY29ubmVjdGlvbiBJRCBzaXplDQoNCkhpIGV2ZXJ5b25lLA0KDQpJbiB0aGUgY3VycmVu dCB2ZXJzaW9uIG9mIFFVSUMsIHRoZSBjb25uZWN0aW9uIElEIHNpemUgaXMgZml4ZWQgdG8gYmUg YSA2NC1iaXQgb3BhcXVlIGJsb2IsIGFuZCB0aGF0IGlzIHNldCBhcyBhbiBpbnZhcmlhbnQgaW4g dGhlIHByb3RvY29sLg0KDQpJ4oCZdmUgbG9va2VkIGludG8gcG9zc2liaWxpdHkgb2YgdXNpbmcg YSBjb25uZWN0aW9uIElEIHRvIGVuY29kZSB0aGUgc3BlY2lmaWMgc2VydmVyIGRldGFpbHMgaW50 byBpdCAodG8gcHJvdmlkZSBzdGFiaWxpdHkgb2YgdGhlIGNvbm5lY3Rpb24gaW4gY2FzZSBvZiBs b2FkIGJhbGFuY2luZyBjaGFuZ2VzLCBlc3BlY2lhbGx5IEJHUCBmbGFwcyBmb3IgYW55Y2FzdCBJ UHMpLCBhbmQgaGF2ZSBjaGF0dGVkIGFib3V0IHRoaXMgd2l0aCBvdGhlciBwZW9wbGUgSSBrbmV3 IHdlcmUgaW50ZXJlc3RlZCBpbiB0aGlzLiAgSXQgc2VlbXMgbGlrZSA2NCBiaXRzIG1pZ2h0IGJl IHRvbyBzbWFsbCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudCB0byBsZWF2ZSBh biBvcHBvcnR1bml0eSB0byBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZS4NCg0KVGhlIGJh c2ljIGlkZWEgaXMgdGhhdCB5b3Ugd2FudCB0byBiZSBhYmxlIHRvOg0KDQogIDEuICBTdG9yZSBz b21lIHJvdXRpbmcgbWV0YWRhdGEgaW4gdGhlIGNvbm5lY3Rpb24gSUQuDQogIDIuICBIYXZlIHNv bWUgZW50cm9weSB0aGF0IGFsbG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50aWNhbCBy b3V0aW5nIG1ldGFkYXRhLg0KICAzLiAgSGF2ZSBhIGNoZWNrc3VtIHRvIGVuc3VyZSB0aGUgdmFs aWRpdHkgb2Ygcm91dGluZyBpbmZvcm1hdGlvbg0KICA0LiAgRW5jcnlwdCB0aGUgaW5mb3JtYXRp b24gYWJvdmUgdG8gcHJldmVudCBkaXNjbG9zaW5nIHRoZSByb3V0ZSBpbmZvcm1hdGlvbiBhbmQg YWxsb3cgZ2VuZXJhdGluZyB1bmNvcnJlbGF0YWJsZSBjb25uZWN0aW9uIElEcy4NClRoZXJlIGFy ZSB0d28gdW5kZXJseWluZyBpc3N1ZXMgaGVyZS4gIFRoZSBmaXJzdCBwcm9ibGVtIGlzIHRoYXQg YWxsIG9mIHRoaXMgZG9lcyBub3QgZml0IHdlbGwgaW50byA2NCBiaXRzLCBhbmQgeW91IGhhdmUg dG8gc2VyaW91c2x5IGNvbXByb21pc2Ugb24gdGhlIHN0cmVuZ3RoIG9mIHRoZSBjaGVja3N1bSAo d2hpY2ggaXMgYmFkIGVzcGVjaWFsbHkgaWYgeW91IHdhbnQgaXQgdG8gYmUgYSBNQUMgcmF0aGVy IHRoYW4gYSBjaGVja3N1bSkuICBUaGUgc2Vjb25kIHByb2JsZW0gaXMgdGhhdCBlbmNyeXB0aW5n IDY0LWJpdCB2YWx1ZXMgZmFzdCBpcyBhY3R1YWxseSBmYWlybHkgaGFyZCBzaW5jZSB0aGUgYmxv Y2sgY2lwaGVycyBlYXNpbHkgYXZhaWxhYmxlIGluIGhhcmR3YXJlIGhhdmUgMTI4LWJpdCBibG9j ayBzaXplLCBhbmQgdGhlIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvbiBsb2FkIGJhbGFuY2Vy cyBhcmUgdGlnaHRlciB0aGFuIG9uIHNlcnZlcnMuDQoNCkluIG90aGVyIHdvcmRzLCBoYXZpbmcg YSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgcHJvdmlkZXMgZm9yIGFuIGVhc3kgc2VjdXJlIHdheSB0 byBnZW5lcmF0ZSB1bmxpbmthYmxlIGNvbm5lY3Rpb24gSURzIG9uIG1pZ3JhdGlvbi4NCg0KU28s IHRoZSBwcm9ibGVtIHdl4oCZcmUgdHJ5aW5nIHRvIHNvbHZlIGlzIHRoYXQgdGhlIGNvbm5lY3Rp b24gSUQgaXMgdG9vIHNtYWxsLiAgVGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgSSBiZWxpZXZlIHRo ZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhbnN3ZXIgYXQgdGhpcyBwb2ludDoNCg0KICAxLiAgRG8g d2Ugd2FudCB0byBhZGRyZXNzIHRoaXMgcHJvYmxlbSBhdCB0aGlzIHBvaW50IGluIHN0YW5kYXJk aXphdGlvbiBwcm9jZXNzPw0KICAyLiAgSWYgd2UgZG9u4oCZdCBhZGRyZXNzIHRoaXMgcHJvYmxl bSByaWdodCBub3csIGhvdyBkbyB3ZSBzdHJ1Y3R1cmUgdGhlIHN0YW5kYXJkIGluIGEgd2F5IHRo YXQgd2UgY2FuIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBpbiB0aGUgZnV0dXJlPw0KVGhlcmUg YXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgbWFraW5nIGNvbm5lY3Rp b24gSUQgbGFyZ2VyLiAgT25lIGlzIHRvIGp1c3QgYWRkIGV4dHJhIGJpdCB0byB0aGUg4oCcb21p dCBjb25uZWN0aW9uIElE4oCdIGZpZWxkIHRvIGFsbG93IDEyOC1iaXQgY29ubmVjdGlvbiBJRHMu ICBBbm90aGVyIGFwcHJvYWNoIGlzIHRvIGFsbG93IGNvbm5lY3Rpb24gSUQgc2l6ZSB0byBiZSBl eHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUgc2VydmVyLCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0 aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0IHNpemUgYW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBw YXRoIG5lZWRzIHRvIHJlYWQgaXQuDQoNClRoZXJl4oCZcyBhbHNvIGEgcXVlc3Rpb24gb2YgaG93 IG11Y2ggb2YgY29ubmVjdGlvbiBJRHMgZG8gbWlkZGxlYm94ZXMgKGV4Y2x1ZGluZyBsb2FkIGJh bGFuY2VycyBhbmQgb3RoZXIgYm94ZXMgb3duZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFzIGVpdGhl ciBjbGllbnQgb3Igc2VydmVyKSBuZWVkIHRvIGtub3cuICBXZSBjb3VsZCBnbyBmb3IgYm90aCDi gJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3YXlzIGFibGUgdG8gcmVhZCB0aGUgZW50aXJlIElE 4oCdIGFuZCDigJxtaWRkbGVib3hlcyBzaG91bGQgbm90IHJlYWQgY29ubmVjdGlvbiBJRHMgYXQg YWxsIG9wdGlvbnPigJ0sIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyBhbHNvIGEgcm9vbSBmb3IgbW9y ZSBmbGV4aWJsZSBmb3JtdWxhdGlvbnMgbGlrZSDigJxtaWRkbGVib3hlcyBhbHdheXMgZ2V0IGZp cnN0IDY0IGJpdHMgYW5kIHRoZXkgaGF2ZSB1c2VmdWwgZW50cm9weSB0byBkaXN0aW5ndWlzaCBj b25uZWN0aW9uc+KAnS4NCg0KICAtLSBWaWN0b3IuDQo= --_000_21333E2AAA5D4D9983153468242493DFfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5F698C588606B5428543DA9789B65CD8@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYu YWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjEzNTAzMjA1OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzY3ODMwMzU2O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MjE5NzA2MDM0Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotNjgxMDI2MjIwO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjI2 OTcwMjU2NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTQwNTc5MTg2O30NCkBsaXN0IGwyOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjps ZXZlbDYNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6NjQzMDQ5NzI4Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNDcyMDk4NjA0O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6NjYxMjAy NzgzOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTcwMzk3MTY2O30NCkBsaXN0IGw0OmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDUNCgl7bXNvLWxpc3QtaWQ6MTQ2NTQ2MjY4ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEx ODkzNDQwOTY7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29ycmVjdC9hZ3JlZWQuIFRoZSBMNCDigJhy b3V0ZXLigJkgbXVzdCBiZSBhYmxlIHRvIGRlY3J5cHQvaW50ZXJwcmV0IHRoZSBkYXRhIGluIG9y ZGVyIHRvIGFjdCB1cG9uIGl0LiBUaGlzIHJlcXVpcmVzIHNoYXJpbmcgb2Ygc29tZSBrZXkgbWF0 ZXJpYWwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mICZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtp bHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgSmFudWFy eSAxMSwgMjAxOCBhdCA0OjU1IFBNPGJyPg0KPGI+VG86IDwvYj5NaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7LCBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zh c2lsdnZAZ29vZ2xlLmNvbSZndDssIElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8 YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNp emU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSB0aGluayB0aGUgaWRlYSBpcyB0aGF0IHRoZSBrZXkgdXNlZCB0byBlbmNyeXB0IGNvbm5lY3Rp b24gSUQgaXMga25vd24gdG8gYm90aCB0aGUgc2VydmVyIGFuZCB0aGUgcm91dGVyLiZuYnNwOyBU aGF0IGtleSB3b3VsZCBuZWVkIHRvIGJlIHJvdGF0ZWQgcGVyaW9kaWNhbGx5LCBhbmQgdGhlIHJv dXRlciB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgd2hpY2gga2V5IHdhcyB1c2VkIGZvciB0aGlz IHBhcnRpY3VsYXIgY29ubmVjdGlvbiwNCiBidXQgdGhhdCBjYW4gYmUgc29sdmVkLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5j b21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNzoyNSBQ TTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20m Z3Q7OyBWaWN0b3IgVmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xlLmNvbSZndDs7IElFVEYgUVVJ QyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEluY3Jl YXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPkFjdHVhbGx5LCBvbiBlbmNyeXB0aW9uIG9mIGNvbm5lY3Rpb24gSUQsIHRoaXMgaXMgbm90 IHNvIHNpbXBsZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2UgbXVzdCBh c3N1bWUgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBrZXkgZm9yIG1hbnkgY29ubmVjdGlvbnMgYmVj YXVzZSB0aGUgcm91dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5IGV4Y2hhbmdlLiBUaGlzIHVuaXF1 ZSB2YWx1ZSBvciBjb3VudGVyIHVzZWQgZm9yIGVuY3J5cHRpbmcgYSBzaW5nbGUNCiBibG9jayBj YW5ub3QgYmUgdGhlIHNhbWUgZm9yIHR3byBkaWZmZXJlbnQgY29ubmVjdGlvbnMgSUTigJlzLCBi dXQgaXQgY2FuIGJlIHB1YmxpYy4gVGhpcyBtZWFucyB0aGF0IGl0IG11c3QgYmUgc3RvcmVkIGlu IHRoZSBwYWNrZXQgaGVhZGVyLiBBbmQsIGFzIGl0IHR1cm5zIG91dCwgcmFuZG9tIGNvbm5lY3Rp b24gSUQgY2hvc2VuIGJ5IGEgdHJ1c3RlZCBzb3VyY2UsIGNhbiBiZSB1c2VkIGZvciBzdWNoIGEg dW5pcXVlIHZhbHVlLiBCdXQgdGhlbg0KIGl0IG11c3QgYmUgdXNlZCB0byBlbmNyeXB0IGFuZC9v ciBhdXRoZW50aWNhdGUgc29tZXRoaW5nIGVsc2UgY2FycnlpbmcgdGhlIGFjdHVhbCByb3V0aW5n IGluZm9ybWF0aW9uLiBTbyBub3cgeW91IHN0YXJ0IHRvIHJlYWxseSBuZWVkIHNvbWUgZXh0cmEg cGF5bG9hZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QWx0ZXJuYXRpdmVs eSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBpcyBlbnRpcmVseSByYW5kb20gc3VjaCBhcyBjb250 ZW50IGhhc2hlZCByb3V0aW5nLiBUaGVuIHlvdSBvbmx5IG5lZWQgdG8gYXV0aGVudGljYXRlIHRo ZSByb3V0aW5nIGRhdGEuIFlvdSBjYW4gZG8gdGhhdCB3aXRoIGEgSE1BQywNCiBhbmQgQ01BQyBj b3VsZCBwcm9iYWJseSBhbHNvIHdvcmsuIFRoZSBhZGRpdGlvbmFsIGJlbmVmaXQgaXMgdGhhdCB5 b3UgY2FuIHByb2JhYmx5IGdldCBhd2F5IHdpdGggNjQtYml0cyBmb3IgYWxsIHJvdXRpbmcgaW5m b3JtYXRpb24gcG9zc2libHkgaW5jbHVkaW5nIHRoZSBhdXRoIHRhZy4gU2F5IDQ4IGJpdHMgb2Yg cm91dGluZyBkYXRhIGFuZCAxNiBiaXRzIG9mIGF1dGggdGFnLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxNTcxNjEzNzIw MzMzMzg4OCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PktpbmQgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+T24gMTIgSmFudWFyeSAyMDE4IGF0IDAwLjU3LjIxLCBMdWJhc2hldiwgSWdv ciAoPGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5j b208L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gaW50ZXJl c3RlZCBpbiBleHBsb3JpbmcgdGhpcyBwcm9wb3NhbCwgc2luY2UgaXQgYWxsb3dzIGZvciBtb3Jl IGZsZXhpYmxlIHNjaGVtZXMgb2YgZW5jb2Rpbmcgcm91dGluZyBtZXRhZGF0YQ0KIGFuZCBhIGNo ZWNrc3VtLiZuYnNwOyBJIHdvdWxkIGFsc28gbGlrZSB0byBiZSBleHBsaWNpdCBhYm91dCB0aGUg Y29ubmVjdGlvbiBJRCBzaXplIGluIGEgcGFja2V0IGhlYWRlciwgdGhvdWdoLCBzaW5jZSBpdCBn cmVhdGx5IHNpbXBsaWZpZXMgdGhlIGltcGxlbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4gVmljdG9yIFZhc2lsaWV2IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhc2lsdnZA Z29vZ2xlLmNvbSI+dmFzaWx2dkBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFV SUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQg c2l6ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgZXZlcnlvbmUsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVjdGlvbiBJRCBzaXplIGlzIGZpeGVk IHRvIGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhhdCBpcyBzZXQgYXMNCiBhbiBpbnZh cmlhbnQgaW4gdGhlIHByb3RvY29sLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPknigJl2ZSBsb29rZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2lu ZyBhIGNvbm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBp bnRvIGl0ICh0byBwcm92aWRlDQogc3RhYmlsaXR5IG9mIHRoZSBjb25uZWN0aW9uIGluIGNhc2Ug b2YgbG9hZCBiYWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBCR1AgZmxhcHMgZm9yIGFueWNh c3QgSVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkg a25ldyB3ZXJlIGludGVyZXN0ZWQgaW4gdGhpcy4mbmJzcDsgSXQgc2VlbXMgbGlrZSA2NCBiaXRz IG1pZ2h0IGJlIHRvbyBzbWFsbCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudA0K IHRvIGxlYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBzaXpl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRo ZSBiYXNpYyBpZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0bzo8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzYi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlN0b3JlIHNvbWUgcm91dGluZyBtZXRhZGF0YSBpbiB0aGUg Y29ubmVjdGlvbiBJRC48L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm82Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5IYXZlIHNvbWUgZW50cm9weSB0aGF0IGFsbG93cyBkaXN0aW5ndWlzaCB1c2VycyB3 aXRoIGlkZW50aWNhbCByb3V0aW5nIG1ldGFkYXRhLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzYiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhhdmUgYSBjaGVja3N1bSB0byBlbnN1cmUgdGhlIHZh bGlkaXR5IG9mIHJvdXRpbmcgaW5mb3JtYXRpb248L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm82 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5FbmNyeXB0IHRoZSBpbmZvcm1hdGlvbiBhYm92ZSB0byBw cmV2ZW50IGRpc2Nsb3NpbmcgdGhlIHJvdXRlIGluZm9ybWF0aW9uIGFuZCBhbGxvdyBnZW5lcmF0 aW5nIHVuY29ycmVsYXRhYmxlIGNvbm5lY3Rpb24gSURzLjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPlRoZXJlIGFyZSB0d28gdW5kZXJseWluZyBpc3N1ZXMgaGVyZS4mbmJzcDsgVGhlIGZp cnN0IHByb2JsZW0gaXMgdGhhdCBhbGwgb2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0 IGJpdHMsIGFuZA0KIHlvdSBoYXZlIHRvIHNlcmlvdXNseSBjb21wcm9taXNlIG9uIHRoZSBzdHJl bmd0aCBvZiB0aGUgY2hlY2tzdW0gKHdoaWNoIGlzIGJhZCBlc3BlY2lhbGx5IGlmIHlvdSB3YW50 IGl0IHRvIGJlIGEgTUFDIHJhdGhlciB0aGFuIGEgY2hlY2tzdW0pLiZuYnNwOyBUaGUgc2Vjb25k IHByb2JsZW0gaXMgdGhhdCBlbmNyeXB0aW5nIDY0LWJpdCB2YWx1ZXMgZmFzdCBpcyBhY3R1YWxs eSBmYWlybHkgaGFyZCBzaW5jZSB0aGUgYmxvY2sgY2lwaGVycyBlYXNpbHkgYXZhaWxhYmxlDQog aW4gaGFyZHdhcmUgaGF2ZSAxMjgtYml0IGJsb2NrIHNpemUsIGFuZCB0aGUgcGVyZm9ybWFuY2Ug cmVxdWlyZW1lbnRzIG9uIGxvYWQgYmFsYW5jZXJzIGFyZSB0aWdodGVyIHRoYW4gb24gc2VydmVy cy4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5JbiBvdGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElE IHByb3ZpZGVzIGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5saW5rYWJsZSBj b25uZWN0aW9uDQogSURzIG9uIG1pZ3JhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbywgdGhlIHByb2JsZW0gd2XigJlyZSB0cnlpbmcg dG8gc29sdmUgaXMgdGhhdCB0aGUgY29ubmVjdGlvbiBJRCBpcyB0b28gc21hbGwuJm5ic3A7IFRo ZXJlIGFyZSB0d28gcXVlc3Rpb25zIEkgYmVsaWV2ZQ0KIHRoZSB3b3JraW5nIGdyb3VwIHNob3Vs ZCBhbnN3ZXIgYXQgdGhpcyBwb2ludDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzkiPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkRvIHdlIHdhbnQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBzdGFu ZGFyZGl6YXRpb24gcHJvY2Vzcz88L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm85Ij4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5JZiB3ZSBkb27igJl0IGFkZHJlc3MgdGhpcyBwcm9ibGVtIHJpZ2h0IG5v dywgaG93IGRvIHdlIHN0cnVjdHVyZSB0aGUgc3RhbmRhcmQgaW4gYSB3YXkgdGhhdCB3ZSBjYW4g ZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIGluIHRoZSBmdXR1cmU/PC9zcGFuPjxvOnA+PC9vOnA+ PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0g b2YgbWFraW5nIGNvbm5lY3Rpb24gSUQgbGFyZ2VyLiZuYnNwOyBPbmUgaXMgdG8ganVzdCBhZGQg ZXh0cmEgYml0IHRvIHRoZQ0KIOKAnG9taXQgY29ubmVjdGlvbiBJROKAnSBmaWVsZCB0byBhbGxv dyAxMjgtYml0IGNvbm5lY3Rpb24gSURzLiZuYnNwOyBBbm90aGVyIGFwcHJvYWNoIGlzIHRvIGFs bG93IGNvbm5lY3Rpb24gSUQgc2l6ZSB0byBiZSBleHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUg c2VydmVyLCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0 IHNpemUgYW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBwYXRoIG5lZWRzIHRvIHJlYWQgaXQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmXigJlz IGFsc28gYSBxdWVzdGlvbiBvZiBob3cgbXVjaCBvZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVi b3hlcyAoZXhjbHVkaW5nIGxvYWQgYmFsYW5jZXJzIGFuZCBvdGhlciBib3hlcw0KIG93bmVkIGJ5 IHRoZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIgY2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93 LiZuYnNwOyBXZSBjb3VsZCBnbyBmb3IgYm90aCDigJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3 YXlzIGFibGUgdG8gcmVhZCB0aGUgZW50aXJlIElE4oCdIGFuZCDigJxtaWRkbGVib3hlcyBzaG91 bGQgbm90IHJlYWQgY29ubmVjdGlvbiBJRHMgYXQgYWxsIG9wdGlvbnPigJ0sIGJ1dCBJIHRoaW5r IHRoZXJl4oCZcyBhbHNvIGEgcm9vbSBmb3IgbW9yZSBmbGV4aWJsZQ0KIGZvcm11bGF0aW9ucyBs aWtlIOKAnG1pZGRsZWJveGVzIGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZl IHVzZWZ1bCBlbnRyb3B5IHRvIGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyAtLSBWaWN0 b3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_21333E2AAA5D4D9983153468242493DFfbcom_-- From nobody Thu Jan 11 17:09:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C365126C26 for ; Thu, 11 Jan 2018 17:09:07 -0800 (PST) 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 Pf_zkQzx0M5b for ; Thu, 11 Jan 2018 17:09:04 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 010FB1200F1 for ; Thu, 11 Jan 2018 17:09:04 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id t63so4092620iod.0 for ; Thu, 11 Jan 2018 17:09:03 -0800 (PST) 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=zsXxSC3VoSK4Y1VpkpwSXs6oKM7EzhG9BBiCfKaWGQw=; b=iwFqbPFY4Vw8m5x928kGd9e9oZpMqeOVJHuMjZr4z+2Wi0ma7hhaESE9o7zYkuALkq kGC+HEcJs4zmQM/Mvbz6e/9Te1ImmT7kBY4M9dBMCFRQ1RnCdnf+8bCmGqNNcBenp0SK fYVNa/hqd3WTKDcQpgH/w3qEwp1eeF1sgfLHuONeVYCJQcfjD5X5LrxQvsbS7Q4APIPR ozNX4EHuf/ekeb7lqaVWH+2sYmqsaBet60ikSt30q0v4hbeotl2ZLLKJ2k7d8NEiWnjD Is3GVqvhyWyHFTuTznQSrMWoYGXXsdRa9xNGBAvnrcsqBOAsl+7gixM/p2LvpRls4PjY aLwQ== 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=zsXxSC3VoSK4Y1VpkpwSXs6oKM7EzhG9BBiCfKaWGQw=; b=lS3699fe2+Wo1STYiGzYakwPzg70DBgweaih//B2rSR0V7Wq08KBKVMRB51RFd9QKN 6VNO/t4mdKyn+RSTuUJs5MNCln9xEiYfFUKK6p4YmiU7Q+8tUaOcOsWlksAsqFBvygEM FCRoDxL73M1IvUuLO2JKprovgfHs3suJsdW0iOWY0wwY/gkuCqg4FVMnNd07hhAx+JwQ WKvXERDNGeYc8HqdrQ8RAEJT3rGX556iR8MA6FLNEXp3pd371lSAQrMuaTyhdfmn/Jm3 13K1VON0BDYJ1wLFT9pGyd9XGXmQ+I1BEAaSNFvAdBdqRl1lCrDmOJtZR7rG2E3VXnyI 3QHg== X-Gm-Message-State: AKwxytePblRi/fOft6Ur+u0Crbl+PXSRuR8AdMF9O9eN/DxUDdTioJLc vUzz9PWZ1jQ/etk2KzU3wLevSx2oxj8O1eD1x/m/Piwb X-Google-Smtp-Source: ACJfBouxoUk6vqX4ZNUcbJIBHjVuUOxj/jzUEfk7UXrvvFLzvJzp+X+XsQMNMNQv5gAmZnRI+A4qEDLXg8iF1JcTFY0= X-Received: by 10.107.168.25 with SMTP id r25mr3141711ioe.16.1515719343182; Thu, 11 Jan 2018 17:09:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jan 2018 17:09:02 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 11 Jan 2018 17:09:02 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: IETF QUIC WG , Roberto Peon , "Lubashev, Igor" , Victor Vasiliev Content-Type: multipart/alternative; boundary="001a11427bca079eec056289e9bb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:09:07 -0000 --001a11427bca079eec056289e9bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This was also my intention. That the server and router share the key. But also that multiple connection ID=E2=80=99s are encrypted with the same key = and a unique identifier. Igor says the key can be matched to the connection. This is true, each connection can have a unique derived key. But it is largely the same as using a single key with different IV since we are only encrypting a single block. Details may very on how insecure the solution is if the unique value is not unique. But the challenge remains that there needs to be a unique identifier and packet number and 4-tuple is not it. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 02.05.18, Roberto Peon (fenix@fb.com) wrote: Correct/agreed. The L4 =E2=80=98router=E2=80=99 must be able to decrypt/int= erpret the data in order to act upon it. This requires sharing of some key material. -=3DR *From: *QUIC on behalf of "Lubashev, Igor" < ilubashe@akamai.com> *Date: *Thursday, January 11, 2018 at 4:55 PM *To: *Mikkel Fahn=C3=B8e J=C3=B8rgensen , Victor Vasili= ev < vasilvv@google.com>, IETF QUIC WG *Subject: *RE: Increasing QUIC connection ID size I think the idea is that the key used to encrypt connection ID is known to both the server and the router. That key would need to be rotated periodically, and the router would need to understand which key was used for this particular connection, but that can be solved. *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] *Sent:* Thursday, January 11, 2018 7:25 PM *To:* Lubashev, Igor ; Victor Vasiliev < vasilvv@google.com>; IETF QUIC WG *Subject:* RE: Increasing QUIC connection ID size Actually, on encryption of connection ID, this is not so simple. We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but it can be public. This means that it must be stored in th= e packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload. Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote: I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum. I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation. - Igor *From:* Victor Vasiliev [mailto:vasilvv@google.com] *Sent:* Thursday, January 11, 2018 6:16 PM *To:* IETF QUIC WG *Subject:* Increasing QUIC connection ID size Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --001a11427bca079eec056289e9bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = This was also my int= ention. That the server and router share the key. But also that multiple co= nnection ID=E2=80=99s are encrypted with the same key and a unique identifi= er.

    Igor says the key= can be matched to the connection. This is true, each connection can have a= unique derived key. But it is largely the same as using a single key with = different IV since we are only encrypting a single block. Details may very = on how insecure the solution is if the unique value is not unique. But the = challenge remains that there needs to be a unique identifier and packet num= ber and 4-tuple is not it.

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


    On 12 January 2018 at 02.05.18, Roberto Peon (fenix@fb.com) wrote:

    Correct/agreed. The L4 =E2=80=98router=E2=80=99 must= be able to decrypt/interpret the data in order to act upon it. This requir= es sharing of some key material.

    -=3DR

    =C2=A0

    From= : QUIC <quic-bounces@ietf.org> on behalf o= f "Lubashev, Igor" <ilu= bashe@akamai.com>
    Date: Thursday, January 11, 2018 at 4:55 PM
    To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>, Victor Vasiliev <vasilvv@google.com>, IETF QUIC WG <quic@ietf.org>
    Subject: RE: Increasing QUIC connection ID size

    =C2=A0

    I think the idea is that the key used to encrypt con= nection ID is known to both the server and the router.=C2=A0 That key would= need to be rotated periodically, and the router would need to understand w= hich key was used for this particular connection, but that can be solved.

    =C2=A0

    From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.com]
    Sent: Thursday, January 11, 2018 7:25 PM
    To: Lubashev, Igor <ilubas= he@akamai.com>; Victor Vasiliev <vasilvv@google.com>; IETF QUIC WG <quic@ietf.org>
    Subject: RE: Increasing QUIC connection ID size

    =C2=A0

    Actually, on encryption of connection ID, this is= not so simple.

    =C2=A0

    We must assume there is only a single key for man= y connections because the router is not part of a key exchange. This unique= value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but i= t can be public. This means that it must be stored in the packet header. An= d, as it turns out, random connection ID chosen by a trusted source, can be= used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the= actual routing information. So now you start to really need some extra pay= load.

    =C2=A0

    Alternatively the routing information is entirely= random such as content hashed routing. Then you only need to authenticate = the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can = probably get away with 64-bits for all routing information possibly includi= ng the auth tag. Say 48 bits of routing data and 16 bits of auth tag.

    =C2=A0

    Kind Regards,

    Mikkel Fahn=C3=B8e= J=C3=B8rgensen

    =C2=A0

    On 12 January 2018 at 00.57.21, Lubashev, Igor (<= a href=3D"mailto:ilubashe@akamai.com">ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it allows for= more flexible schemes of encoding routing metadata and a checksum.=C2=A0 I would also like to be explicit about the connectio= n ID size in a packet header, though, since it greatly simplifies the imple= mentation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org<= /a>>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID size is fixed= to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibility of using a connection ID t= o encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially = BGP flaps for anycast IPs), and have chatted about this with other people I= knew were interested in this.=C2=A0 It seems like 64 bits might be too sma= ll for this purpose, and we might want to leave an opportunity to extend the connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing m= etadata.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route informatio= n and allow generating uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The first problem i= s that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is= bad especially if you want it to be a MAC rather than a checksum).=C2=A0 T= he second problem is that encrypting 64-bit values fast is actually fairly = hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on l= oad balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provides for an = easy secure way to generate unlinkable connection IDs on migration.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is that the conne= ction ID is too small.=C2=A0 There are two questions I believe the working group should answer at this point:

    1. Do we want to address this problem at this point in standardization proc= ess?
    2. If we don=E2=80=99t address this problem right now, how do we structure = the standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of making connecti= on ID larger.=C2=A0 One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs= .=C2=A0 Another approach is to allow connection ID size to be explicitly sp= ecified by the server, and then assume that the load balancer knows that si= ze and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of connection IDs d= o middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.=C2=A0 W= e could go for both =E2=80=9Cmiddleboxes should be always able to read the = entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read connection IDs = at all options=E2=80=9D, but I think there=E2=80=99s also a room for more f= lexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits and they h= ave useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.

    --001a11427bca079eec056289e9bb-- From nobody Thu Jan 11 17:09:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9712D7F2 for ; Thu, 11 Jan 2018 17:09:25 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ouQGO2p3MBWD for ; Thu, 11 Jan 2018 17:09:15 -0800 (PST) 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 C52D51200F1 for ; Thu, 11 Jan 2018 17:09:14 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id a82so1996542ybg.1 for ; Thu, 11 Jan 2018 17:09:14 -0800 (PST) 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=ndjkd5f6Nd0AdN0JrTL3ZuNug2cMbQ/lMJya6UDQ0L0=; b=CZGwT7yXaDJFalsQkW2OYjS+ua5JWVpc0APOWCkEYx5q1TG8ogTs8/72LMtCHh0Lib WMSciEZN41rbJoEJnlEvBPSl4uJ1Nro8+A17p76meQcStjiJu5+/QdtK872AA80laK2a vxkyl253PnSlGjQISOrnJaB2/0bQ6MltDhG7DT+QFawx/rVBXDvp7xGKkko0HMNHGitt DV0DyGlIBFPDt306IOvzdIjxxCe7QYi4GLt2DTg0okoaTnUvz+9RS5XU2D8hkq+oizTk nW5c2ns16oKfkrDBBYe/m4E9TF48xkK8S0BGbNemrVBMiu62Awt6veQNC6aReHAKIb3P phVw== 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=ndjkd5f6Nd0AdN0JrTL3ZuNug2cMbQ/lMJya6UDQ0L0=; b=n1jLrQRwAdwnM2TV0piYAn0R1SXPF0uQs/ZhQ900xJQnKtpGaaFC4pnUhyXcO2iMT1 Yn9ypYgQKcWD92/RAHKHUQ4R1ggtzWq1xvLUrn63h/aPDdV2e/LBFs9lPRmuB4yljpH5 575L1EhFR+Qw/avVxIxKUsGk53OfN3+YXfWhfumseIryzOU5+gQwl+iZUR0ER8rr2VT3 dWggEEYZVmXYAC7ZVnQbKKppNR2dP5KLfF/zd92JMoF6ioTbiTCuQ7yMk/HvSbsGVsbn yiAtQAKYSCv8aNVnY2kgqFKmnccmeobd2Cz8aYk69zsNUc/mBF1wpGq/x8jsi+xV6+D4 /3dw== X-Gm-Message-State: AKwxytcesmuvYKCV2s8hL9zIC150OvHMto+68cpzY3AO9HfTUPqSSJbS vNWn+bDYNTluet/AmumLPW6sEO0C/MhUNYe2Q2ruXQ== X-Google-Smtp-Source: ACJfBosSAZZKdu9qKuA9G2JdTdsiG/sSbsBW8XFH550sHUAP5yH5g6c2kfJgF4aguIeDNeHYnajmJsbhlwOyWwkhYD4= X-Received: by 10.37.132.78 with SMTP id r14mr6374942ybm.366.1515719353606; Thu, 11 Jan 2018 17:09:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.42.147 with HTTP; Thu, 11 Jan 2018 17:09:12 -0800 (PST) In-Reply-To: <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> From: Jana Iyengar Date: Thu, 11 Jan 2018 17:09:12 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Roberto Peon Cc: "Lubashev, Igor" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Victor Vasiliev , IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0826ea90a77d19056289e90e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:09:26 -0000 --089e0826ea90a77d19056289e90e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just thinking aloud about key rotation -- you could always use the high-order bit as an expicit key selection bit... the server and load balancer can then use this bit during rotation to change keys without breakages. On Thu, Jan 11, 2018 at 5:05 PM, Roberto Peon wrote: > Correct/agreed. The L4 =E2=80=98router=E2=80=99 must be able to decrypt/i= nterpret the data > in order to act upon it. This requires sharing of some key material. > > -=3DR > > > > *From: *QUIC on behalf of "Lubashev, Igor" < > ilubashe@akamai.com> > *Date: *Thursday, January 11, 2018 at 4:55 PM > *To: *Mikkel Fahn=C3=B8e J=C3=B8rgensen , Victor Vasi= liev < > vasilvv@google.com>, IETF QUIC WG > > *Subject: *RE: Increasing QUIC connection ID size > > > > I think the idea is that the key used to encrypt connection ID is known t= o > both the server and the router. That key would need to be rotated > periodically, and the router would need to understand which key was used > for this particular connection, but that can be solved. > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Thursday, January 11, 2018 7:25 PM > *To:* Lubashev, Igor ; Victor Vasiliev < > vasilvv@google.com>; IETF QUIC WG > *Subject:* RE: Increasing QUIC connection ID size > > > > Actually, on encryption of connection ID, this is not so simple. > > > > We must assume there is only a single key for many connections because th= e > router is not part of a key exchange. This unique value or counter used f= or > encrypting a single block cannot be the same for two different connection= s > ID=E2=80=99s, but it can be public. This means that it must be stored in = the packet > header. And, as it turns out, random connection ID chosen by a trusted > source, can be used for such a unique value. But then it must be used to > encrypt and/or authenticate something else carrying the actual routing > information. So now you start to really need some extra payload. > > > > Alternatively the routing information is entirely random such as content > hashed routing. Then you only need to authenticate the routing data. You > can do that with a HMAC, and CMAC could probably also work. The additiona= l > benefit is that you can probably get away with 64-bits for all routing > information possibly including the auth tag. Say 48 bits of routing data > and 16 bits of auth tag. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) > wrote: > > I am interested in exploring this proposal, since it allows for more > flexible schemes of encoding routing metadata and a checksum. I would al= so > like to be explicit about the connection ID size in a packet header, > though, since it greatly simplifies the implementation. > > > > - Igor > > *From:* Victor Vasiliev [mailto:vasilvv@google.com] > *Sent:* Thursday, January 11, 2018 6:16 PM > *To:* IETF QUIC WG > *Subject:* Increasing QUIC connection ID size > > > > Hi everyone, > > > > In the current version of QUIC, the connection ID size is fixed to be a > 64-bit opaque blob, and that is set as an invariant in the protocol. > > > > I=E2=80=99ve looked into possibility of using a connection ID to encode t= he > specific server details into it (to provide stability of the connection i= n > case of load balancing changes, especially BGP flaps for anycast IPs), an= d > have chatted about this with other people I knew were interested in this. > It seems like 64 bits might be too small for this purpose, and we might > want to leave an opportunity to extend the connection ID size. > > > > The basic idea is that you want to be able to: > > 1. Store some routing metadata in the connection ID. > 2. Have some entropy that allows distinguish users with identical > routing metadata. > 3. Have a checksum to ensure the validity of routing information > 4. Encrypt the information above to prevent disclosing the route > information and allow generating uncorrelatable connection IDs. > > There are two underlying issues here. The first problem is that all of > this does not fit well into 64 bits, and you have to seriously compromise > on the strength of the checksum (which is bad especially if you want it t= o > be a MAC rather than a checksum). The second problem is that encrypting > 64-bit values fast is actually fairly hard since the block ciphers easily > available in hardware have 128-bit block size, and the performance > requirements on load balancers are tighter than on servers. > > > > In other words, having a 128-bit connection ID provides for an easy secur= e > way to generate unlinkable connection IDs on migration. > > > > So, the problem we=E2=80=99re trying to solve is that the connection ID i= s too > small. There are two questions I believe the working group should answer > at this point: > > 1. Do we want to address this problem at this point in standardization > process? > 2. If we don=E2=80=99t address this problem right now, how do we struc= ture the > standard in a way that we can extend the connection ID in the future? > > There are multiple ways to solve the problem of making connection ID > larger. One is to just add extra bit to the =E2=80=9Comit connection ID= =E2=80=9D field to > allow 128-bit connection IDs. Another approach is to allow connection ID > size to be explicitly specified by the server, and then assume that the > load balancer knows that size and no one else on the path needs to read i= t. > > > > There=E2=80=99s also a question of how much of connection IDs do middlebo= xes > (excluding load balancers and other boxes owned by the same entity as > either client or server) need to know. We could go for both =E2=80=9Cmid= dleboxes > should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleb= oxes should not > read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s = also a room for > more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 = bits and > they have useful entropy to distinguish connections=E2=80=9D. > > > > -- Victor. > > --089e0826ea90a77d19056289e90e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Just thinking aloud about key rotation -- you could always= use the high-order bit as an expicit key selection bit... the server and l= oad balancer can then use this bit during rotation to change keys without b= reakages.

    On= Thu, Jan 11, 2018 at 5:05 PM, Roberto Peon <fenix@fb.com> wrot= e:

    Correct/agreed. The L4 =E2=80=98router=E2=80=99 must= be able to decrypt/interpret the data in order to act upon it. This requir= es sharing of some key material.

    -=3DR

    =C2=A0

    From= : QUIC <quic-bounces@ietf.org> on behalf of "Lubashev, Igor" <ilubashe@akamai.com>
    Date: Thursday, January 11, 2018 at 4:55 PM
    To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>, Victor Vasiliev &= lt;vasilvv@google.c= om>, IETF QUIC WG <quic@ietf.org>


    Subject: RE: Increasing QUIC connection ID size
    <= /div>

    =C2=A0

    I think the idea is that the key used to encrypt con= nection ID is known to both the server and the router.=C2=A0 That key would= need to be rotated periodically, and the router would need to understand w= hich key was used for this particular connection, but that can be solved.

    =C2=A0

    From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mail= to:mikkelfj@gmail.c= om]
    Sent: Thursday, January 11, 2018 7:25 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; Victor Vasiliev <vasilvv@google.com>; IETF = QUIC WG <quic@ietf.or= g>
    Subject: RE: Increasing QUIC connection ID size

    =C2=A0

    Actually, on encryption of connection ID, this is= not so simple.

    =C2=A0

    We must assume there is only a single key for man= y connections because the router is not part of a key exchange. This unique= value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but i= t can be public. This means that it must be stored in the packet header. An= d, as it turns out, random connection ID chosen by a trusted source, can be= used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the= actual routing information. So now you start to really need some extra pay= load.

    =C2=A0

    Alternatively the routing information is entirely= random such as content hashed routing. Then you only need to authenticate = the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can = probably get away with 64-bits for all routing information possibly includi= ng the auth tag. Say 48 bits of routing data and 16 bits of auth tag.

    =C2=A0

    Kind Regards,

    Mikkel Fahn=C3=B8e= J=C3=B8rgensen

    =C2=A0

    On 12 January 2018 at 00.57= .21, Lubashev, Igor (ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since= it allows for more flexible schemes of encoding routing metadata and a checksum.=C2=A0 I would also like to be explicit about the connectio= n ID size in a packet header, though, since it greatly simplifies the imple= mentation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID= size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibility of using a c= onnection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially = BGP flaps for anycast IPs), and have chatted about this with other people I= knew were interested in this.=C2=A0 It seems like 64 bits might be too sma= ll for this purpose, and we might want to leave an opportunity to extend the connection ID size.=

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing m= etadata.
    3. Have a checksum to ensure the validity of routing information<= /u>
    4. Encrypt the information above to prevent disclosing the route informatio= n and allow generating uncorrelatable connection IDs.<= /li>

    There are two underlying issues here.=C2=A0 The f= irst problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is= bad especially if you want it to be a MAC rather than a checksum).=C2=A0 T= he second problem is that encrypting 64-bit values fast is actually fairly = hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on l= oad balancers are tighter than on servers.=C2=A0=C2=A0=

    =C2=A0

    In other words, having a 128-bit connection ID pr= ovides for an easy secure way to generate unlinkable connection IDs on migration.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is = that the connection ID is too small.=C2=A0 There are two questions I believ= e the working group should answer at this point:

    1. Do we want to address this problem at this point in standardization proc= ess?
    2. If we don=E2=80=99t address this problem right now, how do we structure = the standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of m= aking connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs= .=C2=A0 Another approach is to allow connection ID size to be explicitly sp= ecified by the server, and then assume that the load balancer knows that si= ze and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of co= nnection IDs do middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.=C2=A0 W= e could go for both =E2=80=9Cmiddleboxes should be always able to read the = entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read connection IDs = at all options=E2=80=9D, but I think there=E2=80=99s also a room for more f= lexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits and they h= ave useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.


    --089e0826ea90a77d19056289e90e-- From nobody Thu Jan 11 17:13:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FF4128959 for ; Thu, 11 Jan 2018 17:13:09 -0800 (PST) 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=j8E/gVWR; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iOoJqLGZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V5frqhLKMoo for ; Thu, 11 Jan 2018 17:13:07 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698A4120726 for ; Thu, 11 Jan 2018 17:13:07 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0C1BtIq032704; Thu, 11 Jan 2018 17:13:02 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=wrn6UFBrvRbIB46V0jdjhv+q/rWoujzKJ5obQufqy0Y=; b=j8E/gVWReJ+VWceBQFfuebR8/eUNcOVBKnhE68AWra/7VUKy6WCLddTPlyKPeE+fOfcM 2OyEytR4FPsjbt2QswDfRDssQt5Pm0yl7yMoGBCSHAGqaTuFf/ANx2Y9xv90dWCmwaMG R1jWaVQVp4SnICUwqJ1xkips9khVy3lDY3U= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0001303.ppops.net with ESMTP id 2fed8g9e6h-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Jan 2018 17:13:02 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.28) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 11 Jan 2018 20:13:01 -0500 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=wrn6UFBrvRbIB46V0jdjhv+q/rWoujzKJ5obQufqy0Y=; b=iOoJqLGZXFH+ebTgLGND/v/2nT+oLP9BMjDkM/RN1mV7uwpYF9eh3SEytHPmDt+IuppH3IEfmf8tF8n4KfWfPyFKQcGqHXUCpSm0oqbvhNq8f0YH2YEIz3DlP803YtDZCi+2wl81gY7FvszQalL24Y4B3TejNiJ6T4vxtGVXhXw= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 01:12:59 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 01:12:59 +0000 From: Roberto Peon To: Jana Iyengar CC: "Lubashev, Igor" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev , IETF QUIC WG Subject: Re: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNvWU8AgAAH/ICAAAhFgP//fKwAgACHSQD//3rxAA== Date: Fri, 12 Jan 2018 01:12:59 +0000 Message-ID: <346D256C-5D64-4EB4-8AA1-C16ACEB7B704@fb.com> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:47a8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:CcATfzGwMD8Bl2ri8KNo3bruceLij4DaKMC76xp7IuoEv2ZYu6DxZ+dgk9l9MiwTxMee3/YjuIe+AhAIVC3ypBKeoErE/wlhOgEg+wG8cXC++5rRJFapQQbNsSJ68eg4slrqI/MRDEAEqj5mZtz1lOiidw2gBv1B6F1FRWVOV2BxsSULKWyanGkFht70b20ox7wz3ZPAhxxlw2RwJbtANWnLH9L9W4UxrvXPfwIjLq9IjuUtKPSGxziANk/ijIMt; 20:UQ/5d+YckszpuqVZaaMXb2HHMp9P+t7MLVfyb0saM5K/Lm4BoaDxTP4m54whMqwpER8V13X8iA3bBHBxVZ8/mRuJ1kXQ6NQJUCzlPNLAVVIbNedfhRjdge2Z5Zx6YaiP2GgJ2lddosIvDQCstPtSEG3SWrsxbEHz3Aa1/Fffnhk= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e692f07c-0fc8-42f4-9263-08d559599f20 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020074)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189; x-ms-traffictypediagnostic: SN6PR1501MB2189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231023)(11241501184)(944501075)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(24454002)(199004)(189003)(53754006)(99286004)(105586002)(54906003)(5250100002)(316002)(6116002)(2900100001)(106356001)(53546011)(478600001)(36756003)(59450400001)(86362001)(25786009)(76176011)(8936002)(102836004)(53936002)(93886005)(6506007)(39060400002)(561944003)(33656002)(14454004)(68736007)(5660300001)(2950100002)(6916009)(97736004)(3660700001)(83716003)(54896002)(236005)(6306002)(81166006)(81156014)(6512007)(3280700002)(7736002)(4326008)(229853002)(2906002)(6486002)(6436002)(8676002)(82746002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DZQ+9ZyJ++oitZYTWozLcUSl21j+se2RBL3mECo+WMHN62ILtdz/7QzgieP3Qal+nIo0XufeEpjd2zoOh8M02A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_346D256C5D644EB48AA1C16ACEB7B704fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e692f07c-0fc8-42f4-9263-08d559599f20 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 01:12:59.8997 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:13:10 -0000 --_000_346D256C5D644EB48AA1C16ACEB7B704fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WXVwIQ0KSWYgeW914oCZcmUgcGFyYW5vaWQsIHlvdSBjYW4gZW5jcnlwdCB0d2ljZTogT25lIGxl c3Mtc2VjdXJlIGtleSB3aGljaCBhbGxvd3MgZGVjcnlwdGlvbiBvZiB0aGUga2V5IElEIGJpdHMg KGFuZCB0aGUgcmVzdCBvZiB0aGUgYml0cywgd2hpY2ggYXJlIGFsb25nIGZvciB0aGUgcmlkZSks IGFuZCB0aGVuIGFub3RoZXIga2V5IChpbmRpY2F0ZWQgYnkgdGhlIGZpcnN0KSB3aGljaCBhbGxv d3MgZGVjcnlwdGlvbiBhbmQgc3Vic2VxdWVudCBpbnRlcnByZXRhdGlvbiBvZiBlbmNvZGluZyBv ZiB0aGUgdGhlIEw3IGFkZHJlc3MgKHBsdXMgc2FsdCBzb21ld2hlcmUgaW4gdGhlcmUpIGludG8g dGhlIHJlbWFpbmluZyBiaXRzLg0KDQpVbHRpbWF0ZWx5LCBrbm93aW5nIGEgc2NoZW1lIGlzIHBv c3NpYmxlIGlzIHN1ZmZpY2llbnQgaGVyZSBzbyBsb25nIGFzIHdlIGRlbGVnYXRlIGNvbm5JRCBh c3NpZ25tZW50IHRvIHRoZSBzZXJ2ZXIuDQotPVINCg0KRnJvbTogSmFuYSBJeWVuZ2FyIDxqcmlA Z29vZ2xlLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBKYW51YXJ5IDExLCAyMDE4IGF0IDU6MDkgUE0N ClRvOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NCkNjOiAiTHViYXNoZXYsIElnb3IiIDxp bHViYXNoZUBha2FtYWkuY29tPiwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpA Z21haWwuY29tPiwgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdvb2dsZS5jb20+LCBJRVRGIFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogSW5jcmVhc2luZyBRVUlDIGNvbm5l Y3Rpb24gSUQgc2l6ZQ0KDQpKdXN0IHRoaW5raW5nIGFsb3VkIGFib3V0IGtleSByb3RhdGlvbiAt LSB5b3UgY291bGQgYWx3YXlzIHVzZSB0aGUgaGlnaC1vcmRlciBiaXQgYXMgYW4gZXhwaWNpdCBr ZXkgc2VsZWN0aW9uIGJpdC4uLiB0aGUgc2VydmVyIGFuZCBsb2FkIGJhbGFuY2VyIGNhbiB0aGVu IHVzZSB0aGlzIGJpdCBkdXJpbmcgcm90YXRpb24gdG8gY2hhbmdlIGtleXMgd2l0aG91dCBicmVh a2FnZXMuDQoNCk9uIFRodSwgSmFuIDExLCAyMDE4IGF0IDU6MDUgUE0sIFJvYmVydG8gUGVvbiA8 ZmVuaXhAZmIuY29tPG1haWx0bzpmZW5peEBmYi5jb20+PiB3cm90ZToNCkNvcnJlY3QvYWdyZWVk LiBUaGUgTDQg4oCYcm91dGVy4oCZIG11c3QgYmUgYWJsZSB0byBkZWNyeXB0L2ludGVycHJldCB0 aGUgZGF0YSBpbiBvcmRlciB0byBhY3QgdXBvbiBpdC4gVGhpcyByZXF1aXJlcyBzaGFyaW5nIG9m IHNvbWUga2V5IG1hdGVyaWFsLg0KLT1SDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJMdWJhc2hl diwgSWdvciIgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+ Pg0KRGF0ZTogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggYXQgNDo1NSBQTQ0KVG86IE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpA Z21haWwuY29tPj4sIFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2 YXNpbHZ2QGdvb2dsZS5jb20+PiwgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpx dWljQGlldGYub3JnPj4NCg0KU3ViamVjdDogUkU6IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9u IElEIHNpemUNCg0KSSB0aGluayB0aGUgaWRlYSBpcyB0aGF0IHRoZSBrZXkgdXNlZCB0byBlbmNy eXB0IGNvbm5lY3Rpb24gSUQgaXMga25vd24gdG8gYm90aCB0aGUgc2VydmVyIGFuZCB0aGUgcm91 dGVyLiAgVGhhdCBrZXkgd291bGQgbmVlZCB0byBiZSByb3RhdGVkIHBlcmlvZGljYWxseSwgYW5k IHRoZSByb3V0ZXIgd291bGQgbmVlZCB0byB1bmRlcnN0YW5kIHdoaWNoIGtleSB3YXMgdXNlZCBm b3IgdGhpcyBwYXJ0aWN1bGFyIGNvbm5lY3Rpb24sIGJ1dCB0aGF0IGNhbiBiZSBzb2x2ZWQuDQoN CkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5j b208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAx MSwgMjAxOCA3OjI1IFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208 bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PjsgVmljdG9yIFZhc2lsaWV2IDx2YXNpbHZ2QGdv b2dsZS5jb208bWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbT4+OyBJRVRGIFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IEluY3JlYXNpbmcg UVVJQyBjb25uZWN0aW9uIElEIHNpemUNCg0KQWN0dWFsbHksIG9uIGVuY3J5cHRpb24gb2YgY29u bmVjdGlvbiBJRCwgdGhpcyBpcyBub3Qgc28gc2ltcGxlLg0KDQpXZSBtdXN0IGFzc3VtZSB0aGVy ZSBpcyBvbmx5IGEgc2luZ2xlIGtleSBmb3IgbWFueSBjb25uZWN0aW9ucyBiZWNhdXNlIHRoZSBy b3V0ZXIgaXMgbm90IHBhcnQgb2YgYSBrZXkgZXhjaGFuZ2UuIFRoaXMgdW5pcXVlIHZhbHVlIG9y IGNvdW50ZXIgdXNlZCBmb3IgZW5jcnlwdGluZyBhIHNpbmdsZSBibG9jayBjYW5ub3QgYmUgdGhl IHNhbWUgZm9yIHR3byBkaWZmZXJlbnQgY29ubmVjdGlvbnMgSUTigJlzLCBidXQgaXQgY2FuIGJl IHB1YmxpYy4gVGhpcyBtZWFucyB0aGF0IGl0IG11c3QgYmUgc3RvcmVkIGluIHRoZSBwYWNrZXQg aGVhZGVyLiBBbmQsIGFzIGl0IHR1cm5zIG91dCwgcmFuZG9tIGNvbm5lY3Rpb24gSUQgY2hvc2Vu IGJ5IGEgdHJ1c3RlZCBzb3VyY2UsIGNhbiBiZSB1c2VkIGZvciBzdWNoIGEgdW5pcXVlIHZhbHVl LiBCdXQgdGhlbiBpdCBtdXN0IGJlIHVzZWQgdG8gZW5jcnlwdCBhbmQvb3IgYXV0aGVudGljYXRl IHNvbWV0aGluZyBlbHNlIGNhcnJ5aW5nIHRoZSBhY3R1YWwgcm91dGluZyBpbmZvcm1hdGlvbi4g U28gbm93IHlvdSBzdGFydCB0byByZWFsbHkgbmVlZCBzb21lIGV4dHJhIHBheWxvYWQuDQoNCkFs dGVybmF0aXZlbHkgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMgZW50aXJlbHkgcmFuZG9tIHN1 Y2ggYXMgY29udGVudCBoYXNoZWQgcm91dGluZy4gVGhlbiB5b3Ugb25seSBuZWVkIHRvIGF1dGhl bnRpY2F0ZSB0aGUgcm91dGluZyBkYXRhLiBZb3UgY2FuIGRvIHRoYXQgd2l0aCBhIEhNQUMsIGFu ZCBDTUFDIGNvdWxkIHByb2JhYmx5IGFsc28gd29yay4gVGhlIGFkZGl0aW9uYWwgYmVuZWZpdCBp cyB0aGF0IHlvdSBjYW4gcHJvYmFibHkgZ2V0IGF3YXkgd2l0aCA2NC1iaXRzIGZvciBhbGwgcm91 dGluZyBpbmZvcm1hdGlvbiBwb3NzaWJseSBpbmNsdWRpbmcgdGhlIGF1dGggdGFnLiBTYXkgNDgg Yml0cyBvZiByb3V0aW5nIGRhdGEgYW5kIDE2IGJpdHMgb2YgYXV0aCB0YWcuDQoNCktpbmQgUmVn YXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiAxMiBKYW51YXJ5IDIwMTgg YXQgMDAuNTcuMjEsIEx1YmFzaGV2LCBJZ29yIChpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzpp bHViYXNoZUBha2FtYWkuY29tPikgd3JvdGU6DQpJIGFtIGludGVyZXN0ZWQgaW4gZXhwbG9yaW5n IHRoaXMgcHJvcG9zYWwsIHNpbmNlIGl0IGFsbG93cyBmb3IgbW9yZSBmbGV4aWJsZSBzY2hlbWVz IG9mIGVuY29kaW5nIHJvdXRpbmcgbWV0YWRhdGEgYW5kIGEgY2hlY2tzdW0uICBJIHdvdWxkIGFs c28gbGlrZSB0byBiZSBleHBsaWNpdCBhYm91dCB0aGUgY29ubmVjdGlvbiBJRCBzaXplIGluIGEg cGFja2V0IGhlYWRlciwgdGhvdWdoLCBzaW5jZSBpdCBncmVhdGx5IHNpbXBsaWZpZXMgdGhlIGlt cGxlbWVudGF0aW9uLg0KDQoNCiAgKiAgIElnb3INCkZyb206IFZpY3RvciBWYXNpbGlldiBbbWFp bHRvOnZhc2lsdnZAZ29vZ2xlLmNvbTxtYWlsdG86dmFzaWx2dkBnb29nbGUuY29tPl0NClNlbnQ6 IFRodXJzZGF5LCBKYW51YXJ5IDExLCAyMDE4IDY6MTYgUE0NClRvOiBJRVRGIFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogSW5jcmVhc2luZyBR VUlDIGNvbm5lY3Rpb24gSUQgc2l6ZQ0KDQpIaSBldmVyeW9uZSwNCg0KSW4gdGhlIGN1cnJlbnQg dmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVjdGlvbiBJRCBzaXplIGlzIGZpeGVkIHRvIGJlIGEg NjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhhdCBpcyBzZXQgYXMgYW4gaW52YXJpYW50IGluIHRo ZSBwcm90b2NvbC4NCg0KSeKAmXZlIGxvb2tlZCBpbnRvIHBvc3NpYmlsaXR5IG9mIHVzaW5nIGEg Y29ubmVjdGlvbiBJRCB0byBlbmNvZGUgdGhlIHNwZWNpZmljIHNlcnZlciBkZXRhaWxzIGludG8g aXQgKHRvIHByb3ZpZGUgc3RhYmlsaXR5IG9mIHRoZSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgbG9h ZCBiYWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBCR1AgZmxhcHMgZm9yIGFueWNhc3QgSVBz KSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkga25ldyB3 ZXJlIGludGVyZXN0ZWQgaW4gdGhpcy4gIEl0IHNlZW1zIGxpa2UgNjQgYml0cyBtaWdodCBiZSB0 b28gc21hbGwgZm9yIHRoaXMgcHVycG9zZSwgYW5kIHdlIG1pZ2h0IHdhbnQgdG8gbGVhdmUgYW4g b3Bwb3J0dW5pdHkgdG8gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIHNpemUuDQoNClRoZSBiYXNp YyBpZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0bzoNCg0KICAxLiAgU3RvcmUgc29t ZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0aW9uIElELg0KICAyLiAgSGF2ZSBzb21l IGVudHJvcHkgdGhhdCBhbGxvd3MgZGlzdGluZ3Vpc2ggdXNlcnMgd2l0aCBpZGVudGljYWwgcm91 dGluZyBtZXRhZGF0YS4NCiAgMy4gIEhhdmUgYSBjaGVja3N1bSB0byBlbnN1cmUgdGhlIHZhbGlk aXR5IG9mIHJvdXRpbmcgaW5mb3JtYXRpb24NCiAgNC4gIEVuY3J5cHQgdGhlIGluZm9ybWF0aW9u IGFib3ZlIHRvIHByZXZlbnQgZGlzY2xvc2luZyB0aGUgcm91dGUgaW5mb3JtYXRpb24gYW5kIGFs bG93IGdlbmVyYXRpbmcgdW5jb3JyZWxhdGFibGUgY29ubmVjdGlvbiBJRHMuDQpUaGVyZSBhcmUg dHdvIHVuZGVybHlpbmcgaXNzdWVzIGhlcmUuICBUaGUgZmlyc3QgcHJvYmxlbSBpcyB0aGF0IGFs bCBvZiB0aGlzIGRvZXMgbm90IGZpdCB3ZWxsIGludG8gNjQgYml0cywgYW5kIHlvdSBoYXZlIHRv IHNlcmlvdXNseSBjb21wcm9taXNlIG9uIHRoZSBzdHJlbmd0aCBvZiB0aGUgY2hlY2tzdW0gKHdo aWNoIGlzIGJhZCBlc3BlY2lhbGx5IGlmIHlvdSB3YW50IGl0IHRvIGJlIGEgTUFDIHJhdGhlciB0 aGFuIGEgY2hlY2tzdW0pLiAgVGhlIHNlY29uZCBwcm9ibGVtIGlzIHRoYXQgZW5jcnlwdGluZyA2 NC1iaXQgdmFsdWVzIGZhc3QgaXMgYWN0dWFsbHkgZmFpcmx5IGhhcmQgc2luY2UgdGhlIGJsb2Nr IGNpcGhlcnMgZWFzaWx5IGF2YWlsYWJsZSBpbiBoYXJkd2FyZSBoYXZlIDEyOC1iaXQgYmxvY2sg c2l6ZSwgYW5kIHRoZSBwZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgb24gbG9hZCBiYWxhbmNlcnMg YXJlIHRpZ2h0ZXIgdGhhbiBvbiBzZXJ2ZXJzLg0KDQpJbiBvdGhlciB3b3JkcywgaGF2aW5nIGEg MTI4LWJpdCBjb25uZWN0aW9uIElEIHByb3ZpZGVzIGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8g Z2VuZXJhdGUgdW5saW5rYWJsZSBjb25uZWN0aW9uIElEcyBvbiBtaWdyYXRpb24uDQoNClNvLCB0 aGUgcHJvYmxlbSB3ZeKAmXJlIHRyeWluZyB0byBzb2x2ZSBpcyB0aGF0IHRoZSBjb25uZWN0aW9u IElEIGlzIHRvbyBzbWFsbC4gIFRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIEkgYmVsaWV2ZSB0aGUg d29ya2luZyBncm91cCBzaG91bGQgYW5zd2VyIGF0IHRoaXMgcG9pbnQ6DQoNCiAgMS4gIERvIHdl IHdhbnQgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBzdGFuZGFyZGl6 YXRpb24gcHJvY2Vzcz8NCiAgMi4gIElmIHdlIGRvbuKAmXQgYWRkcmVzcyB0aGlzIHByb2JsZW0g cmlnaHQgbm93LCBob3cgZG8gd2Ugc3RydWN0dXJlIHRoZSBzdGFuZGFyZCBpbiBhIHdheSB0aGF0 IHdlIGNhbiBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQgaW4gdGhlIGZ1dHVyZT8NClRoZXJlIGFy ZSBtdWx0aXBsZSB3YXlzIHRvIHNvbHZlIHRoZSBwcm9ibGVtIG9mIG1ha2luZyBjb25uZWN0aW9u IElEIGxhcmdlci4gIE9uZSBpcyB0byBqdXN0IGFkZCBleHRyYSBiaXQgdG8gdGhlIOKAnG9taXQg Y29ubmVjdGlvbiBJROKAnSBmaWVsZCB0byBhbGxvdyAxMjgtYml0IGNvbm5lY3Rpb24gSURzLiAg QW5vdGhlciBhcHByb2FjaCBpcyB0byBhbGxvdyBjb25uZWN0aW9uIElEIHNpemUgdG8gYmUgZXhw bGljaXRseSBzcGVjaWZpZWQgYnkgdGhlIHNlcnZlciwgYW5kIHRoZW4gYXNzdW1lIHRoYXQgdGhl IGxvYWQgYmFsYW5jZXIga25vd3MgdGhhdCBzaXplIGFuZCBubyBvbmUgZWxzZSBvbiB0aGUgcGF0 aCBuZWVkcyB0byByZWFkIGl0Lg0KDQpUaGVyZeKAmXMgYWxzbyBhIHF1ZXN0aW9uIG9mIGhvdyBt dWNoIG9mIGNvbm5lY3Rpb24gSURzIGRvIG1pZGRsZWJveGVzIChleGNsdWRpbmcgbG9hZCBiYWxh bmNlcnMgYW5kIG90aGVyIGJveGVzIG93bmVkIGJ5IHRoZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIg Y2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiAgV2UgY291bGQgZ28gZm9yIGJvdGgg4oCc bWlkZGxlYm94ZXMgc2hvdWxkIGJlIGFsd2F5cyBhYmxlIHRvIHJlYWQgdGhlIGVudGlyZSBJROKA nSBhbmQg4oCcbWlkZGxlYm94ZXMgc2hvdWxkIG5vdCByZWFkIGNvbm5lY3Rpb24gSURzIGF0IGFs bCBvcHRpb25z4oCdLCBidXQgSSB0aGluayB0aGVyZeKAmXMgYWxzbyBhIHJvb20gZm9yIG1vcmUg ZmxleGlibGUgZm9ybXVsYXRpb25zIGxpa2Ug4oCcbWlkZGxlYm94ZXMgYWx3YXlzIGdldCBmaXJz dCA2NCBiaXRzIGFuZCB0aGV5IGhhdmUgdXNlZnVsIGVudHJvcHkgdG8gZGlzdGluZ3Vpc2ggY29u bmVjdGlvbnPigJ0uDQoNCiAgLS0gVmljdG9yLg0KDQo= --_000_346D256C5D644EB48AA1C16ACEB7B704fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <8A84E488425CC044AB650CE409A443F0@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubS0yMjQ2OTQ2MDI1NDAwNjIyMzY0YWlybWFpbG9uLCBsaS5tLTIy NDY5NDYwMjU0MDA2MjIzNjRhaXJtYWlsb24sIGRpdi5tLTIyNDY5NDYwMjU0MDA2MjIzNjRhaXJt YWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8tMjI0Njk0NjAyNTQwMDYyMjM2NGFpcm1haWxvbjsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjk2MTIyNDQwMzsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6MTkyNDkyNTc0MDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNDY0 MzQ1ODk3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE4NzczODg4NDt9DQpAbGlzdCBsMTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyDQoJe21zby1saXN0LWlkOjIxMDI5NDkxMDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjY1MzgwMzQyMDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90 dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZdXAhPGJyPg0KSWYgeW914oCZcmUgcGFy YW5vaWQsIHlvdSBjYW4gZW5jcnlwdCB0d2ljZTogT25lIGxlc3Mtc2VjdXJlIGtleSB3aGljaCBh bGxvd3MgZGVjcnlwdGlvbiBvZiB0aGUga2V5IElEIGJpdHMgKGFuZCB0aGUgcmVzdCBvZiB0aGUg Yml0cywgd2hpY2ggYXJlIGFsb25nIGZvciB0aGUgcmlkZSksIGFuZCB0aGVuIGFub3RoZXIga2V5 IChpbmRpY2F0ZWQgYnkgdGhlIGZpcnN0KSB3aGljaCBhbGxvd3MgZGVjcnlwdGlvbiBhbmQgc3Vi c2VxdWVudCBpbnRlcnByZXRhdGlvbg0KIG9mIGVuY29kaW5nIG9mIHRoZSB0aGUgTDcgYWRkcmVz cyAocGx1cyBzYWx0IHNvbWV3aGVyZSBpbiB0aGVyZSkgaW50byB0aGUgcmVtYWluaW5nIGJpdHMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpVbHRpbWF0ZWx5LCBr bm93aW5nIGEgc2NoZW1lIGlzIHBvc3NpYmxlIGlzIHN1ZmZpY2llbnQgaGVyZSBzbyBsb25nIGFz IHdlIGRlbGVnYXRlIGNvbm5JRCBhc3NpZ25tZW50IHRvIHRoZSBzZXJ2ZXIuPGJyPg0KLT1SPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+SmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggYXQgNTowOSBQTTxicj4NCjxiPlRvOiA8 L2I+Um9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVv dDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDssIE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDssIFZpY3RvciBW YXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0OywgSUVURiBRVUlDIFdHICZsdDtxdWlj QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogSW5jcmVhc2luZyBRVUlDIGNv bm5lY3Rpb24gSUQgc2l6ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0aGlua2luZyBhbG91ZCBhYm91dCBrZXkgcm90YXRp b24gLS0geW91IGNvdWxkIGFsd2F5cyB1c2UgdGhlIGhpZ2gtb3JkZXIgYml0IGFzIGFuIGV4cGlj aXQga2V5IHNlbGVjdGlvbiBiaXQuLi4gdGhlIHNlcnZlciBhbmQgbG9hZCBiYWxhbmNlciBjYW4g dGhlbiB1c2UgdGhpcyBiaXQgZHVyaW5nIHJvdGF0aW9uIHRvIGNoYW5nZSBrZXlzIHdpdGhvdXQg YnJlYWthZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVGh1LCBKYW4gMTEsIDIwMTggYXQgNTowNSBQTSwgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVm PSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkNvcnJlY3QvYWdyZWVkLiBUaGUgTDQg4oCYcm91dGVy4oCZIG11 c3QgYmUgYWJsZSB0byBkZWNyeXB0L2ludGVycHJldCB0aGUgZGF0YSBpbiBvcmRlciB0byBhY3Qg dXBvbiBpdC4gVGhpcyByZXF1aXJlcyBzaGFyaW5nIG9mIHNvbWUga2V5IG1hdGVyaWFsLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tPVI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5pbHViYXNo ZUBha2FtYWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEphbnVhcnkg MTEsIDIwMTggYXQgNDo1NSBQTTxicj4NCjxiPlRvOiA8L2I+TWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7LCBWaWN0b3IgVmFzaWxpZXYgJmx0OzxhIGhy ZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNpbHZ2QGdv b2dsZS5jb208L2E+Jmd0OywgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+ U3ViamVjdDogPC9iPlJFOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXplPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlIGlkZWEgaXMgdGhhdCB0aGUga2V5IHVzZWQg dG8gZW5jcnlwdCBjb25uZWN0aW9uIElEIGlzIGtub3duIHRvIGJvdGggdGhlIHNlcnZlciBhbmQg dGhlIHJvdXRlci4mbmJzcDsgVGhhdCBrZXkgd291bGQgbmVlZCB0byBiZSByb3RhdGVkIHBlcmlv ZGljYWxseSwgYW5kIHRoZSByb3V0ZXIgd291bGQNCiBuZWVkIHRvIHVuZGVyc3RhbmQgd2hpY2gg a2V5IHdhcyB1c2VkIGZvciB0aGlzIHBhcnRpY3VsYXIgY29ubmVjdGlvbiwgYnV0IHRoYXQgY2Fu IGJlIHNvbHZlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5taWtrZWxmakBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBK YW51YXJ5IDExLCAyMDE4IDc6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZs dDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmls dWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OzsgVmljdG9yIFZhc2lsaWV2ICZsdDs8YSBocmVmPSJt YWlsdG86dmFzaWx2dkBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmFzaWx2dkBnb29nbGUu Y29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdiBpZD0ibV8tMjI0Njk0NjAyNTQwMDYyMjM2NGJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QWN0dWFsbHksIG9u IGVuY3J5cHRpb24gb2YgY29ubmVjdGlvbiBJRCwgdGhpcyBpcyBub3Qgc28gc2ltcGxlLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tMjI0Njk0NjAyNTQwMDYyMjM2 NGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0y MjQ2OTQ2MDI1NDAwNjIyMzY0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5XZSBtdXN0IGFzc3VtZSB0aGVyZSBpcyBvbmx5IGEgc2lu Z2xlIGtleSBmb3IgbWFueSBjb25uZWN0aW9ucyBiZWNhdXNlIHRoZSByb3V0ZXIgaXMgbm90IHBh cnQgb2YgYSBrZXkgZXhjaGFuZ2UuDQogVGhpcyB1bmlxdWUgdmFsdWUgb3IgY291bnRlciB1c2Vk IGZvciBlbmNyeXB0aW5nIGEgc2luZ2xlIGJsb2NrIGNhbm5vdCBiZSB0aGUgc2FtZSBmb3IgdHdv IGRpZmZlcmVudCBjb25uZWN0aW9ucyBJROKAmXMsIGJ1dCBpdCBjYW4gYmUgcHVibGljLiBUaGlz IG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBzdG9yZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIuIEFuZCwg YXMgaXQgdHVybnMgb3V0LCByYW5kb20gY29ubmVjdGlvbiBJRCBjaG9zZW4gYnkgYSB0cnVzdGVk DQogc291cmNlLCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBhIHVuaXF1ZSB2YWx1ZS4gQnV0IHRoZW4g aXQgbXVzdCBiZSB1c2VkIHRvIGVuY3J5cHQgYW5kL29yIGF1dGhlbnRpY2F0ZSBzb21ldGhpbmcg ZWxzZSBjYXJyeWluZyB0aGUgYWN0dWFsIHJvdXRpbmcgaW5mb3JtYXRpb24uIFNvIG5vdyB5b3Ug c3RhcnQgdG8gcmVhbGx5IG5lZWQgc29tZSBleHRyYSBwYXlsb2FkLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8tMjI0Njk0NjAyNTQwMDYyMjM2NGJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy0yMjQ2OTQ2MDI1NDAw NjIyMzY0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5BbHRlcm5hdGl2ZWx5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGlzIGVudGly ZWx5IHJhbmRvbSBzdWNoIGFzIGNvbnRlbnQgaGFzaGVkIHJvdXRpbmcuIFRoZW4geW91IG9ubHkg bmVlZCB0bw0KIGF1dGhlbnRpY2F0ZSB0aGUgcm91dGluZyBkYXRhLiBZb3UgY2FuIGRvIHRoYXQg d2l0aCBhIEhNQUMsIGFuZCBDTUFDIGNvdWxkIHByb2JhYmx5IGFsc28gd29yay4gVGhlIGFkZGl0 aW9uYWwgYmVuZWZpdCBpcyB0aGF0IHlvdSBjYW4gcHJvYmFibHkgZ2V0IGF3YXkgd2l0aCA2NC1i aXRzIGZvciBhbGwgcm91dGluZyBpbmZvcm1hdGlvbiBwb3NzaWJseSBpbmNsdWRpbmcgdGhlIGF1 dGggdGFnLiBTYXkgNDggYml0cyBvZiByb3V0aW5nIGRhdGEgYW5kDQogMTYgYml0cyBvZiBhdXRo IHRhZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYg aWQ9Im1fLTIyNDY5NDYwMjU0MDA2MjIzNjRibG9vcF9zaWduXzE1MTU3MTYxMzcyMDMzMzM4ODgi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQg UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJtLTIyNDY5NDYwMjU0MDA2MjIzNjRhaXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAx MiBKYW51YXJ5IDIwMTggYXQgMDAuNTcuMjEsIEx1YmFzaGV2LCBJZ29yICg8YSBocmVmPSJtYWls dG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5j b208L2E+KSB3cm90ZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYW0gaW50ZXJl c3RlZCBpbiBleHBsb3JpbmcgdGhpcyBwcm9wb3NhbCwgc2luY2UgaXQgYWxsb3dzIGZvciBtb3Jl IGZsZXhpYmxlIHNjaGVtZXMgb2YgZW5jb2Rpbmcgcm91dGluZyBtZXRhZGF0YQ0KIGFuZCBhIGNo ZWNrc3VtLiZuYnNwOyBJIHdvdWxkIGFsc28gbGlrZSB0byBiZSBleHBsaWNpdCBhYm91dCB0aGUg Y29ubmVjdGlvbiBJRCBzaXplIGluIGEgcGFja2V0IGhlYWRlciwgdGhvdWdoLCBzaW5jZSBpdCBn cmVhdGx5IHNpbXBsaWZpZXMgdGhlIGltcGxlbWVudGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4gVmljdG9yIFZhc2lsaWV2IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhc2lsdnZA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNjoxNiBQTTxicj4NCjxi PlRvOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXplPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5IaSBldmVyeW9uZSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIFFVSUMs IHRoZSBjb25uZWN0aW9uIElEIHNpemUgaXMgZml4ZWQgdG8gYmUgYSA2NC1iaXQgb3BhcXVlIGJs b2IsIGFuZCB0aGF0IGlzIHNldCBhcw0KIGFuIGludmFyaWFudCBpbiB0aGUgcHJvdG9jb2wuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKAmXZl IGxvb2tlZCBpbnRvIHBvc3NpYmlsaXR5IG9mIHVzaW5nIGEgY29ubmVjdGlvbiBJRCB0byBlbmNv ZGUgdGhlIHNwZWNpZmljIHNlcnZlciBkZXRhaWxzIGludG8gaXQgKHRvIHByb3ZpZGUNCiBzdGFi aWxpdHkgb2YgdGhlIGNvbm5lY3Rpb24gaW4gY2FzZSBvZiBsb2FkIGJhbGFuY2luZyBjaGFuZ2Vz LCBlc3BlY2lhbGx5IEJHUCBmbGFwcyBmb3IgYW55Y2FzdCBJUHMpLCBhbmQgaGF2ZSBjaGF0dGVk IGFib3V0IHRoaXMgd2l0aCBvdGhlciBwZW9wbGUgSSBrbmV3IHdlcmUgaW50ZXJlc3RlZCBpbiB0 aGlzLiZuYnNwOyBJdCBzZWVtcyBsaWtlIDY0IGJpdHMgbWlnaHQgYmUgdG9vIHNtYWxsIGZvciB0 aGlzIHB1cnBvc2UsIGFuZCB3ZSBtaWdodCB3YW50DQogdG8gbGVhdmUgYW4gb3Bwb3J0dW5pdHkg dG8gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIHNpemUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGJhc2ljIGlkZWEgaXMgdGhhdCB5b3Ug d2FudCB0byBiZSBhYmxlIHRvOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3Rv cmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0aW9uIElELjwvc3Bhbj48bzpw PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhhdmUgc29tZSBlbnRyb3B5 IHRoYXQgYWxsb3dzIGRpc3Rpbmd1aXNoIHVzZXJzIHdpdGggaWRlbnRpY2FsIHJvdXRpbmcgbWV0 YWRhdGEuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SGF2ZSBhIGNoZWNrc3VtIHRvIGVuc3VyZSB0aGUgdmFsaWRpdHkgb2Ygcm91dGluZyBpbmZvcm1h dGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkVu Y3J5cHQgdGhlIGluZm9ybWF0aW9uIGFib3ZlIHRvIHByZXZlbnQgZGlzY2xvc2luZyB0aGUgcm91 dGUgaW5mb3JtYXRpb24gYW5kIGFsbG93IGdlbmVyYXRpbmcgdW5jb3JyZWxhdGFibGUgY29ubmVj dGlvbiBJRHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJlIHR3byB1bmRl cmx5aW5nIGlzc3VlcyBoZXJlLiZuYnNwOyBUaGUgZmlyc3QgcHJvYmxlbSBpcyB0aGF0IGFsbCBv ZiB0aGlzIGRvZXMgbm90IGZpdCB3ZWxsIGludG8gNjQgYml0cywgYW5kDQogeW91IGhhdmUgdG8g c2VyaW91c2x5IGNvbXByb21pc2Ugb24gdGhlIHN0cmVuZ3RoIG9mIHRoZSBjaGVja3N1bSAod2hp Y2ggaXMgYmFkIGVzcGVjaWFsbHkgaWYgeW91IHdhbnQgaXQgdG8gYmUgYSBNQUMgcmF0aGVyIHRo YW4gYSBjaGVja3N1bSkuJm5ic3A7IFRoZSBzZWNvbmQgcHJvYmxlbSBpcyB0aGF0IGVuY3J5cHRp bmcgNjQtYml0IHZhbHVlcyBmYXN0IGlzIGFjdHVhbGx5IGZhaXJseSBoYXJkIHNpbmNlIHRoZSBi bG9jayBjaXBoZXJzIGVhc2lseSBhdmFpbGFibGUNCiBpbiBoYXJkd2FyZSBoYXZlIDEyOC1iaXQg YmxvY2sgc2l6ZSwgYW5kIHRoZSBwZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgb24gbG9hZCBiYWxh bmNlcnMgYXJlIHRpZ2h0ZXIgdGhhbiBvbiBzZXJ2ZXJzLiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIG90aGVyIHdvcmRz LCBoYXZpbmcgYSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgcHJvdmlkZXMgZm9yIGFuIGVhc3kgc2Vj dXJlIHdheSB0byBnZW5lcmF0ZSB1bmxpbmthYmxlIGNvbm5lY3Rpb24NCiBJRHMgb24gbWlncmF0 aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PlNvLCB0aGUgcHJvYmxlbSB3ZeKAmXJlIHRyeWluZyB0byBzb2x2ZSBpcyB0aGF0IHRoZSBjb25u ZWN0aW9uIElEIGlzIHRvbyBzbWFsbC4mbmJzcDsgVGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgSSBi ZWxpZXZlDQogdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFuc3dlciBhdCB0aGlzIHBvaW50Ojwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0i MSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBs ZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RG8gd2Ugd2FudCB0byBhZGRyZXNzIHRo aXMgcHJvYmxlbSBhdCB0aGlzIHBvaW50IGluIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzPzwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIHdlIGRvbuKA mXQgYWRkcmVzcyB0aGlzIHByb2JsZW0gcmlnaHQgbm93LCBob3cgZG8gd2Ugc3RydWN0dXJlIHRo ZSBzdGFuZGFyZCBpbiBhIHdheSB0aGF0IHdlIGNhbiBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQg aW4gdGhlIGZ1dHVyZT88L3NwYW4+PG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZSBhcmUgbXVs dGlwbGUgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBtYWtpbmcgY29ubmVjdGlvbiBJRCBs YXJnZXIuJm5ic3A7IE9uZSBpcyB0byBqdXN0IGFkZCBleHRyYSBiaXQgdG8gdGhlDQog4oCcb21p dCBjb25uZWN0aW9uIElE4oCdIGZpZWxkIHRvIGFsbG93IDEyOC1iaXQgY29ubmVjdGlvbiBJRHMu Jm5ic3A7IEFub3RoZXIgYXBwcm9hY2ggaXMgdG8gYWxsb3cgY29ubmVjdGlvbiBJRCBzaXplIHRv IGJlIGV4cGxpY2l0bHkgc3BlY2lmaWVkIGJ5IHRoZSBzZXJ2ZXIsIGFuZCB0aGVuIGFzc3VtZSB0 aGF0IHRoZSBsb2FkIGJhbGFuY2VyIGtub3dzIHRoYXQgc2l6ZSBhbmQgbm8gb25lIGVsc2Ugb24g dGhlIHBhdGggbmVlZHMgdG8gcmVhZCBpdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGVyZeKAmXMgYWxzbyBhIHF1ZXN0aW9uIG9mIGhvdyBt dWNoIG9mIGNvbm5lY3Rpb24gSURzIGRvIG1pZGRsZWJveGVzIChleGNsdWRpbmcgbG9hZCBiYWxh bmNlcnMgYW5kIG90aGVyIGJveGVzDQogb3duZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFzIGVpdGhl ciBjbGllbnQgb3Igc2VydmVyKSBuZWVkIHRvIGtub3cuJm5ic3A7IFdlIGNvdWxkIGdvIGZvciBi b3RoIOKAnG1pZGRsZWJveGVzIHNob3VsZCBiZSBhbHdheXMgYWJsZSB0byByZWFkIHRoZSBlbnRp cmUgSUTigJ0gYW5kIOKAnG1pZGRsZWJveGVzIHNob3VsZCBub3QgcmVhZCBjb25uZWN0aW9uIElE cyBhdCBhbGwgb3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGFsc28gYSByb29tIGZv ciBtb3JlIGZsZXhpYmxlDQogZm9ybXVsYXRpb25zIGxpa2Ug4oCcbWlkZGxlYm94ZXMgYWx3YXlz IGdldCBmaXJzdCA2NCBiaXRzIGFuZCB0aGV5IGhhdmUgdXNlZnVsIGVudHJvcHkgdG8gZGlzdGlu Z3Vpc2ggY29ubmVjdGlvbnPigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7IC0tIFZpY3Rvci48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_346D256C5D644EB48AA1C16ACEB7B704fbcom_-- From nobody Thu Jan 11 17:28:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959812D574 for ; Thu, 11 Jan 2018 17:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4EaUzH5f7gHx for ; Thu, 11 Jan 2018 17:28:33 -0800 (PST) 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 8F281126BF0 for ; Thu, 11 Jan 2018 17:28:33 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0C1Ri1Q027121; Fri, 12 Jan 2018 01:28:29 GMT 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=Has/VyL5GOyk5QcR6MxVyEYAw/EseCcj8VU5VECtt2Y=; b=KBaLZNkRZM33x9/xZL5Dv0BU2hp1dJMsUymB4hW+MkkeIo/dMuqT9ICZyMFXL5gfo4/h qKnFVmsmKMaorF72hhol2Y5zs+E54dksZItR+du2jPpxvOmmsAjGSvmVDsPnQK/xAMUV +wLZ5sHzsL+NXwJwMaz16F8mb1xu/SLD5/+vESLQGKucZ8LT/hV0CUJiuktH6RNhTyBV VWgC5JY84SJjK3epDLAJQ9jxerHbx/vsinAAP+4mAaAc2QhHivOYwA5JgxGdUj7xUBsH GlCqQISqSIQzVayZVGWIBBs3CAaMOIflN9uKuKgcxImEM8Ci9MmRTomKbbsay7km9ye9 sQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2fda9fhr00-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 01:28:28 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0C1PqpF013109; Thu, 11 Jan 2018 20:28:27 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fatnyrt0a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 11 Jan 2018 20:28:26 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb3.msg.corp.akamai.com (172.27.123.58) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 11 Jan 2018 20:28:26 -0500 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, 11 Jan 2018 20:28:25 -0500 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, 11 Jan 2018 20:28:25 -0500 From: "Lubashev, Igor" To: Roberto Peon , Jana Iyengar CC: QUIC WG , Martin Thomson Subject: RE: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidqwSZojuevrjEKuWaFfJc7FkKNt4tSAgAHcoQCAAALNgP//rUOw Date: Fri, 12 Jan 2018 01:28:25 +0000 Message-ID: References: <18061ACE-08F7-4219-81E6-0B73BBC56170@fb.com> In-Reply-To: <18061ACE-08F7-4219-81E6-0B73BBC56170@fb.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.88] Content-Type: multipart/alternative; boundary="_000_a891c4d345e446e3b172c7a9d7e815b3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-11_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120015 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 01:28:37 -0000 --_000_a891c4d345e446e3b172c7a9d7e815b3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHJhbnNwb3J0IGNhbm5vdCBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBkZWFkbG9ja2luZyBkdWUgdG8g YSBoaWdoZXIgcHJvdG9jb2zigJlzIGRhdGEgcHJpb3JpdHkgb24gaXRzIG93bi4gIFRoZSBhcHBs aWNhdGlvbiB3b3VsZCBuZWVkIHRvIGNvb3BlcmF0ZSBjYXJlZnVsbHkuDQoNClRoZSBwcm9ibGVt IGlzIHRoYXQgaXQgaXMgbm90IG9ubHkgdGhlIHJlY2VpdmVyIHRoYXQgaXMgaW5mbHVlbmNpbmcg ZmxvdyBjb250cm9sLCBiZWNhdXNlIHNlbmRlciB0cmFuc3BvcnQgaGFzIGJ1ZmZlcnMgYXMgd2Vs bC4gIFRoZSBzZW5kZXIgdHJhbnNwb3J0IGNhbiByZWZ1c2UgdG8gYWNjZXB0IGhpZ2hlci1wcmlv cml0eSBkYXRhIGZyb20gdGhlIGFwcGxpY2F0aW9uLCBpZiBpdHMgYnVmZmVycyBhcmUgYWxyZWFk eSBmdWxsIHdpdGggbG93ZXItcHJpb3JpdHkgZGF0YS4NCg0KU28geW91IGNhbiBlbmQgdXAgd2l0 aCByZWNlaXZlciByZWZ1c2luZyB0byBncmFudCBhZGRpdGlvbmFsIGNyZWRpdHMgZm9yIHN0cmVh bSBZIChiZWNhdXNlIGl0IGNhbm5vdCBwcm9jZXNzIHN0cmVhbSBZIHcvbyBzdHJlYW0gWCkuICBJ ZiB0aGUgc2VuZGVy4oCZcyBidWZmZXJzIGFyZSBmdWxsIG9mIHN0cmVhbSBZIGRhdGEsIGl0IGNh bm5vdCBzZW5kIHRoYXQgZGF0YSBhbmQgY2Fubm90IGFjY2VwdCBhbnkgYWRkaXRpb25hbCBkYXRh IChmb3Igc3RyZWFtIFgpLg0KDQpUaGUgYXBwbGljYXRpb24gbXVzdCBiZSBjYXJlZnVsIG5vdCB0 byBlbnF1ZXVlIHN0cmVhbSBZIGRhdGEgdG8gdGhlIHRyYW5zcG9ydCBiZWZvcmUgaXQgZW5xdWV1 ZXMgYWxsIGRhdGEgZnJvbSBzdHJlYW0gWCB0aGF0IHN0cmVhbSBZIGRhdGEgZGVwZW5kcyBvbi4N Cg0KDQogICogICBJZ29yDQoNCg0KRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhAZmIu Y29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggODowMyBQTQ0KVG86IEphbmEg SXllbmdhciA8anJpQGdvb2dsZS5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1h cnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogRGVh ZGxvY2tpbmcgaW4gdGhlIHRyYW5zcG9ydA0KDQpUaGUgcmVjZWl2ZXIgd291bGQgYmUgdGhlIG9u ZSB0byBwcm92aWRlIHRoZSBvdmVycmlkZTsgVGhlIHNlbmRlciBjb3VsZCBoaW50IHRvIHRoZSBy ZWNlaXZlciB0aGF0IGl0IHNob3VsZCB3aXNoIHRoaXMgYnkgc2lnbmFsaW5nIGl0IGlzIGJsb2Nr ZWQgKG9yIGRlYWRsb2NrZWQpIG9uIGZsb3cgY29udHJvbC4NCi09Ug0KDQpGcm9tOiBKYW5hIEl5 ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+DQpEYXRlOiBUaHVy c2RheSwgSmFudWFyeSAxMSwgMjAxOCBhdCA0OjUzIFBNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5p eEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+DQpDYzogTWFydGluIFRob21zb24gPG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4sIFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6 IERlYWRsb2NraW5nIGluIHRoZSB0cmFuc3BvcnQNCg0KUm9iZXJ0bywNCg0KSSdtIG5vdCBjb252 aW5jZWQgdGhhdCB3ZSBuZWVkIHNvbWV0aGluZyBhcyBoZWF2eS13ZWlnaHQgYXMgdGhpcy4uLiBz cGVjaWZpY2FsbHksIGZsb3cgY29udHJvbCBzbyBmYXIgaGFzIGJlZW4gaW4gdGhlIHJlY2VpdmVy J3MgY29udHJvbCwgd2hpY2ggaXMgYWxzbyB0aGUgdGhpbmcgdGhhdCBvd25zIHRoZSByZXNvdXJj ZSBpdCBpcyB0cnlpbmcgdG8gbGltaXQgZXhoYXVzdGlvbiBvZi4gVGhpcyBtb3ZlcyBpdCBvdXQg dG8gdGhlIHNlbmRlciwgd2hpY2ggd291bGQgcmVxdWlyZSBhIHJlY2VpdmVyIHRvIG5vdyBjb21t aXQgbWVtb3J5IGJhc2VkIG9uIHdoYXQgYSBzZW5kZXIgYmVsaWV2ZXMgaXMgaW1wb3J0YW50LiBS ZWFzb25pbmcgYWJvdXQgdGhpcyBzZWVtcyBub24tdHJpdmlhbC4gSSB3b3JyeSBhYm91dCBob3cg YWxsIHRoaXMgZGVncmVlIG9mIGZyZWVkb20gd2lsbCBnZXQgYWJ1c2VkLCBhbmQgcG90ZW50aWFs IHNoYXJwIGVkZ2VzLg0KDQpJZiB3ZSBjYW4gZW5zdXJlIHByaW9yaXR5IGNvbnN1bXB0aW9uIG9m IHRoZSBzaGFyZWQgcmVzb3VyY2UsIHRoYXQgc2VlbXMgYWRlcXVhdGUgdG8gcmVzb2x2ZSB0aGUg cHJvYmxlbSBvbiBoYW5kLiBEbyB5b3UgdGhpbmsgc29tZXRoaW5nIG1vcmUgaXMgcmVxdWlyZWQ/ DQoNCi0gamFuYQ0KDQpPbiBXZWQsIEphbiAxMCwgMjAxOCBhdCAxMjoyNiBQTSwgUm9iZXJ0byBQ ZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0KQW5vdGhlciBv cHRpb246DQpBbGxvdyBhIGZsb3ctY29udHJvbCDigJhvdmVycmlkZeKAmSB3aGljaCBhbGxvd3Mg YSByZWNlaXZlciB0byBzdGF0ZSB0aGF0IHRoZXkgcmVhbGx5IHdhbnQgZGF0YSBvbiBhIHBhcnRp Y3VsYXIgc3RyZWFtLCBhbmQgaWdub3JlIHRoZSBnbG9iYWwgZmxvdyBjb250cm9sIGZvciB0aGlz Lg0KDQpIb3cgeW914oCZZCBkbyBpdDoNCkEgcmVjZWl2ZXIgY2FuIHNlbmQgYSBmbG93LWNvbnRy b2wgb3ZlcnJpZGUgZm9yIGEgc3RyZWFtLiBUaGlzIGluY2x1ZGVzIHRoZSBzdHJlYW0gaWQgdG8g d2hpY2ggdGhlIGdsb2JhbCB3aW5kb3cgdGVtcG9yYXJpbHkgZG9lcyBub3QgYXBwbHksIHRoZSBy ZWNlaXZlcuKAmXMgY3VycmVudCBzdHJlYW0gZmxvdy1jb250cm9sIG9mZnNldCwgYW5kIHRoZSBv ZmZzZXQgdGhlIHJlY2VpdmVyIHdvdWxkIHdpc2ggdG8gYmUgYWJsZSB0byByZWNlaXZlLg0KQSBy ZWNlaXZlciBtdXN0IGNvbnRpbnVlIHRvIChyZSlzZW5kIHRoZSBvdmVycmlkZSAoaS5lLiByZXht aXQpIHVudGlsIGl0IGlzIGFja+KAmWQuIEl0IGNhbm5vdCBzZW5kIG90aGVyIGZsb3ctY29udHJv bCBmb3IgdGhhdCBzdHJlYW0gdW50aWwgdGhlIG92ZXJyaWRlIGlzIGFja+KAmWQuDQpUaHVzOg0K ICBnbG9iYWwtZmxvdy1jb250cm9sLW92ZXJyaWRlOiA8c3RyZWFtLWlkPiA8Y3VycmVudC1mbG93 LWNvbnRyb2wtb2Zmc2V0PiwgPG92ZXJyaWRlLWZsb3ctY29udHJvbC1vZmZzZXQ+DQoNClRoZSBz ZW5kZXIgKHdoaWNoIHJlY2VpdmVzIHRoZSBvdmVycmlkZSkgY3JlZGl0cyB0aGUgZ2xvYmFsIGZs b3cgY29udHJvbCB3aXRoIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIGRhdGEgc2VudCBiZXlv bmQgdGhlIHJlY2VpdmVycyBjdXJyZW50bHkta25vd24gZmxvdy1jb250cm9sIG9mZnNldCB1cG9u IHJlY2VpcHQgb2YgdGhlIG92ZXJyaWRlLg0KVGhpcyBzeW5jaHJvbml6ZXMgdGhlIGdsb2JhbCBz dGF0ZSBiZXR3ZWVuIHRoZSByZWNlaXZlciBhbmQgdGhlIHNlbmRlci4NClRoZSBzZW5kZXIgY2Fu IHRoZW4gc2VuZCB0aGUgZGF0YSBvbiB0aGUgc3RyZWFtICh3aXRob3V0IHRvdWNoaW5nIGFueSBv dGhlciBmbG93IGNvbnRyb2wgZGF0YSkuDQoNCldoeToNClRoaXMgYWxsb3dzIGZvciBhIHJlY2Vp dmVyIHRvIHJlc29sdmUgcHJpb3JpdHkgaW52ZXJzaW9ucyB3aGljaCB3b3VsZCBvdGhlcndpc2Ug bGVhZCB0byBkZWFkbG9jaywgZXZlbiB3aGVuIHRoZSBkYXRhL2RlcCBsZWFkaW5nIHRvIHRoaXMg d2FzIG5vdCBrbm93biB0byB0aGUgdHJhbnNwb3J0LiBUaGlzIGV4dGVuZHMgYmV5b25kIHN1Y2gg aXNzdWVzIGJleW9uZCBqdXN0IGhlYWRlciBjb21wcmVzc2lvbi4NCg0KU2luY2UgdGhlIGdsb2Jh bCBmbG93LWNvbnRyb2wgZXhpc3RzIHRvIHByb3RlY3QgdGhlIGFwcCBmcm9tIHJlc291cmNlIGV4 aGF1c3Rpb24sIHRoaXMgcG9zZXMgbm8gYWRkaXRpb25hbCByaXNrIHRvIHRoZSBhcHBsaWNhdGlv bi4NClNpbXBseSBpbmNyZWFzaW5nIHRoZSBnbG9iYWwgZmxvdyBjb250cm9sIHByb3ZpZGVzIGxl c3Mgc3Ryb25nIGd1YXJhbnRlZXPigJRhbnkgc3RyZWFtIG1pZ2h0IGNvbnN1bWUgaXQsIHdoaWNo IGRvZXNu4oCZdCByZXNvbHZlIHRoZSBkZXAgaW52ZXJzaW9uLiBSZWppZ2dlcmluZyBwcmlvcml0 aWVzIGNhbiBoZWxwIHRvIHJlc29sdmUgdGhpcywgYnV0IHdvdWxkIHJlcXVpcmUgdGhlIHNlbmRl ciB0byBzZW5kIHByaW9yaXRpZXMgdG8gdGhlIGNsaWVudCwgd2hpY2ggaXMgcHJvYmxlbWF0aWMg dy5yLnQucmFjZXMgYW5kIGp1c3QgYSB3ZWIgb2YgaWNrLg0KDQpIYXZpbmcgYSBjdXN0b20gZnJh bWUgdHlwZSBpcyBhbHNvIGEgbGVzcyBzdHJvbmcgZ3VhcmFudGVlIGFzIGl0IHJlcXVpcmVzIHRo ZSBrbm93bGVkZ2UgdGhhdCB0aGUgZGVwIGV4aXN0cyB0byBiZSBwcmVzZW50IGF0IHRoZSB0aW1l IG9mIHNlbmRpbmcsIHdoaWNoIGlzIG9mdGVuIGltcG9zc2libGUuDQoNCi09Ug0KDQpPbiAxLzkv MTgsIDEwOjE3IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2YgTWFydGluIFRob21zb24iIDxxdWljLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29t Pj4gd3JvdGU6DQoNCiAgICBCdWlsZGluZyBhIGNvbXBsZXggYXBwbGljYXRpb24gcHJvdG9jb2wg b24gdG9wIG9mIFFVSUMgY29udGludWVzIHRvDQogICAgcHJvZHVjZSBzdXJwcmlzZXMuDQoNCiAg ICBUb2RheSBpbiB0aGUgaGVhZGVyIGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIG1lZXRpbmcgd2Ug ZGlzY3Vzc2VkIGENCiAgICBkZWFkbG9ja2luZyBpc3N1ZSB0aGF0IEkgdGhpbmsgd2FycmFudHMg c2hhcmluZyB3aXRoIHRoZSBsYXJnZXIgZ3JvdXAuDQogICAgVGhpcyBoYXMgaW1wbGljYXRpb25z IGZvciBob3cgcGVvcGxlIGJ1aWxkIGEgUVVJQyB0cmFuc3BvcnQgbGF5ZXIuICBJdA0KICAgIG1p Z2h0IG5lZWQgY2hhbmdlcyB0byB0aGUgQVBJIHRoYXQgaXMgZXhwb3NlZCBieSB0aGF0IGxheWVy Lg0KDQogICAgVGhpcyBpc24ndCByZWFsbHkgdGhhdCBuZXcsIGJ1dCBJIGRvbid0IHRoaW5rIHdl J3ZlIHByb3Blcmx5IGFkZHJlc3NlZA0KICAgIHRoZSBwcm9ibGVtLg0KDQoNCiAgICAjIyBUaGUg QmFzaWMgUHJvYmxlbQ0KDQogICAgSWYgYSBwcm90b2NvbCBjcmVhdGVzIGEgZGVwZW5kZW5jeSBi ZXR3ZWVuIHN0cmVhbXMsIHRoZXJlIGlzIGENCiAgICBwb3RlbnRpYWwgZm9yIGZsb3cgY29udHJv bCB0byBkZWFkbG9jay4NCg0KICAgIFNheSB0aGF0IEkgc2VuZCBYIG9uIHN0cmVhbSAzIGFuZCBZ IG9uIHN0cmVhbSA3LiAgUHJvY2Vzc2luZyBZDQogICAgcmVxdWlyZXMgdGhhdCBYIGlzIHByb2Nl c3NlZCBmaXJzdC4NCg0KICAgIFggY2Fubm90IGJlIHNlbnQgZHVlIHRvIGZsb3cgY29udHJvbCBi dXQgWSBpcyBzZW50LiAgVGhpcyBpcyBhbHdheXMNCiAgICBwb3NzaWJsZSBldmVuIGlmIFggaXMg YXBwcm9wcmlhdGVseSBwcmlvcml0aXplZC4gIFRoZSByZWNlaXZlciB0aGVuDQogICAgbGVhdmVz IFkgaW4gaXRzIHJlY2VpdmUgYnVmZmVyIHVudGlsIFggaXMgcmVjZWl2ZWQuDQoNCiAgICBUaGUg cmVjZWl2ZXIgY2Fubm90IGdpdmUgZmxvdyBjb250cm9sIGNyZWRpdCBmb3IgY29uc3VtaW5nIFkg YmVjYXVzZQ0KICAgIGl0IGNhbid0IGNvbnN1bWUgWSB1bnRpbCBYIGlzIHNlbnQuICBCdXQgdGhl IHNlbmRlciBuZWVkcyBmbG93IGNvbnRyb2wNCiAgICBjcmVkaXQgdG8gc2VuZCBYLiAgV2UgYXJl IGRlYWRsb2NrZWQuDQoNCiAgICBJdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSBzdHJlYW0g b3IgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgaXMNCiAgICBjYXVzaW5nIHRoZSBwcm9ibGVtLCBl aXRoZXIgcHJvZHVjZXMgdGhlIHNhbWUgcmVzdWx0Lg0KDQogICAgKFRvIGdpdmUgc29tZSBiYWNr Z3JvdW5kIG9uIHRoaXMsIHdlIHdlcmUgY29uc2lkZXJpbmcgYSBwcmVmYWNlIHRvDQogICAgaGVh ZGVyIGJsb2NrcyB0aGF0IGlkZW50aWZpZWQgdGhlIGhlYWRlciB0YWJsZSBzdGF0ZSB0aGF0IHdh cw0KICAgIG5lY2Vzc2FyeSB0byBwcm9jZXNzIHRoZSBoZWFkZXIgYmxvY2suICBUaGlzIHdvdWxk IGFsbG93IGZvcg0KICAgIGNvbmN1cnJlbnQgcG9wdWxhdGlvbiBvZiB0aGUgaGVhZGVyIHRhYmxl IGFuZCBzZW5kaW5nIG1lc3NhZ2UgdGhhdA0KICAgIGRlcGVuZGVkIG9uIHRoZSBoZWFkZXIgdGFi bGUgc3RhdGUgdGhhdCBpcyB1bmRlciBjb25zdHJ1Y3Rpb24uICBBDQogICAgcmVjZWl2ZXIgd291 bGQgcmVhZCB0aGUgaWRlbnRpZmllciBhbmQgdGhlbiBsZWF2ZSB0aGUgcmVtYWluZGVyIG9mIHRo ZQ0KICAgIGhlYWRlciBibG9jayBpbiB0aGUgcmVjZWl2ZSBidWZmZXIgdW50aWwgdGhlIGhlYWRl ciB0YWJsZSB3YXMgcmVhZHkuKQ0KDQoNCiAgICAjIyBPcHRpb25zDQoNCiAgICBJdCBzZWVtcyBs aWtlIHRoZXJlIGFyZSBhIGZldyBkZWNlbnQgb3B0aW9ucyBmb3IgbWFuYWdpbmcgdGhpcy4gIFRo ZXNlDQogICAgYXJlIHdoYXQgb2NjdXJyZWQgdG8gbWUgKHRoZXJlIGFyZSBhbG1vc3QgY2VydGFp bmx5IG1vcmUgb3B0aW9ucyk6DQoNCiAgICAxLiBEb24ndCBkbyB0aGF0LiAgV2UgbWlnaHQgY29u Y2VkZSBpbiB0aGlzIGNhc2UgdGhhdCBzZWVraW5nIHRoZQ0KICAgIGluY3JlbWVudGFsIGltcHJv dmVtZW50IHRvIGNvbXByZXNzaW9uIGVmZmljaWVuY3kgaXNuJ3Qgd29ydGggdGhlDQogICAgcmlz ay4gIFRoYXQgaXMsIHdlIG1pZ2h0IG1ha2UgYSBnZW5lcmFsIHN0YXRlbWVudCB0aGF0IHRoaXMg c29ydCBvZg0KICAgIGludGVyLXN0cmVhbSBibG9ja2luZyBpcyBhIGJhZCBpZGVhLg0KDQogICAg Mi4gRm9yY2UgcmVjZWl2ZXJzIHRvIGNvbnN1bWUgZGF0YSBvciByZXNldCBzdHJlYW1zIGluIHRo ZSBjYXNlIG9mDQogICAgdW5mdWxmaWxsZWQgZGVwZW5kZW5jaWVzLiAgVGhlIGZvcm1lciBzZWVt cyBsaWtlIGl0IG1pZ2h0IGJlIHRvbyBtdWNoDQogICAgbGlrZSBtYWdpY2FsIHRoaW5raW5nLCBp biB0aGUgc2Vuc2UgdGhhdCBpdCByZXF1aXJlcyB0aGF0IHJlY2VpdmVycw0KICAgIGNvbmp1cmUg bW9yZSBtZW1vcnkgdXAsIGJ1dCBpZiB0aGUgcmVjZWl2ZXIgd2VyZSByZXF1aXJlZCB0byByZWFk IFkNCiAgICBhbmQgcmVsZWFzZSB0aGUgZmxvdyBjb250cm9sIGNyZWRpdCwgdGhlbiBhbGwgd291 bGQgYmUgZmluZS4gIEZvcg0KICAgIGluc3RhbmNlLCB3ZSBjb3VsZCByZXF1aXJlIHRoYXQgdGhl IHJlY2VpdmVyIHJlc2V0IGEgc3RyZWFtIGlmIGl0DQogICAgY291bGRuJ3QgcmVhZCBhbmQgaGFu ZGxlIGRhdGEuICBJdCBzZWVtcyBsaWtlIGEgYmFkIGFycmFuZ2VtZW50DQogICAgdGhvdWdoOiB5 b3UgZWl0aGVyIGhhdmUgdG8gYWxsb2NhdGUgbW9yZSBtZW1vcnkgdGhhbiB5b3Ugd291bGQgbGlr ZSBvcg0KICAgIHN1ZmZlciB0aGUgdGltZSBhbmQgb3Bwb3J0dW5pdHkgY29zdCBvZiBoYXZpbmcg dG8gZG8gWSBvdmVyLg0KDQogICAgMy4gQ3JlYXRlIGFuIGV4Y2VwdGlvbiBmb3IgZmxvdyBjb250 cm9sLiAgVGhpcyBpcyB3aGF0IEdvb2dsZSBRVUlDDQogICAgZG9lcyBmb3IgaXRzIGhlYWRlcnMg c3RyZWFtLiAgUm9iZXJ0byBvYnNlcnZlZCB0aGF0IHdlIGNvdWxkDQogICAgYWx0ZXJuYXRpdmVs eSBjcmVhdGUgYSBmcmFtZSB0eXBlIHRoYXQgd2FzIGV4Y2x1ZGVkIGZyb20gZmxvdyBjb250cm9s Lg0KICAgIElmIHRoaXMgd2VyZSB1c2VkIGZvciBkYXRhIHRoYXQgaGFkIGRlcGVuZGVuY2llcywg dGhlbiBpdCB3b3VsZCBiZQ0KICAgIGltcG9zc2libGUgdG8gZGVhZGxvY2suICBJdCB3b3VsZCBi ZSBzaW1pbGFybHkgZGlmZmljdWx0IHRvIGFjY291bnQNCiAgICBmb3IgbWVtb3J5IGFsbG9jYXRp b24sIHRob3VnaCBpZiBpdCB3ZXJlIHBvc3NpYmxlIHRvIHByb2Nlc3Mgb24NCiAgICByZWNlaXB0 LCB0aGVuIHRoaXMgKm1pZ2h0KiB3b3JrLiAgV2UnZCBoYXZlIHRvIGRvIHNvbWV0aGluZyB0byBh ZGRyZXNzDQogICAgb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5IHRob3VnaC4gIEl0J3MgcG9zc2libGUg dGhhdCB0aGUgc3RyZWFtDQogICAgYWJzdHJhY3Rpb24gaXMgbm90IGFwcHJvcHJpYXRlIGluIHRo aXMgY2FzZS4NCg0KICAgIDQuIEJsb2NrIHRoZSBwcm9ibGVtIGF0IHRoZSBzb3VyY2UuICBJdCB3 YXMgc3VnZ2VzdGVkIHRoYXQgaW4gY2FzZXMNCiAgICB3aGVyZSB0aGVyZSBpcyBhIHBvdGVudGlh bCBkZXBlbmRlbmN5LCB0aGVuIGl0IGNhbid0IGJlIGEgcHJvYmxlbSBpZg0KICAgIHRoZSB0cmFu c3BvcnQgcmVmdXNlZCB0byBhY2NlcHQgZGF0YSB0aGF0IGl0IGRpZG4ndCBoYXZlIGZsb3cgY29u dHJvbA0KICAgIGNyZWRpdCBmb3IuICBXcml0ZXMgdG8gdGhlIHRyYW5zcG9ydCB3b3VsZCBjb25z dW1lIGZsb3cgY29udHJvbCBjcmVkaXQNCiAgICBpbW1lZGlhdGVseS4gIFRoYXQgd2F5IGFwcGxp Y2F0aW9ucyB3b3VsZCBvbmx5IGJlIGFibGUgdG8gd3JpdGUgWCBpZg0KICAgIHRoZXJlIHdhcyBh IGNoYW5jZSB0aGF0IGl0IHdvdWxkIGJlIGRlbGl2ZXJlZC4gIEFwcGxpY2F0aW9ucyB0aGF0IGhh dmUNCiAgICBvcmRlcmluZyByZXF1aXJlbWVudHMgY2FuIGVuc3VyZSB0aGF0IFkgaXMgd3JpdHRl biBhZnRlciBYIGlzIGFjY2VwdGVkDQogICAgYnkgdGhlIHRyYW5zcG9ydCBhbmQgdGhlcmVieSBh dm9pZCB0aGUgZGVhZGxvY2suICBXcml0ZXMgbWlnaHQgYmxvY2sNCiAgICByYXRoZXIgdGhhbiBm YWlsLCBpZiB0aGUgQVBJIHdhc24ndCBpbnRvIHRoZSB3aG9sZSBub24tYmxvY2tpbmcgSS9PDQog ICAgdGhpbmcuICBUaGUgdHJhbnNwb3J0IG1pZ2h0IHN0aWxsIGhhdmUgdG8gYnVmZmVyIFggZm9y IG90aGVyIHJlYXNvbnMsDQogICAgbGlrZSBjb25nZXN0aW9uIGNvbnRyb2wsIGJ1dCBpdCBjYW4g Z3VhcmFudGVlIHRoYXQgZmxvdyBjb250cm9sIGlzbid0DQogICAgZ29pbmcgdG8gYmxvY2sgZGVs aXZlcnkuDQoNCg0KICAgICMjIE15IFByZWZlcmVuY2UNCg0KICAgIFJpZ2h0IG5vdywgSSdtIGlu Y2xpbmVkIHRvd2FyZCBvcHRpb24gNC4gT3B0aW9uIDEgc2VlbXMgYSBsaXR0bGUgdG9vDQogICAg bXVjaCBvZiBhIGNvbnN0cmFpbnQuICBQcm90b2NvbHMgY3JlYXRlIHRoaXMgc29ydCBvZiBpbnRl ci1kZXBlbmRlbmN5DQogICAgbmF0dXJhbGx5Lg0KDQogICAgVGhlcmUncyBhIGNlcnRhaW4gcHVy aXR5IGluIGhhdmluZyB0aGUgZmxvdyBjb250cm9sIGV4ZXJ0IGJhY2sNCiAgICBwcmVzc3VyZSBh bGwgdGhlIHdheSB0byB0aGUgbmV4dCBsYXllciB1cC4gIE5vdCBiZWluZyBhYmxlIHRvIGJ1aWxk IGENCiAgICB0cmFuc3BvcnQgd2l0aCB1bmNvbnN0cmFpbmVkIHdyaXRlcyBpcyBwb3RlbnRpYWxs eSBjcmVhdGluZw0KICAgIHVuZGVzaXJhYmxlIGV4dGVybmFsaXRpZXMgb24gdHJhbnNwb3J0IHVz ZXJzLiAgTm93IHRoZXkgaGF2ZSB0byB3b3JyeQ0KICAgIGFib3V0IGZsb3cgY29udHJvbCBhcyB3 ZWxsLiAgUGVyc29uYWxseSwgSSdtIGluY2xpbmVkIHRvIHNheSB0aGF0IHRoaXMNCiAgICBpcyBz b21ldGhpbmcgdGhhdCBhcHBsaWNhdGlvbiBwcm90b2NvbHMgYW5kIHRoZWlyIHVzZXJzIHNob3Vs ZCBiZQ0KICAgIGV4cG9zZWQgdG8uICBXZSd2ZSBzZWVuIHdpdGggdGhlIEpTIHN0cmVhbXMgQVBJ IHRoYXQgaXQncyB2YWx1YWJsZSB0bw0KICAgIGhhdmUgYmFjayBwcmVzc3VyZSBhdmFpbGFibGUg YXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGFuZCBhbHNvIGhvdyBpdA0KICAgIGlzIHBvc3NpYmxl IHRvIGRvIHRoYXQgcmVsYXRpdmVseSBlbGVnYW50bHkuDQoNCiAgICBJJ20gYWxtb3N0IGNlcnRh aW4gdGhhdCBJIGhhdmVuJ3QgdGhvdWdodCBhYm91dCBhbGwgdGhlIHBvdGVudGlhbA0KICAgIGFs dGVybmF0aXZlcy4gIEkgd29uZGVyIGlmIHRoZXJlIGlzbid0IHNvbWUgZXhwZXJpZW5jZSB3aXRo IHRoaXMNCiAgICBwcm9ibGVtIGluIFNDVFAgdGhhdCBtaWdodCBsZW5kIHNvbWUgaW5zaWdodHMu DQoNCg0K --_000_a891c4d345e446e3b172c7a9d7e815b3usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjAxNzQxNzM2NDsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTM4MDk5NDI5 NiAtMTIyMzUwMjU1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VHJhbnNwb3J0IGNhbm5vdCBzb2x2ZSB0aGUg cHJvYmxlbSBvZiBkZWFkbG9ja2luZyBkdWUgdG8gYSBoaWdoZXIgcHJvdG9jb2zigJlzIGRhdGEg cHJpb3JpdHkgb24gaXRzIG93bi4mbmJzcDsgVGhlIGFwcGxpY2F0aW9uIHdvdWxkIG5lZWQgdG8g Y29vcGVyYXRlIGNhcmVmdWxseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0g aXMgdGhhdCBpdCBpcyBub3Qgb25seSB0aGUgcmVjZWl2ZXIgdGhhdCBpcyBpbmZsdWVuY2luZyBm bG93IGNvbnRyb2wsIGJlY2F1c2Ugc2VuZGVyIHRyYW5zcG9ydCBoYXMgYnVmZmVycyBhcyB3ZWxs LiZuYnNwOyBUaGUgc2VuZGVyIHRyYW5zcG9ydCBjYW4gcmVmdXNlIHRvIGFjY2VwdCBoaWdoZXIt cHJpb3JpdHkgZGF0YSBmcm9tIHRoZSBhcHBsaWNhdGlvbiwgaWYgaXRzIGJ1ZmZlcnMgYXJlIGFs cmVhZHkNCiBmdWxsIHdpdGggbG93ZXItcHJpb3JpdHkgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+U28geW91IGNhbiBlbmQgdXAgd2l0aCByZWNlaXZlciByZWZ1c2luZyB0byBncmFudCBh ZGRpdGlvbmFsIGNyZWRpdHMgZm9yIHN0cmVhbSBZIChiZWNhdXNlIGl0IGNhbm5vdCBwcm9jZXNz IHN0cmVhbSBZIHcvbyBzdHJlYW0gWCkuICZuYnNwO0lmIHRoZSBzZW5kZXLigJlzIGJ1ZmZlcnMg YXJlIGZ1bGwgb2Ygc3RyZWFtIFkgZGF0YSwgaXQgY2Fubm90IHNlbmQgdGhhdCBkYXRhIGFuZCBj YW5ub3QgYWNjZXB0IGFueSBhZGRpdGlvbmFsDQogZGF0YSAoZm9yIHN0cmVhbSBYKS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFwcGxpY2F0aW9uIG11c3QgYmUgY2FyZWZ1bCBub3QgdG8g ZW5xdWV1ZSBzdHJlYW0gWSBkYXRhIHRvIHRoZSB0cmFuc3BvcnQgYmVmb3JlIGl0IGVucXVldWVz IGFsbCBkYXRhIGZyb20gc3RyZWFtIFggdGhhdCBzdHJlYW0gWSBkYXRhIGRlcGVuZHMgb24uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBSb2JlcnRvIFBlb24gW21haWx0bzpmZW5peEBmYi5jb21dIDxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA4OjAzIFBNPGJyPg0KPGI+ VG86PC9iPiBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBEZWFkbG9j a2luZyBpbiB0aGUgdHJhbnNwb3J0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgcmVjZWl2ZXIgd291bGQgYmUgdGhlIG9uZSB0byBwcm92aWRlIHRoZSBvdmVycmlk ZTsgVGhlIHNlbmRlciBjb3VsZCBoaW50IHRvIHRoZSByZWNlaXZlciB0aGF0IGl0IHNob3VsZCB3 aXNoIHRoaXMgYnkgc2lnbmFsaW5nIGl0IGlzIGJsb2NrZWQgKG9yIGRlYWRsb2NrZWQpIG9uIGZs b3cgY29udHJvbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi09UjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SmFuYSBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBnb29nbGUuY29tPC9hPiZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggYXQgNDo1MyBQTTxicj4N CjxiPlRvOiA8L2I+Um9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29t Ij5mZW5peEBmYi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+TWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTwvYT4mZ3Q7LCBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBEZWFk bG9ja2luZyBpbiB0aGUgdHJhbnNwb3J0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2JlcnRvLCA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgY29udmluY2VkIHRoYXQgd2UgbmVl ZCBzb21ldGhpbmcgYXMgaGVhdnktd2VpZ2h0IGFzIHRoaXMuLi4gc3BlY2lmaWNhbGx5LCBmbG93 IGNvbnRyb2wgc28gZmFyIGhhcyBiZWVuIGluIHRoZSByZWNlaXZlcidzIGNvbnRyb2wsIHdoaWNo IGlzIGFsc28gdGhlIHRoaW5nIHRoYXQgb3ducyB0aGUgcmVzb3VyY2UgaXQgaXMgdHJ5aW5nIHRv IGxpbWl0IGV4aGF1c3Rpb24gb2YuIFRoaXMgbW92ZXMgaXQNCiBvdXQgdG8gdGhlIHNlbmRlciwg d2hpY2ggd291bGQgcmVxdWlyZSBhIHJlY2VpdmVyIHRvIG5vdyBjb21taXQgbWVtb3J5IGJhc2Vk IG9uIHdoYXQgYSBzZW5kZXIgYmVsaWV2ZXMgaXMgaW1wb3J0YW50LiBSZWFzb25pbmcgYWJvdXQg dGhpcyBzZWVtcyBub24tdHJpdmlhbC4gSSB3b3JyeSBhYm91dCBob3cgYWxsIHRoaXMgZGVncmVl IG9mIGZyZWVkb20gd2lsbCBnZXQgYWJ1c2VkLCBhbmQgcG90ZW50aWFsIHNoYXJwIGVkZ2VzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3 ZSBjYW4gZW5zdXJlIHByaW9yaXR5IGNvbnN1bXB0aW9uIG9mIHRoZSBzaGFyZWQgcmVzb3VyY2Us IHRoYXQgc2VlbXMgYWRlcXVhdGUgdG8gcmVzb2x2ZSB0aGUgcHJvYmxlbSBvbiBoYW5kLiBEbyB5 b3UgdGhpbmsgc29tZXRoaW5nIG1vcmUgaXMgcmVxdWlyZWQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSmFuIDEwLCAyMDE4 IGF0IDEyOjI2IFBNLCBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5j b20iIHRhcmdldD0iX2JsYW5rIj5mZW5peEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBvcHRpb246PGJyPg0KQWxsb3cgYSBmbG93LWNv bnRyb2wg4oCYb3ZlcnJpZGXigJkgd2hpY2ggYWxsb3dzIGEgcmVjZWl2ZXIgdG8gc3RhdGUgdGhh dCB0aGV5IHJlYWxseSB3YW50IGRhdGEgb24gYSBwYXJ0aWN1bGFyIHN0cmVhbSwgYW5kIGlnbm9y ZSB0aGUgZ2xvYmFsIGZsb3cgY29udHJvbCBmb3IgdGhpcy48YnI+DQo8YnI+DQpIb3cgeW914oCZ ZCBkbyBpdDo8YnI+DQpBIHJlY2VpdmVyIGNhbiBzZW5kIGEgZmxvdy1jb250cm9sIG92ZXJyaWRl IGZvciBhIHN0cmVhbS4gVGhpcyBpbmNsdWRlcyB0aGUgc3RyZWFtIGlkIHRvIHdoaWNoIHRoZSBn bG9iYWwgd2luZG93IHRlbXBvcmFyaWx5IGRvZXMgbm90IGFwcGx5LCB0aGUgcmVjZWl2ZXLigJlz IGN1cnJlbnQgc3RyZWFtIGZsb3ctY29udHJvbCBvZmZzZXQsIGFuZCB0aGUgb2Zmc2V0IHRoZSBy ZWNlaXZlciB3b3VsZCB3aXNoIHRvIGJlIGFibGUgdG8gcmVjZWl2ZS48YnI+DQpBIHJlY2VpdmVy IG11c3QgY29udGludWUgdG8gKHJlKXNlbmQgdGhlIG92ZXJyaWRlIChpLmUuIHJleG1pdCkgdW50 aWwgaXQgaXMgYWNr4oCZZC4gSXQgY2Fubm90IHNlbmQgb3RoZXIgZmxvdy1jb250cm9sIGZvciB0 aGF0IHN0cmVhbSB1bnRpbCB0aGUgb3ZlcnJpZGUgaXMgYWNr4oCZZC48YnI+DQpUaHVzOjxicj4N CiZuYnNwOyBnbG9iYWwtZmxvdy1jb250cm9sLW92ZXJyaWRlOiAmbHQ7c3RyZWFtLWlkJmd0OyAm bHQ7Y3VycmVudC1mbG93LWNvbnRyb2wtb2Zmc2V0Jmd0OywgJmx0O292ZXJyaWRlLWZsb3ctY29u dHJvbC1vZmZzZXQmZ3Q7PGJyPg0KPGJyPg0KVGhlIHNlbmRlciAod2hpY2ggcmVjZWl2ZXMgdGhl IG92ZXJyaWRlKSBjcmVkaXRzIHRoZSBnbG9iYWwgZmxvdyBjb250cm9sIHdpdGggdGhlIGRpZmZl cmVuY2UgYmV0d2VlbiB0aGUgZGF0YSBzZW50IGJleW9uZCB0aGUgcmVjZWl2ZXJzIGN1cnJlbnRs eS1rbm93biBmbG93LWNvbnRyb2wgb2Zmc2V0IHVwb24gcmVjZWlwdCBvZiB0aGUgb3ZlcnJpZGUu PGJyPg0KVGhpcyBzeW5jaHJvbml6ZXMgdGhlIGdsb2JhbCBzdGF0ZSBiZXR3ZWVuIHRoZSByZWNl aXZlciBhbmQgdGhlIHNlbmRlci48YnI+DQpUaGUgc2VuZGVyIGNhbiB0aGVuIHNlbmQgdGhlIGRh dGEgb24gdGhlIHN0cmVhbSAod2l0aG91dCB0b3VjaGluZyBhbnkgb3RoZXIgZmxvdyBjb250cm9s IGRhdGEpLjxicj4NCjxicj4NCldoeTo8YnI+DQpUaGlzIGFsbG93cyBmb3IgYSByZWNlaXZlciB0 byByZXNvbHZlIHByaW9yaXR5IGludmVyc2lvbnMgd2hpY2ggd291bGQgb3RoZXJ3aXNlIGxlYWQg dG8gZGVhZGxvY2ssIGV2ZW4gd2hlbiB0aGUgZGF0YS9kZXAgbGVhZGluZyB0byB0aGlzIHdhcyBu b3Qga25vd24gdG8gdGhlIHRyYW5zcG9ydC4gVGhpcyBleHRlbmRzIGJleW9uZCBzdWNoIGlzc3Vl cyBiZXlvbmQganVzdCBoZWFkZXIgY29tcHJlc3Npb24uPGJyPg0KPGJyPg0KU2luY2UgdGhlIGds b2JhbCBmbG93LWNvbnRyb2wgZXhpc3RzIHRvIHByb3RlY3QgdGhlIGFwcCBmcm9tIHJlc291cmNl IGV4aGF1c3Rpb24sIHRoaXMgcG9zZXMgbm8gYWRkaXRpb25hbCByaXNrIHRvIHRoZSBhcHBsaWNh dGlvbi48YnI+DQpTaW1wbHkgaW5jcmVhc2luZyB0aGUgZ2xvYmFsIGZsb3cgY29udHJvbCBwcm92 aWRlcyBsZXNzIHN0cm9uZyBndWFyYW50ZWVz4oCUYW55IHN0cmVhbSBtaWdodCBjb25zdW1lIGl0 LCB3aGljaCBkb2VzbuKAmXQgcmVzb2x2ZSB0aGUgZGVwIGludmVyc2lvbi4gUmVqaWdnZXJpbmcg cHJpb3JpdGllcyBjYW4gaGVscCB0byByZXNvbHZlIHRoaXMsIGJ1dCB3b3VsZCByZXF1aXJlIHRo ZSBzZW5kZXIgdG8gc2VuZCBwcmlvcml0aWVzIHRvIHRoZSBjbGllbnQsIHdoaWNoDQogaXMgcHJv YmxlbWF0aWMgdy5yLnQucmFjZXMgYW5kIGp1c3QgYSB3ZWIgb2YgaWNrLjxicj4NCjxicj4NCkhh dmluZyBhIGN1c3RvbSBmcmFtZSB0eXBlIGlzIGFsc28gYSBsZXNzIHN0cm9uZyBndWFyYW50ZWUg YXMgaXQgcmVxdWlyZXMgdGhlIGtub3dsZWRnZSB0aGF0IHRoZSBkZXAgZXhpc3RzIHRvIGJlIHBy ZXNlbnQgYXQgdGhlIHRpbWUgb2Ygc2VuZGluZywgd2hpY2ggaXMgb2Z0ZW4gaW1wb3NzaWJsZS48 YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56 YiI+LT1SPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpPbiAxLzkv MTgsIDEwOjE3IFBNLCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBNYXJ0aW4gVGhvbXNvbiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4N Cjxicj4NCiZuYnNwOyAmbmJzcDsgQnVpbGRpbmcgYSBjb21wbGV4IGFwcGxpY2F0aW9uIHByb3Rv Y29sIG9uIHRvcCBvZiBRVUlDIGNvbnRpbnVlcyB0bzxicj4NCiZuYnNwOyAmbmJzcDsgcHJvZHVj ZSBzdXJwcmlzZXMuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUb2RheSBpbiB0aGUgaGVhZGVy IGNvbXByZXNzaW9uIGRlc2lnbiB0ZWFtIG1lZXRpbmcgd2UgZGlzY3Vzc2VkIGE8YnI+DQombmJz cDsgJm5ic3A7IGRlYWRsb2NraW5nIGlzc3VlIHRoYXQgSSB0aGluayB3YXJyYW50cyBzaGFyaW5n IHdpdGggdGhlIGxhcmdlciBncm91cC48YnI+DQombmJzcDsgJm5ic3A7IFRoaXMgaGFzIGltcGxp Y2F0aW9ucyBmb3IgaG93IHBlb3BsZSBidWlsZCBhIFFVSUMgdHJhbnNwb3J0IGxheWVyLiZuYnNw OyBJdDxicj4NCiZuYnNwOyAmbmJzcDsgbWlnaHQgbmVlZCBjaGFuZ2VzIHRvIHRoZSBBUEkgdGhh dCBpcyBleHBvc2VkIGJ5IHRoYXQgbGF5ZXIuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGlz IGlzbid0IHJlYWxseSB0aGF0IG5ldywgYnV0IEkgZG9uJ3QgdGhpbmsgd2UndmUgcHJvcGVybHkg YWRkcmVzc2VkPGJyPg0KJm5ic3A7ICZuYnNwOyB0aGUgcHJvYmxlbS48YnI+DQo8YnI+DQo8YnI+ DQombmJzcDsgJm5ic3A7ICMjIFRoZSBCYXNpYyBQcm9ibGVtPGJyPg0KPGJyPg0KJm5ic3A7ICZu YnNwOyBJZiBhIHByb3RvY29sIGNyZWF0ZXMgYSBkZXBlbmRlbmN5IGJldHdlZW4gc3RyZWFtcywg dGhlcmUgaXMgYTxicj4NCiZuYnNwOyAmbmJzcDsgcG90ZW50aWFsIGZvciBmbG93IGNvbnRyb2wg dG8gZGVhZGxvY2suPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBTYXkgdGhhdCBJIHNlbmQgWCBv biBzdHJlYW0gMyBhbmQgWSBvbiBzdHJlYW0gNy4mbmJzcDsgUHJvY2Vzc2luZyBZPGJyPg0KJm5i c3A7ICZuYnNwOyByZXF1aXJlcyB0aGF0IFggaXMgcHJvY2Vzc2VkIGZpcnN0Ljxicj4NCjxicj4N CiZuYnNwOyAmbmJzcDsgWCBjYW5ub3QgYmUgc2VudCBkdWUgdG8gZmxvdyBjb250cm9sIGJ1dCBZ IGlzIHNlbnQuJm5ic3A7IFRoaXMgaXMgYWx3YXlzPGJyPg0KJm5ic3A7ICZuYnNwOyBwb3NzaWJs ZSBldmVuIGlmIFggaXMgYXBwcm9wcmlhdGVseSBwcmlvcml0aXplZC4mbmJzcDsgVGhlIHJlY2Vp dmVyIHRoZW48YnI+DQombmJzcDsgJm5ic3A7IGxlYXZlcyBZIGluIGl0cyByZWNlaXZlIGJ1ZmZl ciB1bnRpbCBYIGlzIHJlY2VpdmVkLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgVGhlIHJlY2Vp dmVyIGNhbm5vdCBnaXZlIGZsb3cgY29udHJvbCBjcmVkaXQgZm9yIGNvbnN1bWluZyBZIGJlY2F1 c2U8YnI+DQombmJzcDsgJm5ic3A7IGl0IGNhbid0IGNvbnN1bWUgWSB1bnRpbCBYIGlzIHNlbnQu Jm5ic3A7IEJ1dCB0aGUgc2VuZGVyIG5lZWRzIGZsb3cgY29udHJvbDxicj4NCiZuYnNwOyAmbmJz cDsgY3JlZGl0IHRvIHNlbmQgWC4mbmJzcDsgV2UgYXJlIGRlYWRsb2NrZWQuPGJyPg0KPGJyPg0K Jm5ic3A7ICZuYnNwOyBJdCBkb2Vzbid0IG1hdHRlciB3aGV0aGVyIHRoZSBzdHJlYW0gb3IgY29u bmVjdGlvbiBmbG93IGNvbnRyb2wgaXM8YnI+DQombmJzcDsgJm5ic3A7IGNhdXNpbmcgdGhlIHBy b2JsZW0sIGVpdGhlciBwcm9kdWNlcyB0aGUgc2FtZSByZXN1bHQuPGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyAoVG8gZ2l2ZSBzb21lIGJhY2tncm91bmQgb24gdGhpcywgd2Ugd2VyZSBjb25zaWRl cmluZyBhIHByZWZhY2UgdG88YnI+DQombmJzcDsgJm5ic3A7IGhlYWRlciBibG9ja3MgdGhhdCBp ZGVudGlmaWVkIHRoZSBoZWFkZXIgdGFibGUgc3RhdGUgdGhhdCB3YXM8YnI+DQombmJzcDsgJm5i c3A7IG5lY2Vzc2FyeSB0byBwcm9jZXNzIHRoZSBoZWFkZXIgYmxvY2suJm5ic3A7IFRoaXMgd291 bGQgYWxsb3cgZm9yPGJyPg0KJm5ic3A7ICZuYnNwOyBjb25jdXJyZW50IHBvcHVsYXRpb24gb2Yg dGhlIGhlYWRlciB0YWJsZSBhbmQgc2VuZGluZyBtZXNzYWdlIHRoYXQ8YnI+DQombmJzcDsgJm5i c3A7IGRlcGVuZGVkIG9uIHRoZSBoZWFkZXIgdGFibGUgc3RhdGUgdGhhdCBpcyB1bmRlciBjb25z dHJ1Y3Rpb24uJm5ic3A7IEE8YnI+DQombmJzcDsgJm5ic3A7IHJlY2VpdmVyIHdvdWxkIHJlYWQg dGhlIGlkZW50aWZpZXIgYW5kIHRoZW4gbGVhdmUgdGhlIHJlbWFpbmRlciBvZiB0aGU8YnI+DQom bmJzcDsgJm5ic3A7IGhlYWRlciBibG9jayBpbiB0aGUgcmVjZWl2ZSBidWZmZXIgdW50aWwgdGhl IGhlYWRlciB0YWJsZSB3YXMgcmVhZHkuKTxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsg IyMgT3B0aW9uczxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSXQgc2VlbXMgbGlrZSB0aGVyZSBh cmUgYSBmZXcgZGVjZW50IG9wdGlvbnMgZm9yIG1hbmFnaW5nIHRoaXMuJm5ic3A7IFRoZXNlPGJy Pg0KJm5ic3A7ICZuYnNwOyBhcmUgd2hhdCBvY2N1cnJlZCB0byBtZSAodGhlcmUgYXJlIGFsbW9z dCBjZXJ0YWlubHkgbW9yZSBvcHRpb25zKTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDEuIERv bid0IGRvIHRoYXQuJm5ic3A7IFdlIG1pZ2h0IGNvbmNlZGUgaW4gdGhpcyBjYXNlIHRoYXQgc2Vl a2luZyB0aGU8YnI+DQombmJzcDsgJm5ic3A7IGluY3JlbWVudGFsIGltcHJvdmVtZW50IHRvIGNv bXByZXNzaW9uIGVmZmljaWVuY3kgaXNuJ3Qgd29ydGggdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyBy aXNrLiZuYnNwOyBUaGF0IGlzLCB3ZSBtaWdodCBtYWtlIGEgZ2VuZXJhbCBzdGF0ZW1lbnQgdGhh dCB0aGlzIHNvcnQgb2Y8YnI+DQombmJzcDsgJm5ic3A7IGludGVyLXN0cmVhbSBibG9ja2luZyBp cyBhIGJhZCBpZGVhLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgMi4gRm9yY2UgcmVjZWl2ZXJz IHRvIGNvbnN1bWUgZGF0YSBvciByZXNldCBzdHJlYW1zIGluIHRoZSBjYXNlIG9mPGJyPg0KJm5i c3A7ICZuYnNwOyB1bmZ1bGZpbGxlZCBkZXBlbmRlbmNpZXMuJm5ic3A7IFRoZSBmb3JtZXIgc2Vl bXMgbGlrZSBpdCBtaWdodCBiZSB0b28gbXVjaDxicj4NCiZuYnNwOyAmbmJzcDsgbGlrZSBtYWdp Y2FsIHRoaW5raW5nLCBpbiB0aGUgc2Vuc2UgdGhhdCBpdCByZXF1aXJlcyB0aGF0IHJlY2VpdmVy czxicj4NCiZuYnNwOyAmbmJzcDsgY29uanVyZSBtb3JlIG1lbW9yeSB1cCwgYnV0IGlmIHRoZSBy ZWNlaXZlciB3ZXJlIHJlcXVpcmVkIHRvIHJlYWQgWTxicj4NCiZuYnNwOyAmbmJzcDsgYW5kIHJl bGVhc2UgdGhlIGZsb3cgY29udHJvbCBjcmVkaXQsIHRoZW4gYWxsIHdvdWxkIGJlIGZpbmUuJm5i c3A7IEZvcjxicj4NCiZuYnNwOyAmbmJzcDsgaW5zdGFuY2UsIHdlIGNvdWxkIHJlcXVpcmUgdGhh dCB0aGUgcmVjZWl2ZXIgcmVzZXQgYSBzdHJlYW0gaWYgaXQ8YnI+DQombmJzcDsgJm5ic3A7IGNv dWxkbid0IHJlYWQgYW5kIGhhbmRsZSBkYXRhLiZuYnNwOyBJdCBzZWVtcyBsaWtlIGEgYmFkIGFy cmFuZ2VtZW50PGJyPg0KJm5ic3A7ICZuYnNwOyB0aG91Z2g6IHlvdSBlaXRoZXIgaGF2ZSB0byBh bGxvY2F0ZSBtb3JlIG1lbW9yeSB0aGFuIHlvdSB3b3VsZCBsaWtlIG9yPGJyPg0KJm5ic3A7ICZu YnNwOyBzdWZmZXIgdGhlIHRpbWUgYW5kIG9wcG9ydHVuaXR5IGNvc3Qgb2YgaGF2aW5nIHRvIGRv IFkgb3Zlci48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDMuIENyZWF0ZSBhbiBleGNlcHRpb24g Zm9yIGZsb3cgY29udHJvbC4mbmJzcDsgVGhpcyBpcyB3aGF0IEdvb2dsZSBRVUlDPGJyPg0KJm5i c3A7ICZuYnNwOyBkb2VzIGZvciBpdHMgaGVhZGVycyBzdHJlYW0uJm5ic3A7IFJvYmVydG8gb2Jz ZXJ2ZWQgdGhhdCB3ZSBjb3VsZDxicj4NCiZuYnNwOyAmbmJzcDsgYWx0ZXJuYXRpdmVseSBjcmVh dGUgYSBmcmFtZSB0eXBlIHRoYXQgd2FzIGV4Y2x1ZGVkIGZyb20gZmxvdyBjb250cm9sLjxicj4N CiZuYnNwOyAmbmJzcDsgSWYgdGhpcyB3ZXJlIHVzZWQgZm9yIGRhdGEgdGhhdCBoYWQgZGVwZW5k ZW5jaWVzLCB0aGVuIGl0IHdvdWxkIGJlPGJyPg0KJm5ic3A7ICZuYnNwOyBpbXBvc3NpYmxlIHRv IGRlYWRsb2NrLiZuYnNwOyBJdCB3b3VsZCBiZSBzaW1pbGFybHkgZGlmZmljdWx0IHRvIGFjY291 bnQ8YnI+DQombmJzcDsgJm5ic3A7IGZvciBtZW1vcnkgYWxsb2NhdGlvbiwgdGhvdWdoIGlmIGl0 IHdlcmUgcG9zc2libGUgdG8gcHJvY2VzcyBvbjxicj4NCiZuYnNwOyAmbmJzcDsgcmVjZWlwdCwg dGhlbiB0aGlzICptaWdodCogd29yay4mbmJzcDsgV2UnZCBoYXZlIHRvIGRvIHNvbWV0aGluZyB0 byBhZGRyZXNzPGJyPg0KJm5ic3A7ICZuYnNwOyBvdXQtb2Ytb3JkZXIgZGVsaXZlcnkgdGhvdWdo LiZuYnNwOyBJdCdzIHBvc3NpYmxlIHRoYXQgdGhlIHN0cmVhbTxicj4NCiZuYnNwOyAmbmJzcDsg YWJzdHJhY3Rpb24gaXMgbm90IGFwcHJvcHJpYXRlIGluIHRoaXMgY2FzZS48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IDQuIEJsb2NrIHRoZSBwcm9ibGVtIGF0IHRoZSBzb3VyY2UuJm5ic3A7IEl0 IHdhcyBzdWdnZXN0ZWQgdGhhdCBpbiBjYXNlczxicj4NCiZuYnNwOyAmbmJzcDsgd2hlcmUgdGhl cmUgaXMgYSBwb3RlbnRpYWwgZGVwZW5kZW5jeSwgdGhlbiBpdCBjYW4ndCBiZSBhIHByb2JsZW0g aWY8YnI+DQombmJzcDsgJm5ic3A7IHRoZSB0cmFuc3BvcnQgcmVmdXNlZCB0byBhY2NlcHQgZGF0 YSB0aGF0IGl0IGRpZG4ndCBoYXZlIGZsb3cgY29udHJvbDxicj4NCiZuYnNwOyAmbmJzcDsgY3Jl ZGl0IGZvci4mbmJzcDsgV3JpdGVzIHRvIHRoZSB0cmFuc3BvcnQgd291bGQgY29uc3VtZSBmbG93 IGNvbnRyb2wgY3JlZGl0PGJyPg0KJm5ic3A7ICZuYnNwOyBpbW1lZGlhdGVseS4mbmJzcDsgVGhh dCB3YXkgYXBwbGljYXRpb25zIHdvdWxkIG9ubHkgYmUgYWJsZSB0byB3cml0ZSBYIGlmPGJyPg0K Jm5ic3A7ICZuYnNwOyB0aGVyZSB3YXMgYSBjaGFuY2UgdGhhdCBpdCB3b3VsZCBiZSBkZWxpdmVy ZWQuJm5ic3A7IEFwcGxpY2F0aW9ucyB0aGF0IGhhdmU8YnI+DQombmJzcDsgJm5ic3A7IG9yZGVy aW5nIHJlcXVpcmVtZW50cyBjYW4gZW5zdXJlIHRoYXQgWSBpcyB3cml0dGVuIGFmdGVyIFggaXMg YWNjZXB0ZWQ8YnI+DQombmJzcDsgJm5ic3A7IGJ5IHRoZSB0cmFuc3BvcnQgYW5kIHRoZXJlYnkg YXZvaWQgdGhlIGRlYWRsb2NrLiZuYnNwOyBXcml0ZXMgbWlnaHQgYmxvY2s8YnI+DQombmJzcDsg Jm5ic3A7IHJhdGhlciB0aGFuIGZhaWwsIGlmIHRoZSBBUEkgd2Fzbid0IGludG8gdGhlIHdob2xl IG5vbi1ibG9ja2luZyBJL088YnI+DQombmJzcDsgJm5ic3A7IHRoaW5nLiZuYnNwOyBUaGUgdHJh bnNwb3J0IG1pZ2h0IHN0aWxsIGhhdmUgdG8gYnVmZmVyIFggZm9yIG90aGVyIHJlYXNvbnMsPGJy Pg0KJm5ic3A7ICZuYnNwOyBsaWtlIGNvbmdlc3Rpb24gY29udHJvbCwgYnV0IGl0IGNhbiBndWFy YW50ZWUgdGhhdCBmbG93IGNvbnRyb2wgaXNuJ3Q8YnI+DQombmJzcDsgJm5ic3A7IGdvaW5nIHRv IGJsb2NrIGRlbGl2ZXJ5Ljxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgIyMgTXkgUHJl ZmVyZW5jZTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUmlnaHQgbm93LCBJJ20gaW5jbGluZWQg dG93YXJkIG9wdGlvbiA0LiBPcHRpb24gMSBzZWVtcyBhIGxpdHRsZSB0b288YnI+DQombmJzcDsg Jm5ic3A7IG11Y2ggb2YgYSBjb25zdHJhaW50LiZuYnNwOyBQcm90b2NvbHMgY3JlYXRlIHRoaXMg c29ydCBvZiBpbnRlci1kZXBlbmRlbmN5PGJyPg0KJm5ic3A7ICZuYnNwOyBuYXR1cmFsbHkuPGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBUaGVyZSdzIGEgY2VydGFpbiBwdXJpdHkgaW4gaGF2aW5n IHRoZSBmbG93IGNvbnRyb2wgZXhlcnQgYmFjazxicj4NCiZuYnNwOyAmbmJzcDsgcHJlc3N1cmUg YWxsIHRoZSB3YXkgdG8gdGhlIG5leHQgbGF5ZXIgdXAuJm5ic3A7IE5vdCBiZWluZyBhYmxlIHRv IGJ1aWxkIGE8YnI+DQombmJzcDsgJm5ic3A7IHRyYW5zcG9ydCB3aXRoIHVuY29uc3RyYWluZWQg d3JpdGVzIGlzIHBvdGVudGlhbGx5IGNyZWF0aW5nPGJyPg0KJm5ic3A7ICZuYnNwOyB1bmRlc2ly YWJsZSBleHRlcm5hbGl0aWVzIG9uIHRyYW5zcG9ydCB1c2Vycy4mbmJzcDsgTm93IHRoZXkgaGF2 ZSB0byB3b3JyeTxicj4NCiZuYnNwOyAmbmJzcDsgYWJvdXQgZmxvdyBjb250cm9sIGFzIHdlbGwu Jm5ic3A7IFBlcnNvbmFsbHksIEknbSBpbmNsaW5lZCB0byBzYXkgdGhhdCB0aGlzPGJyPg0KJm5i c3A7ICZuYnNwOyBpcyBzb21ldGhpbmcgdGhhdCBhcHBsaWNhdGlvbiBwcm90b2NvbHMgYW5kIHRo ZWlyIHVzZXJzIHNob3VsZCBiZTxicj4NCiZuYnNwOyAmbmJzcDsgZXhwb3NlZCB0by4mbmJzcDsg V2UndmUgc2VlbiB3aXRoIHRoZSBKUyBzdHJlYW1zIEFQSSB0aGF0IGl0J3MgdmFsdWFibGUgdG88 YnI+DQombmJzcDsgJm5ic3A7IGhhdmUgYmFjayBwcmVzc3VyZSBhdmFpbGFibGUgYXQgdGhlIGFw cGxpY2F0aW9uIGxheWVyIGFuZCBhbHNvIGhvdyBpdDxicj4NCiZuYnNwOyAmbmJzcDsgaXMgcG9z c2libGUgdG8gZG8gdGhhdCByZWxhdGl2ZWx5IGVsZWdhbnRseS48YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IEknbSBhbG1vc3QgY2VydGFpbiB0aGF0IEkgaGF2ZW4ndCB0aG91Z2h0IGFib3V0IGFs bCB0aGUgcG90ZW50aWFsPGJyPg0KJm5ic3A7ICZuYnNwOyBhbHRlcm5hdGl2ZXMuJm5ic3A7IEkg d29uZGVyIGlmIHRoZXJlIGlzbid0IHNvbWUgZXhwZXJpZW5jZSB3aXRoIHRoaXM8YnI+DQombmJz cDsgJm5ic3A7IHByb2JsZW0gaW4gU0NUUCB0aGF0IG1pZ2h0IGxlbmQgc29tZSBpbnNpZ2h0cy48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a891c4d345e446e3b172c7a9d7e815b3usma1exdag1mb5msgcorpak_-- From nobody Thu Jan 11 18:47:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E56F12D72F for ; Thu, 11 Jan 2018 18:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DCRDgVWNyrV for ; Thu, 11 Jan 2018 18:47:55 -0800 (PST) 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 E87DD126D45 for ; Thu, 11 Jan 2018 18:47:53 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx15.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eZpNb-0007Vq-02 for quic@ietf.org; Fri, 12 Jan 2018 03:47:40 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eZpNR-00032Z-3V for quic@ietf.org; Thu, 11 Jan 2018 21:47:32 -0500 Received: (qmail 29201 invoked from network); 12 Jan 2018 02:47:20 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Jan 2018 02:47:19 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> Date: Thu, 11 Jan 2018 16:47:19 -1000 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="------------0FAA3E03FF542E5934698F17" Subject: Re: Increasing QUIC connection ID size X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tOaXUxIwwGx8QDPCy6+3lMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftfrEty55E/y6tQNxmuYB7fB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIx4AXarfh1O38bAuuIRigptEjxjSIdK/OrMoYfnrE KP3aXbDVPW3nVdYVd9gzfcPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATvFVVOfJAYdBTniKgyyo60ONoJfh+XjGSeeT90H/uIEu fDSTg6PfMsskW99EgQeafmirzrF513SzC18rTLvbNWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWi2LEHF33nMCnEPdDBPtPg/fFcHV2tQAVqGdj/zM7G/G3L31QGIB1LDs8uX49JL/W5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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, 12 Jan 2018 02:47:58 -0000 This is a multi-part message in MIME format. --------------0FAA3E03FF542E5934698F17 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value. On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state. If the router does not want to keep the state, it can indeed create a connection ID by encrypting a tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish. So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large. On 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Actually, on encryption of connection ID, this is not so simple. > > We must assume there is only a single key for many connections because > the router is not part of a key exchange. This unique value or counter > used for encrypting a single block cannot be the same for two > different connections ID=E2=80=99s, but it can be public. This means th= at it > must be stored in the packet header. And, as it turns out, random > connection ID chosen by a trusted source, can be used for such a > unique value. But then it must be used to encrypt and/or authenticate > something else carrying the actual routing information. So now you > start to really need some extra payload. > > Alternatively the routing information is entirely random such as > content hashed routing. Then you only need to authenticate the routing > data. You can do that with a HMAC, and CMAC could probably also work. > The additional benefit is that you can probably get away with 64-bits > for all routing information possibly including the auth tag. Say 48 > bits of routing data and 16 bits of auth tag. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com > ) wrote: > >> I am interested in exploring this proposal, since it allows for more >> flexible schemes of encoding routing metadata and a checksum. I >> would also like to be explicit about the connection ID size in a >> packet header, though, since it greatly simplifies the implementation.= >> >> =20 >> >> * Igor >> >> *From:* Victor Vasiliev [mailto:vasilvv@google.com >> ] >> *Sent:* Thursday, January 11, 2018 6:16 PM >> *To:* IETF QUIC WG > >> *Subject:* Increasing QUIC connection ID size >> >> =20 >> >> Hi everyone, >> >> =20 >> >> In the current version of QUIC, the connection ID size is fixed to be >> a 64-bit opaque blob, and that is set as an invariant in the protocol.= >> >> =20 >> >> I=E2=80=99ve looked into possibility of using a connection ID to encod= e the >> specific server details into it (to provide stability of the >> connection in case of load balancing changes, especially BGP flaps >> for anycast IPs), and have chatted about this with other people I >> knew were interested in this. It seems like 64 bits might be too >> small for this purpose, and we might want to leave an opportunity to >> extend the connection ID size. >> >> =20 >> >> The basic idea is that you want to be able to: >> >> 1. Store some routing metadata in the connection ID. >> 2. Have some entropy that allows distinguish users with identical >> routing metadata. >> 3. Have a checksum to ensure the validity of routing information >> 4. Encrypt the information above to prevent disclosing the route >> information and allow generating uncorrelatable connection IDs. >> >> There are two underlying issues here. The first problem is that all >> of this does not fit well into 64 bits, and you have to seriously >> compromise on the strength of the checksum (which is bad especially >> if you want it to be a MAC rather than a checksum). The second >> problem is that encrypting 64-bit values fast is actually fairly hard >> since the block ciphers easily available in hardware have 128-bit >> block size, and the performance requirements on load balancers are >> tighter than on servers. =20 >> >> =20 >> >> In other words, having a 128-bit connection ID provides for an easy >> secure way to generate unlinkable connection IDs on migration. >> >> =20 >> >> So, the problem we=E2=80=99re trying to solve is that the connection I= D is >> too small. There are two questions I believe the working group >> should answer at this point: >> >> 1. Do we want to address this problem at this point in >> standardization process? >> 2. If we don=E2=80=99t address this problem right now, how do we stru= cture >> the standard in a way that we can extend the connection ID in the >> future? >> >> There are multiple ways to solve the problem of making connection ID >> larger. One is to just add extra bit to the =E2=80=9Comit connection = ID=E2=80=9D >> field to allow 128-bit connection IDs. Another approach is to allow >> connection ID size to be explicitly specified by the server, and then >> assume that the load balancer knows that size and no one else on the >> path needs to read it. >> >> =20 >> >> There=E2=80=99s also a question of how much of connection IDs do middl= eboxes >> (excluding load balancers and other boxes owned by the same entity as >> either client or server) need to know. We could go for both >> =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80= =9D and >> =E2=80=9Cmiddleboxes should not read connection IDs at all options=E2=80= =9D, but I >> think there=E2=80=99s also a room for more flexible formulations like >> =E2=80=9Cmiddleboxes always get first 64 bits and they have useful ent= ropy to >> distinguish connections=E2=80=9D. >> >> =20 >> >> -- Victor. >> --------------0FAA3E03FF542E5934698F17 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value.

    On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state.

    If the router does not want to keep the state, it can indeed create a connection ID by encrypting a <nonce, server-ID> tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large.


    On 1/11/2018 2:25 PM, Mikkel Fahnøe Jørgensen wrote:
    Actually, on encryption of connection ID, this is not so simple.

    We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID’s, but it can be public. This means that it must be stored in the packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload.

    Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag.

    Kind Regards,
    Mikkel Fahnøe Jørgensen


    On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum.  I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation.

     

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

     

    Hi everyone,

     

    In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

     

    I’ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this.  It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size.

     

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing metadata.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs.

    There are two underlying issues here.  The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum).  The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers.  

     

    In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration.

     

    So, the problem we’re trying to solve is that the connection ID is too small.  There are two questions I believe the working group should answer at this point:

    1. Do we want to address this problem at this point in standardization process?
    2. If we don’t address this problem right now, how do we structure the standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of making connection ID larger.  One is to just add extra bit to the “omit connection ID†field to allow 128-bit connection IDs.  Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it.

     

    There’s also a question of how much of connection IDs do middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.  We could go for both “middleboxes should be always able to read the entire ID†and “middleboxes should not read connection IDs at all optionsâ€, but I think there’s also a room for more flexible formulations like “middleboxes always get first 64 bits and they have useful entropy to distinguish connectionsâ€.

     

      -- Victor.


    --------------0FAA3E03FF542E5934698F17-- From nobody Thu Jan 11 21:56:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD071201FA for ; Thu, 11 Jan 2018 21:56:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mCEa-QiVSXC for ; Thu, 11 Jan 2018 21:56:06 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 210C4120727 for ; Thu, 11 Jan 2018 21:56:05 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0C5tsRE015883; Fri, 12 Jan 2018 06:55:54 +0100 Date: Fri, 12 Jan 2018 06:55:54 +0100 From: Willy Tarreau To: Roberto Peon Cc: "Lubashev, Igor" , Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Victor Vasiliev , IETF QUIC WG Subject: Re: Increasing QUIC connection ID size Message-ID: <20180112055554.GA15873@1wt.eu> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 05:56:08 -0000 On Fri, Jan 12, 2018 at 01:05:02AM +0000, Roberto Peon wrote: > Correct/agreed. The L4 'router' must be able to decrypt/interpret the data in > order to act upon it. This requires sharing of some key material. At least we need to keep in mind that it's critical to ensure consistency between all front nodes (think DNS+anycast BGP+ECMP LB before reaching the L7 LB). It's critical that all equipments in the path are able to coherently find the correct path to the origin node without having to actually learn anything from the packets. And synchronizing keys between multiple nodes is often a pain (though never impossible). At the HTTP workshop 2 years ago, I proposed to place some upfront routing information on TLS to save LBs from having to decrypting the stream to find what server the stream had to be sent to. The proposal was to have a small ID, typically 16 bits, for this. In my opinion this is another option we can consider here : with only 16 bits, you can easily store a server ID in a reasonable farm size (even dynamic), but you don't have enough information to track users. So it could remain accessible in clear, saving front nodes from having to decrypt anything or share keys. Willy From nobody Thu Jan 11 22:18:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBC2126CE8 for ; Thu, 11 Jan 2018 22:18:55 -0800 (PST) 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 zfiXdhDlKAtD for ; Thu, 11 Jan 2018 22:18:53 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 980911205F1 for ; Thu, 11 Jan 2018 22:18:53 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 44so3354992otk.8 for ; Thu, 11 Jan 2018 22:18:53 -0800 (PST) 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=0iY+CE4ToIHflEdKvsR/xg1duJBnKJjHFxC115/WoYw=; b=Aza9aeGTQmwKS4TTmwF5GP8tjyqXlBw6lClxHwcj1cd4U0IcYc6GNL2L50rDoYEP5U vA/E6zr8XDnJv01vxT/R56eraUgN296fTpPYnXYprZFU6xBvRxBjFHk02qX1oGukpc2t 894P8dThE7N5Hkcw06BWiycDlPhX9/hB2Kt4jXcW23R9zkLSwmjJZcUDpvUUCjA9BCXj MR/glzuTOlLkv8h5GqjhcF1NKsverRYdC5FDoX2QEZitrVttoRxi9OgZ6G5d32HTBxJi ud7IlS+FAjNgAD2K/MM+KG3wZaE2sRHv6+jLZ+cZ50kVhK/YaClZ7uWav3vBwCsNuJDC DhSg== 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=0iY+CE4ToIHflEdKvsR/xg1duJBnKJjHFxC115/WoYw=; b=Jf0gqnZrk/W5DSCTrAhXx6Sep46XMo3AWWdUXdHt7Ydqlz7wiKUeZ3MYvTcr1d7IJI bg12Nz7V0abc3auwgdfjZPSeHkV7cWY2ITQYU1hiUpdVE2J0CEKOObi8FklopCw6TZ3I hzn9qsT9u1ixw+9CgPGiEPPYohlBIF+MDt7q31hJi+K/dv7YjKMUjuyXCxiw5gcy9CJy 9hwg8xJ9q8bPvdfY6kMdYLbfIp2BbpGqYdp2hfvt7SYNnNBnvPSazhi6T3aNc/y8srb3 X9Q8wM3XQw1CMxs7l+aOlaT9C9BG8qY1Nwn9oaD0xsK5qUjoOIPlhVGC1Wht/uZ3sx5f 727Q== X-Gm-Message-State: AKwxytfX9ly9O9y3EZbLRsJyWHzehPP5X0fs3Lbxo4uys47J2fUN2OI+ qYSXBHqC+3xeWcqi8c0U/Xjm+QCJUrzYK1mjgnU= X-Google-Smtp-Source: ACJfBotND6bEqbglrnk2x3QWbL+bLpBlXrtfV0DwGpO3hIbDbfBmgtOFVPh20y9+eUYBJHs9G+/oe86uFxZBlI5RswI= X-Received: by 10.157.40.134 with SMTP id s6mr15104780ota.133.1515737932936; Thu, 11 Jan 2018 22:18:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Thu, 11 Jan 2018 22:18:52 -0800 (PST) In-Reply-To: <20180112055554.GA15873@1wt.eu> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> <20180112055554.GA15873@1wt.eu> From: Martin Thomson Date: Fri, 12 Jan 2018 17:18:52 +1100 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Willy Tarreau Cc: Roberto Peon , Victor Vasiliev , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Lubashev, Igor" , 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, 12 Jan 2018 06:18:55 -0000 https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00 is currently DTLS specific. Is this something that you feel should be more general? I think that people reading this thread should be aware of the alternative design options here, the above draft identifies one. Note that there are several key ways in which this might be unsuitable for QUIC in its current form; it makes a different set of trade-offs. On Fri, Jan 12, 2018 at 4:55 PM, Willy Tarreau wrote: > On Fri, Jan 12, 2018 at 01:05:02AM +0000, Roberto Peon wrote: >> Correct/agreed. The L4 'router' must be able to decrypt/interpret the data in >> order to act upon it. This requires sharing of some key material. > > At least we need to keep in mind that it's critical to ensure consistency > between all front nodes (think DNS+anycast BGP+ECMP LB before reaching the > L7 LB). It's critical that all equipments in the path are able to coherently > find the correct path to the origin node without having to actually learn > anything from the packets. And synchronizing keys between multiple nodes > is often a pain (though never impossible). > > At the HTTP workshop 2 years ago, I proposed to place some upfront routing > information on TLS to save LBs from having to decrypting the stream to > find what server the stream had to be sent to. The proposal was to have > a small ID, typically 16 bits, for this. In my opinion this is another > option we can consider here : with only 16 bits, you can easily store a > server ID in a reasonable farm size (even dynamic), but you don't have > enough information to track users. So it could remain accessible in > clear, saving front nodes from having to decrypt anything or share keys. > > Willy > From nobody Thu Jan 11 22:20:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98454126D73 for ; Thu, 11 Jan 2018 22:20:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UtgB87oattDw for ; Thu, 11 Jan 2018 22:20:25 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394EE1205F1 for ; Thu, 11 Jan 2018 22:20:25 -0800 (PST) X-AuditID: c1b4fb3a-34dff700000037f2-6d-5a5853a7126f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 79.21.14322.7A3585A5; Fri, 12 Jan 2018 07:20:23 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 12 Jan 2018 07:20:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Jdeamw/1/p3rMYVhKIDZ+OTVA+JkqIclAlncP2ZZSZ8=; b=LHUHoytwbs8EHrRQADiKHK4WG87cFJh8SCeb4MO1rPj1HHHESg9Hvh0wFQohF2r+7Xqd7pWtptuS1bAfQZ/RLZlFAqlawEJARUJvu8CnsKEuJrfm/rIawudFmxP8VHL6hlkqp4lgt2fv9yEctUTK7EtQ+yJckQFk9LwITM9rmbc= Received: from DB6PR07MB3256.eurprd07.prod.outlook.com (10.175.233.27) by DB6PR07MB3077.eurprd07.prod.outlook.com (10.170.223.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.407.1; Fri, 12 Jan 2018 06:20:21 +0000 Received: from DB6PR07MB3256.eurprd07.prod.outlook.com ([fe80::3c44:3724:718c:6ad5]) by DB6PR07MB3256.eurprd07.prod.outlook.com ([fe80::3c44:3724:718c:6ad5%13]) with mapi id 15.20.0407.009; Fri, 12 Jan 2018 06:20:21 +0000 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Roberto Peon , Victor Vasiliev , "IETF QUIC WG" Subject: Re: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizI3iEQBWn4tikSvgaDx/B9OtKNvZtUAgABuYQA= Date: Fri, 12 Jan 2018 06:20:21 +0000 Message-ID: <6037C2BE-C3C5-4859-AF6F-D12300EFB8A5@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.29.0.171205 x-originating-ip: [78.70.164.147] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3077; 7:68dsq9t5lNKRfKiBRhq0jS3EKqxaREf13s+iPjU/htlslJz0onba8SDnSKayDsJDyJ6nZMpu+yJraGMW/9rY8ChZhHbuKoY0VQGwN8I59x4lr8fw+r1xSPQH0Ef0iiscKNx86znj4AWky+2+GOx608aJsTc+VV+nv4WI6cxZqoHiM2XGFrD6rh6X/eK1wwMNaeTo7WDEMrleOzyda3yZB3oyul7TXTBXErsLN49zVx1GkCumRhYUhpWr0rljD5UP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 69288f63-163c-442b-5a19-08d559848f45 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020077)(4652020)(5600026)(4604075)(3008032)(4534107)(4602075)(4627203)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR07MB3077; x-ms-traffictypediagnostic: DB6PR07MB3077: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231023)(944501140)(10201501046)(3002001)(6041268)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DB6PR07MB3077; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB6PR07MB3077; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(376002)(39860400002)(39380400002)(189003)(24454002)(199004)(377424004)(3846002)(83716003)(2900100001)(236005)(6512007)(6306002)(54896002)(66066001)(25786009)(6486002)(85202003)(97736004)(85182001)(99286004)(68736007)(2906002)(5660300001)(6436002)(82746002)(5250100002)(86362001)(83506002)(2950100002)(105586002)(7736002)(3660700001)(76176011)(36756003)(33656002)(14454004)(8676002)(478600001)(102836004)(81156014)(53936002)(106356001)(6506007)(6116002)(3280700002)(229853002)(6246003)(58126008)(110136005)(81166006)(6346003)(53546011)(8936002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3077; H:DB6PR07MB3256.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=goran.ap.eriksson@ericsson.com; x-microsoft-antispam-message-info: P6HszXkd9vItIWu+qIkBeUrWGKTyaU/8KnzxoncNvUCz9yzCdLwvHmJ6qwF7FdcM2wnDgepecZUI3MuawLUEjQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_6037C2BEC3C54859AF6FD12300EFB8A5ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 69288f63-163c-442b-5a19-08d559848f45 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 06:20:21.6566 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3077 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRjG+3bOtrPp4PMyfbELOLqazktBSytNiKQIowhsWrbcSUWdsqOW QiBq3g21pWmTmRciL4VmZuJ9VsuEvGSG+E+oqZCGqGgq2rYzwf9+7/M87/d+N4qw7eQ6UZGq eFqtUkRLeEKyNOj9BbeX14PkHoNaB5mmNI8ry6uwko3XZnP8iIDCtAV+QEVTQkB19T/OVUIu PKOkoyMTabX7uTvCiJn6VV7chOuDla1OMgW9PZ6DKArwSSir8M9BQsoW6xEMNHQRbGFAsP14 k2sqSJxPgG4qF7FOEQeqsrL4OUhgLCYRtD2PNjEPX4aMdD1pYnscDlXbm4SJ7bA7bNT081nd A6a+VnJZ9oYig8Gsk/gQZC4NmXUR9oXB/mXLsBQEf9sHzSGBsWG0spNjYoQdYLW/3swEdoTU 5VfmZsAYqtu/ESyLYW5yy6yLsRRmB37wWd0ZJhtSLbwfhnXsyQA3c2BmLYPHGlJ4VziPWL5i 3Ol3PhsaQtBfoCVZwwX6NDrLtCj4uGzg7fBYyTTBNtQRUNCTbjH2QXmLxrLSOhe0z9ZQAZKW 7ToGy2Ew/GQblZnvwwa+lE6RZcbnIvAxeNPmzkacQZP7i8/yUXikLbdwAHQtNXJ3ZyoQVYvE DM0wMeFeXlJaHRnGMLEqqYqOb0LGX9XTvOHdinpmzvciTCGJtcgmMEhuy1UkMkkxvQgoQmIv enbRKImUiqRkWh0bqk6IppletJciJY4i/3syuS0OV8TTUTQdR6t3XA4lcEpBgpuNDd0r+gN2 i6flH16M/AxJOkI+lDbcf108kqwRK2WhsYKSw5M3Qtz8niL5XP7njXK99amuTOZa35CnN7Og vCU+270nd3S9ebY1sKU41vHP3bqNjsXfvp8qJ05Mp80LfLTyxjFDje42CvYJFo7rbA5m6+ng S2kx7SW+7VauHRKSiVB4uhBqRvEfYo7NXlEDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 06:20:27 -0000 --_000_6037C2BEC3C54859AF6FD12300EFB8A5ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCk9uIDIwMTgtMDEtMTIsIDAxOjQ1LCAiUVVJQyBvbiBiZWhhbGYgb2YgUm9iZXJ0byBQZW9u IiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdyb3RlOg0KDQpI YXZpbmcgdGhlIHNlcnZlciBzcGVjaWZ5IHRoZSBjb25uSUQtc2l6ZSBhcyBwYXJ0IG9mIHRoZSBj b25uZWN0aW9uIHNldHVwK3ZlcnNpb24gbmVnb3RpYXRpb24gd291bGQgY2VydGFpbmx5IGJlIGdy ZWFzZS15Lg0KDQpBIGxhcmdlciBjb25uSUQgaGVscHMgdG8gc29sdmUgYSBsb3Qgb2YgTDQ8LT5M NyByb3V0aW5nIGlzc3VlcywgYWdyZWVkLCBwcmUtc3VwcG9zaW5nIHRoYXQgdGhlIHNlcnZlciBh bHdheXMgcGlja3MgdGhlIG5ldy9hbHRlcm5hdGUgY29ubi1JRCBmb3IgdGhlIGNsaWVudC4NCi09 Ug0KDQo+ICsxLiBBbmQgc2V0dGxpbmcgdGhpcyBpc3N1ZSBlYXJseSBpbiB0aGUgUVVJQyBkZXZl bG9wbWVudCB3b3VsZCBzZWN1cmUgd2lkZSBzdXBwb3J0IGluIHNlcnZlcnMgc3VjaCBhcyBlbnZv eSBhbmQgbmdueCBlYXJseSBvbiBmb3IgY29ubmVjdGlvbiBlc3RhYmxpc21lbnQuDQo= --_000_6037C2BEC3C54859AF6FD12300EFB8A5ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <867483B4161086429DA862615CEBC82C@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4wcHQgODQyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9y PSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPk9uIDIwMTgtMDEtMTIsIDAx OjQ1LCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBSb2JlcnRvIFBlb24mcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwv YT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIj5mZW5peEBmYi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQt YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPkhhdmluZyB0aGUgc2VydmVyIHNwZWNpZnkgdGhlIGNvbm5JRC1z aXplIGFzIHBhcnQgb2YgdGhlIGNvbm5lY3Rpb24gc2V0dXAmIzQzO3ZlcnNpb24gbmVnb3RpYXRp b24gd291bGQgY2VydGFpbmx5IGJlIGdyZWFzZS15Ljxicj4NCjxicj4NCkEgbGFyZ2VyIGNvbm5J RCBoZWxwcyB0byBzb2x2ZSBhIGxvdCBvZiBMNCZsdDstJmd0O0w3IHJvdXRpbmcgaXNzdWVzLCBh Z3JlZWQsIHByZS1zdXBwb3NpbmcgdGhhdCB0aGUgc2VydmVyIGFsd2F5cyBwaWNrcyB0aGUgbmV3 L2FsdGVybmF0ZSBjb25uLUlEIGZvciB0aGUgY2xpZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7Zm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBh dXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPi09 UjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7ICYjNDM7MS4gQW5kIHNldHRsaW5n IHRoaXMgaXNzdWUgZWFybHkgaW4gdGhlIFFVSUMgZGV2ZWxvcG1lbnQgd291bGQgc2VjdXJlIHdp ZGUgc3VwcG9ydCBpbiBzZXJ2ZXJzIHN1Y2ggYXMgZW52b3kgYW5kIG5nbnggZWFybHkgb24gZm9y IGNvbm5lY3Rpb24gZXN0YWJsaXNtZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6037C2BEC3C54859AF6FD12300EFB8A5ericssoncom_-- From nobody Thu Jan 11 23:30:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FDB12D890 for ; Thu, 11 Jan 2018 23:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r7qZX8Z6AL6X for ; Thu, 11 Jan 2018 23:30:02 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3BFB812700F for ; Thu, 11 Jan 2018 23:30:00 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0C7Tnt2015934; Fri, 12 Jan 2018 08:29:49 +0100 Date: Fri, 12 Jan 2018 08:29:49 +0100 From: Willy Tarreau To: Martin Thomson Cc: Victor Vasiliev , Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , "Lubashev, Igor" , Roberto Peon , IETF QUIC WG Subject: Re: Increasing QUIC connection ID size Message-ID: <20180112072949.GA15927@1wt.eu> References: <1bf50145082642f1add41595c73ec4a1@usma1ex-dag1mb5.msg.corp.akamai.com> <21333E2A-AA5D-4D99-8315-3468242493DF@fb.com> <20180112055554.GA15873@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 07:30:04 -0000 On Fri, Jan 12, 2018 at 05:18:52PM +1100, Martin Thomson wrote: > https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-00 is > currently DTLS specific. Is this something that you feel should be > more general? Hmm I don't know yet, this makes me think. I'm realizing that very often the LB will not decide on the server from the initial packet if it starts to take certain elements in consideration, so it may be needed to pass the server identifier later. In the most basic DSR case it will work though. But above there's provision for changing the connection ID later so that could possibly work to some extents. I need more time to think about it and I'm lagging behind on QUIC design, so I'm mostly focusing on general architectural points that I want to be sure we don't forget to address. Willy From nobody Fri Jan 12 05:58:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2312D77D for ; Fri, 12 Jan 2018 05:58:50 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FDV7gIqxUgpO for ; Fri, 12 Jan 2018 05:58:46 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3BE112E869 for ; Fri, 12 Jan 2018 05:58:46 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id t63so5950540iod.0 for ; Fri, 12 Jan 2018 05:58:46 -0800 (PST) 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=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=g0qI3lxKZEV0GxCwkvxb6Vt5yLAa8GYFaR+y+BTXtGrXnp7u27cTIuBurB2Ayv2AQW bwX375IYd10JKHX+vpboB42VnsGLwBWcjYxSfkO2ePxoRPQWm95U2XxRnQzrn6ktvAvb hqlFoRUaQ/BIA1Aq1foe1g35XflpM3pp52FdqYJX32TpNLYGswISGeF+43lfqT8WZ8/w oNJ3oqfTrlF0lUvdYU/zQau5Ih1++2C+p85bxlMJ0rf34y6Wl9tW9KK2GIBwbenKA0gM LHrDoe17vem1j3WORTpfV2ZpGjoQcoMpC1S6Al53QBsuQJ+GyWjAr14Vmp1wDoIAzVs3 EMLQ== 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=d61a15hbM8tQPqvEbUviDoe3In+rQO0/WiAFrCrzqpg=; b=HoH8qpBxa9Wuy61CCdNQfwJnTd1szC0IWt+bYtxXI3i8DzSPKplux1Vw9XXNQK85R4 aNPY4JiMnxW98lEkbu/gjjN4VYmC6AGs2rJGiv2Gm8VN9FVqjuyuLAZoEHw1l15Og8vi U0FJ4jQuK+pEPQcil1he9zkTTeCNbnu4Z/g3AuYObk/3+wJiGWNf8benOa3xUw3LB7Yc xV4QI6t2i1OhJz4vRQ+fiRTg4GSpvJfnR3b7Ddto4pZ1v03K+eqLtiCF29yxO89gmGaA 5jOZ7iHg+bzmlPQP4hNxT/TYL9q/arLBhYnN9i4+OnpnQ5FvNkxx8gFd1iT/aCNBCX2q Q9KA== X-Gm-Message-State: AKwxytdI7AXyddyYFUPjz8mNzGS1+zz5rpEoZ844fdhS4NXQWuJt5uiZ LAuTR/4vNR4CWHoPxM85eQBa0CigQTB/ltu93/trJQ== X-Google-Smtp-Source: ACJfBotDTUqAKOYhx2pHfDHgBVO7iLVPnDgPM31/LLynBNhRpH45+fNtuL54feKtAEtIqfyQDGplLfPrCfqoG9lEdlg= X-Received: by 10.107.79.2 with SMTP id d2mr23801780iob.170.1515765525676; Fri, 12 Jan 2018 05:58:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.82.17 with HTTP; Fri, 12 Jan 2018 05:58:24 -0800 (PST) In-Reply-To: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> From: Ian Swett Date: Fri, 12 Jan 2018 08:58:24 -0500 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f4f5e803beb0b910af056294a93d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 13:58:50 -0000 --f4f5e803beb0b910af056294a93d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would like to leave QUIC open for longer connection IDs in future versions, so I'd like to specify the invariants in such a way that longer connection Ids wouldn't violate them(ie: Victor's suggestion of =E2=80=9Cmiddleboxes always get first 64 bits and they have useful entro= py to distinguish connections=E2=80=9D.) but I'm reluctant to include 128 bit con= nection IDs in v1 at this point. I would also echo Christian's sentiment that the incremental overhead starts becoming fairly large. On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema wrote: > We have a prototype implementation in Picoquic in which the connection ID > can be split so some bits are random and some bits are used for routing t= o > a specific server -- thanks Igor for that. It makes for nice experiments, > but it is a denial of service waiting to happen. For example, attackers > could set the bits in such a way as to target a specific server in a pool= , > or they could learn which connections are on the same server and use that > later for some kind of same server attack. It would be better if that > information was not in clear text. In fact, the picoquic implementation u= se > a callback to ask for the new value -- presumably from the router. That > callback could return anything, including an encrypted value. > > On the other hand, it is not clear to me that we need full encryption. Fo= r > example, assume that the server that needs a connection ID can ask it fro= m > the router. The router could pick one at random, make sure that it is > properly documented in the routing tables and that there is no collision, > and then pass it back to the server. No encryption needed, but of course > lots of state. > > If the router does not want to keep the state, it can indeed create a > connection ID by encrypting a tuple. But it does not > follow that the encryption needs to be 128 bits. For example, it could us= e > a 64 bit algorithm like Blowfish. > > So I am not sure that we actually need to change the length. And I am a > bit concerned by the incremental overhead if the connection ID suddenly > becomes very large. > > > > On 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Actually, on encryption of connection ID, this is not so simple. > > We must assume there is only a single key for many connections because th= e > router is not part of a key exchange. This unique value or counter used f= or > encrypting a single block cannot be the same for two different connection= s > ID=E2=80=99s, but it can be public. This means that it must be stored in = the packet > header. And, as it turns out, random connection ID chosen by a trusted > source, can be used for such a unique value. But then it must be used to > encrypt and/or authenticate something else carrying the actual routing > information. So now you start to really need some extra payload. > > Alternatively the routing information is entirely random such as content > hashed routing. Then you only need to authenticate the routing data. You > can do that with a HMAC, and CMAC could probably also work. The additiona= l > benefit is that you can probably get away with 64-bits for all routing > information possibly including the auth tag. Say 48 bits of routing data > and 16 bits of auth tag. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) > wrote: > > I am interested in exploring this proposal, since it allows for more > flexible schemes of encoding routing metadata and a checksum. I would al= so > like to be explicit about the connection ID size in a packet header, > though, since it greatly simplifies the implementation. > > > > - Igor > > *From:* Victor Vasiliev [mailto:vasilvv@google.com] > *Sent:* Thursday, January 11, 2018 6:16 PM > *To:* IETF QUIC WG > *Subject:* Increasing QUIC connection ID size > > > > Hi everyone, > > > > In the current version of QUIC, the connection ID size is fixed to be a > 64-bit opaque blob, and that is set as an invariant in the protocol. > > > > I=E2=80=99ve looked into possibility of using a connection ID to encode t= he > specific server details into it (to provide stability of the connection i= n > case of load balancing changes, especially BGP flaps for anycast IPs), an= d > have chatted about this with other people I knew were interested in this. > It seems like 64 bits might be too small for this purpose, and we might > want to leave an opportunity to extend the connection ID size. > > > > The basic idea is that you want to be able to: > > 1. Store some routing metadata in the connection ID. > 2. Have some entropy that allows distinguish users with identical > routing metadata. > 3. Have a checksum to ensure the validity of routing information > 4. Encrypt the information above to prevent disclosing the route > information and allow generating uncorrelatable connection IDs. > > There are two underlying issues here. The first problem is that all of > this does not fit well into 64 bits, and you have to seriously compromise > on the strength of the checksum (which is bad especially if you want it t= o > be a MAC rather than a checksum). The second problem is that encrypting > 64-bit values fast is actually fairly hard since the block ciphers easily > available in hardware have 128-bit block size, and the performance > requirements on load balancers are tighter than on servers. > > > > In other words, having a 128-bit connection ID provides for an easy secur= e > way to generate unlinkable connection IDs on migration. > > > > So, the problem we=E2=80=99re trying to solve is that the connection ID i= s too > small. There are two questions I believe the working group should answer > at this point: > > 1. Do we want to address this problem at this point in standardization > process? > 2. If we don=E2=80=99t address this problem right now, how do we struc= ture the > standard in a way that we can extend the connection ID in the future? > > There are multiple ways to solve the problem of making connection ID > larger. One is to just add extra bit to the =E2=80=9Comit connection ID= =E2=80=9D field to > allow 128-bit connection IDs. Another approach is to allow connection ID > size to be explicitly specified by the server, and then assume that the > load balancer knows that size and no one else on the path needs to read i= t. > > > > There=E2=80=99s also a question of how much of connection IDs do middlebo= xes > (excluding load balancers and other boxes owned by the same entity as > either client or server) need to know. We could go for both =E2=80=9Cmid= dleboxes > should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleb= oxes should not > read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s = also a room for > more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 = bits and > they have useful entropy to distinguish connections=E2=80=9D. > > > > -- Victor. > > > --f4f5e803beb0b910af056294a93d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I would like to leave QUIC open for longer connection IDs = in future versions, so I'd like to specify the invariants in such a way= that longer connection Ids wouldn't violate them(ie: Victor's sugg= estion of=C2=A0=E2=80=9Cmiddleboxes always get first 64 bits and they have = useful entropy to distinguish connections=E2=80=9D.) but I'm reluctant = to include 128 bit connection IDs in v1 at this point.

    I would also= echo Christian's sentiment that the incremental overhead starts becomi= ng fairly large.

    On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema <huitema@h= uitema.net> wrote:
    =20 =20 =20
    We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value.

    On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state.

    If the router does not want to keep the state, it can indeed create a connection ID by encrypting a <nonce, server-ID> tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large.



    On 1/11/2018 2:25 P= M, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
    =20
    Actually, on encryption of connection ID, this is not so simple.

    We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but it can be public. This means that it must be stored in the packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload.

    Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag.
    Kind Regards,
    Mikkel Fahn=C3=B8e J=C3=B8rgensen


    On 12 January 2018 at 00= .57.21, Lubashev, Igor (ilub= ashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum.=C2=A0 I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibi= lity of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing metadata.
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The first problem is that all of this doe= s not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration.

    =C2=A0

    So, the problem we=E2=80=99re tr= ying to solve is that the connection ID is too small.=C2=A0 There are two questions I believe the working group should answer at this point:

    1. Do we want to address this problem at this point in standardization process?
    2. If we don=E2=80=99t address this problem right now,= how do we structure the standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of making connection ID larger.=C2= =A0 One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D field to allow 128-bit connect= ion IDs.=C2=A0 Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question = of how much of connection IDs do middleboxes (excluding load balancers and other boxes owned by the same entity as either client or server) need to know.=C2= =A0 We could go for both =E2=80=9Cmiddleboxes should be a= lways able to read the entire ID=E2=80=9D and =E2=80=9Cmidd= leboxes should not read connection IDs at all options=E2=80= =9D, but I think there=E2=80=99s also a room for more flex= ible formulations like =E2=80=9Cmiddleboxes always get fir= st 64 bits and they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.



    --f4f5e803beb0b910af056294a93d-- From nobody Fri Jan 12 06:14:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1353512D77D for ; Fri, 12 Jan 2018 06:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tWqgsh2X7L1b for ; Fri, 12 Jan 2018 06:14:07 -0800 (PST) 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 DF9A012773A for ; Fri, 12 Jan 2018 06:14:07 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0CEBp6b024796; Fri, 12 Jan 2018 14:13:58 GMT 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=YcnrYl+7XtWgIgAZMRWzt2okMVqyZiAer4xW/SMgHUU=; b=mtFpPmXm3RKmFnqQV2YF1zNw5gGkxpmWlPZZtOz3LX49LZFWluT2xdnWQI29YzKxjjNh E5RS13iKq+hZCiF/T3XPcKy7Z5NVdLW5t/VNIQIawQT0Rozj6D1cG7fBca/+FWv45DUZ VUS9MgRVRskqjtB1/9+KuGydnFbbGbShdhMTBeTa4iI7DFcNBzlHzPguab6ODDrDXOi/ pa2YU+l2h0qOzH9Vy7vtm+hk7HWsypcVTTxWHIYh0K8ox0BxTJYVAJhjahEgiA7QYi7w 3d20dUJfmo6N1Bu9QWkg/P3+m+lBuuA3jK4juhmKd0l7OBAsvMmj75GBoOHwNImmsoW6 rg== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2fda8yvbqm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 14:13:57 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0CEB5bO021231; Fri, 12 Jan 2018 09:13:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2fd6pcr8wm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 09:13:56 -0500 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, 12 Jan 2018 09:13:54 -0500 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, 12 Jan 2018 09:13:54 -0500 From: "Lubashev, Igor" To: "huitema@huitema.net" , "ianswett@google.com" CC: "quic@ietf.org" Subject: RE: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizIxs65b7ysujkqedmh6APARjaNvVjxAgABe4YCAACejgIAAu4AA//+wgmo= Date: Fri, 12 Jan 2018 14:13:53 +0000 Message-ID: <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@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_69f4ff2b505d4574b369ed872df9b1beusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120194 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120194 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 14:14:11 -0000 --_000_69f4ff2b505d4574b369ed872df9b1beusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the 128-bit option is not in V1, then it will be required for the 128-bi= t option to be signaled in the packet's invariant section (like a bit in th= e 1st byte). Otherwise, the very load balancers this is designed for will n= ot know whether the connection ID has 64- or 128-bit format. (It would need= to support both, since there would be clients stuck at V1.) In fact, the security promises of having a 128-bit connection ID option (al= lows for making routing info harder to forge) are greatly diminished, when = a load balancer has to support 64-bit connection IDs "forever". -----Original Message----- From: Ian Swett [ianswett@google.com] Received: Friday, 12 Jan 2018, 8:59AM To: Christian Huitema [huitema@huitema.net] CC: IETF QUIC WG [quic@ietf.org] Subject: Re: Increasing QUIC connection ID size I would like to leave QUIC open for longer connection IDs in future version= s, so I'd like to specify the invariants in such a way that longer connecti= on Ids wouldn't violate them(ie: Victor's suggestion of =93middleboxes alwa= ys get first 64 bits and they have useful entropy to distinguish connection= s=94.) but I'm reluctant to include 128 bit connection IDs in v1 at this po= int. I would also echo Christian's sentiment that the incremental overhead start= s becoming fairly large. On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema > wrote: We have a prototype implementation in Picoquic in which the connection ID c= an be split so some bits are random and some bits are used for routing to a= specific server -- thanks Igor for that. It makes for nice experiments, bu= t it is a denial of service waiting to happen. For example, attackers could= set the bits in such a way as to target a specific server in a pool, or th= ey could learn which connections are on the same server and use that later = for some kind of same server attack. It would be better if that information= was not in clear text. In fact, the picoquic implementation use a callback= to ask for the new value -- presumably from the router. That callback coul= d return anything, including an encrypted value. On the other hand, it is not clear to me that we need full encryption. For = example, assume that the server that needs a connection ID can ask it from = the router. The router could pick one at random, make sure that it is prope= rly documented in the routing tables and that there is no collision, and th= en pass it back to the server. No encryption needed, but of course lots of = state. If the router does not want to keep the state, it can indeed create a conne= ction ID by encrypting a tuple. But it does not follow t= hat the encryption needs to be 128 bits. For example, it could use a 64 bit= algorithm like Blowfish. So I am not sure that we actually need to change the length. And I am a bit= concerned by the incremental overhead if the connection ID suddenly become= s very large. On 1/11/2018 2:25 PM, Mikkel Fahn=F8e J=F8rgensen wrote: Actually, on encryption of connection ID, this is not so simple. We must assume there is only a single key for many connections because the = router is not part of a key exchange. This unique value or counter used for= encrypting a single block cannot be the same for two different connections= ID=92s, but it can be public. This means that it must be stored in the pac= ket header. And, as it turns out, random connection ID chosen by a trusted = source, can be used for such a unique value. But then it must be used to en= crypt and/or authenticate something else carrying the actual routing inform= ation. So now you start to really need some extra payload. Alternatively the routing information is entirely random such as content ha= shed routing. Then you only need to authenticate the routing data. You can = do that with a HMAC, and CMAC could probably also work. The additional bene= fit is that you can probably get away with 64-bits for all routing informat= ion possibly including the auth tag. Say 48 bits of routing data and 16 bit= s of auth tag. Kind Regards, Mikkel Fahn=F8e J=F8rgensen On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote: I am interested in exploring this proposal, since it allows for more flexib= le schemes of encoding routing metadata and a checksum. I would also like = to be explicit about the connection ID size in a packet header, though, sin= ce it greatly simplifies the implementation. * Igor From: Victor Vasiliev [mailto:vasilvv@google.com= ] Sent: Thursday, January 11, 2018 6:16 PM To: IETF QUIC WG > Subject: Increasing QUIC connection ID size Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-= bit opaque blob, and that is set as an invariant in the protocol. I=92ve looked into possibility of using a connection ID to encode the speci= fic server details into it (to provide stability of the connection in case = of load balancing changes, especially BGP flaps for anycast IPs), and have = chatted about this with other people I knew were interested in this. It se= ems like 64 bits might be too small for this purpose, and we might want to = leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routin= g metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route informa= tion and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of thi= s does not fit well into 64 bits, and you have to seriously compromise on t= he strength of the checksum (which is bad especially if you want it to be a= MAC rather than a checksum). The second problem is that encrypting 64-bit= values fast is actually fairly hard since the block ciphers easily availab= le in hardware have 128-bit block size, and the performance requirements on= load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure = way to generate unlinkable connection IDs on migration. So, the problem we=92re trying to solve is that the connection ID is too sm= all. There are two questions I believe the working group should answer at = this point: 1. Do we want to address this problem at this point in standardization p= rocess? 2. If we don=92t address this problem right now, how do we structure the= standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger= . One is to just add extra bit to the =93omit connection ID=94 field to al= low 128-bit connection IDs. Another approach is to allow connection ID siz= e to be explicitly specified by the server, and then assume that the load b= alancer knows that size and no one else on the path needs to read it. There=92s also a question of how much of connection IDs do middleboxes (exc= luding load balancers and other boxes owned by the same entity as either cl= ient or server) need to know. We could go for both =93middleboxes should b= e always able to read the entire ID=94 and =93middleboxes should not read c= onnection IDs at all options=94, but I think there=92s also a room for more= flexible formulations like =93middleboxes always get first 64 bits and the= y have useful entropy to distinguish connections=94. -- Victor. --_000_69f4ff2b505d4574b369ed872df9b1beusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If the 128-bit option is not in V1, then it will be requir= ed for the 128-bit option to be signaled in the packet's invariant section = (like a bit in the 1st byte). Otherwise, the very load balancers this is designed for will not know whether the con= nection ID has 64- or 128-bit format. (It would need to support both, since= there would be clients stuck at V1.)

    In fact, the security promises of having a 128-bit connection ID option (al= lows for making routing info harder to forge) are greatly diminished, when = a load balancer has to support 64-bit connection IDs "forever".
    -----Original Message-----
    From: Ian Swett [ianswett@google.com]
    Received: Friday, 12 Jan 2018, 8:59AM
    To: Christian Huitema [huitema@huitema.net]
    CC: IETF QUIC WG [quic@ietf.org]
    Subject: Re: Increasing QUIC connection ID size
    I would like to leave QUIC open for longer connection IDs = in future versions, so I'd like to specify the invariants in such a way tha= t longer connection Ids wouldn't violate them(ie: Victor's suggestion of&nb= sp;=93middleboxes always get first 64 bits and they have useful entropy to distinguish connections=94.) but I'm reluc= tant to include 128 bit connection IDs in v1 at this point.

    I would also echo Christian's sentiment that the incremental overhead start= s becoming fairly large.

    On Thu, Jan 11, 2018 at 9:47 PM, Christian Huite= ma <huitema@huitem= a.net> wrote:
    We have a prototype implementation in Picoquic in = which the connection ID can be split so some bits are random and some bits = are used for routing to a specific server -- thanks Igor for that. It makes= for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the = bits in such a way as to target a specific server in a pool, or they could = learn which connections are on the same server and use that later for some = kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic= implementation use a callback to ask for the new value -- presumably from = the router. That callback could return anything, including an encrypted val= ue.

    On the other hand, it is not clear to me that we need full encryption. For = example, assume that the server that needs a connection ID can ask it from = the router. The router could pick one at random, make sure that it is prope= rly documented in the routing tables and that there is no collision, and then pass it back to the server. No en= cryption needed, but of course lots of state.

    If the router does not want to keep the state, it can indeed create a conne= ction ID by encrypting a <nonce, server-ID> tuple. But it does not fo= llow that the encryption needs to be 128 bits. For example, it could use a = 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit= concerned by the incremental overhead if the connection ID suddenly become= s very large.



    On 1/11/2018 2:25 PM, M= ikkel Fahn=F8e J=F8rgensen wrote:
    Actually, on encryption of connection ID, this is not so simple.

    We must assume there is only a single key for many connections because the = router is not part of a key exchange. This unique value or counter used for= encrypting a single block cannot be the same for two different connections= ID=92s, but it can be public. This means that it must be stored in the packet header. And, as it turns out, r= andom connection ID chosen by a trusted source, can be used for such a uniq= ue value. But then it must be used to encrypt and/or authenticate something= else carrying the actual routing information. So now you start to really need some extra payload.

    Alternatively the routing information is entirely random such as content ha= shed routing. Then you only need to authenticate the routing data. You can = do that with a HMAC, and CMAC could probably also work. The additional bene= fit is that you can probably get away with 64-bits for all routing information possibly including the auth = tag. Say 48 bits of routing data and 16 bits of auth tag.

    Kind Regards,
    Mikkel Fahn=F8e = J=F8rgensen


    On 12 January 2018 at 00.57.21= , Lubashev, Igor (= ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it= allows for more flexible schemes of encoding routing metadata and a checks= um.  I would also like to be explicit about the connection ID size in = a packet header, though, since it greatly simplifies the implementation.

     

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

     

    Hi everyone,

     

    In the current version of QUIC, the connection ID si= ze is fixed to be a 64-bit opaque blob, and that is set as an invariant in = the protocol.

     

    I=92ve looked into possibility of using a connection= ID to encode the specific server details into it (to provide stability of = the connection in case of load balancing changes, especially BGP flaps for = anycast IPs), and have chatted about this with other people I knew were interested in this.  It seems like= 64 bits might be too small for this purpose, and we might want to leave an= opportunity to extend the connection ID size.

     

    The basic idea is that you want to be able to:

    1. Store some routing metada= ta in the connection ID.
    2. Have some entropy th= at allows distinguish users with identical routing metadata.
    3. Have a checksum to e= nsure the validity of routing information
    4. Encrypt the informat= ion above to prevent disclosing the route information and allow generating = uncorrelatable connection IDs.

    There are two underlying issues here.  The firs= t problem is that all of this does not fit well into 64 bits, and you have = to seriously compromise on the strength of the checksum (which is bad espec= ially if you want it to be a MAC rather than a checksum).  The second problem is that encrypting 64-bit value= s fast is actually fairly hard since the block ciphers easily available in = hardware have 128-bit block size, and the performance requirements on load = balancers are tighter than on servers.  

     

    In other words, having a 128-bit connection ID provi= des for an easy secure way to generate unlinkable connection IDs on migrati= on.

     

    So, the problem we=92re trying to solve is that the = connection ID is too small.  There are two questions I believe the wor= king group should answer at this point:

    1. Do we want to address thi= s problem at this point in standardization process?
    2. If we don=92t addres= s this problem right now, how do we structure the standard in a way that we= can extend the connection ID in the future?

    There are multiple ways to solve the problem of maki= ng connection ID larger.  One is to just add extra bit to the =93omit = connection ID=94 field to allow 128-bit connection IDs.  Another appro= ach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that= size and no one else on the path needs to read it.

     

    There=92s also a question of how much of connection = IDs do middleboxes (excluding load balancers and other boxes owned by the s= ame entity as either client or server) need to know.  We could go for = both =93middleboxes should be always able to read the entire ID=94 and =93middleboxes should not read connection IDs at= all options=94, but I think there=92s also a room for more flexible formul= ations like =93middleboxes always get first 64 bits and they have useful en= tropy to distinguish connections=94.

     

      -- Victor.



    --_000_69f4ff2b505d4574b369ed872df9b1beusma1exdag1mb5msgcorpak_-- From nobody Fri Jan 12 06:35:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E512E884 for ; Fri, 12 Jan 2018 06:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 hSlYV3yNQrTD for ; Fri, 12 Jan 2018 06:35:10 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 633EB124319 for ; Fri, 12 Jan 2018 06:35:10 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id d11so6055683iog.5 for ; Fri, 12 Jan 2018 06:35:10 -0800 (PST) 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=bhvbAvgDtc4r7E9z/es0TvJ88wyVxeTdNcPcZrH9fz4=; b=nEMssOwk2sbxDKxGqe94rBPc1rbIZvzZxzkWhLeWFlkoTXGU3NEiIqYYnNuqh2gHTT w8zJdk6gD+CjsnW28+Aim8RgvhzSDQAuH2RH1st3mxJiT373KsC0Cio2os8oJzBEDwJD WV4AwlPP2zKr9DAVlpilKTXpYdzO89opGJBoXgUu4tRnhvLTkdDCJ73uDnslYtPA+p+U 2nqCG2F29xZDkNDk2eKURRZO5SPTKZVDWTNF2hLq5NqG0bvda0WdN1A1u/xbEp0A/wFS R2dvZbhO+bATb4jIrNlggNV5jW5IlNAa5pmhD1B5eEnzwT02rQGWsufsQIN3YDi+sZu4 xuaQ== 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=bhvbAvgDtc4r7E9z/es0TvJ88wyVxeTdNcPcZrH9fz4=; b=o2DXynZLCSiHs0cIQNI8jUomEuZ7ZOyRrK1UG+o7iixhTGVGYVk6RVVBwembO5QezA twWqvrD3h8t2xAv7BSnIoeS79Hq8DQp9cgoa3aMNBifuC0F+f7Esv8eCvnBCRUuA+gRV SKReW5EL6pHUtbgtcrYCbzcHciD11U5SPh4XjhwCnPCkx5GotoOaFLbChE5Qrw9ZuQzu 7Hn+oftQLmiaMcR8YyUXvLbikpv6koxRFGXOY9LnTXe4v1telEuesIGrXkdg51r4+M3M b30jKhe3RYp+v4uT6ShY5XbiGBbAlRvjDKvWauh+djujP0EXOQ/IVBFPz6bOoMtKdULM WjMw== X-Gm-Message-State: AKGB3mIV5nSo0GEEv/+ucKwVNl39DmRKPTaNPyAOkYv37SZisbQ8qBN7 OooVXbdFr/8c10DB1tL8tir4Q8NXiAjcfHMwfrZd8Q== X-Google-Smtp-Source: ACJfBovjR9SkNfMTBKEPaFZp7/VPpPVS1+Bv2D0WMS+7SEYfnYCNFPe6ItLEDwwbFbQe2WFEYZ7u9ukPgwD1BJUDLHc= X-Received: by 10.107.201.4 with SMTP id z4mr25403837iof.154.1515767709375; Fri, 12 Jan 2018 06:35:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.82.17 with HTTP; Fri, 12 Jan 2018 06:34:48 -0800 (PST) In-Reply-To: <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Fri, 12 Jan 2018 09:34:48 -0500 Message-ID: Subject: Re: Increasing QUIC connection ID size To: "Lubashev, Igor" Cc: "huitema@huitema.net" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b7042e1ead60562952b44" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 14:35:13 -0000 --94eb2c0b7042e1ead60562952b44 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think we'll want support for both no matter how we do this. On Fri, Jan 12, 2018 at 9:13 AM, Lubashev, Igor wrote= : > If the 128-bit option is not in V1, then it will be required for the > 128-bit option to be signaled in the packet's invariant section (like a b= it > in the 1st byte). Otherwise, the very load balancers this is designed for > will not know whether the connection ID has 64- or 128-bit format. (It > would need to support both, since there would be clients stuck at V1.) > > In fact, the security promises of having a 128-bit connection ID option > (allows for making routing info harder to forge) are greatly diminished, > when a load balancer has to support 64-bit connection IDs "forever". > > > -----Original Message----- > *From:* Ian Swett [ianswett@google.com] > *Received:* Friday, 12 Jan 2018, 8:59AM > *To:* Christian Huitema [huitema@huitema.net] > *CC:* IETF QUIC WG [quic@ietf.org] > *Subject:* Re: Increasing QUIC connection ID size > > I would like to leave QUIC open for longer connection IDs in future > versions, so I'd like to specify the invariants in such a way that longer > connection Ids wouldn't violate them(ie: Victor's suggestion > of =E2=80=9Cmiddleboxes always get first 64 bits and they have useful ent= ropy to > distinguish connections=E2=80=9D.) but I'm reluctant to include 128 bit c= onnection > IDs in v1 at this point. > > I would also echo Christian's sentiment that the incremental overhead > starts becoming fairly large. > > On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema > wrote: > >> We have a prototype implementation in Picoquic in which the connection I= D >> can be split so some bits are random and some bits are used for routing = to >> a specific server -- thanks Igor for that. It makes for nice experiments= , >> but it is a denial of service waiting to happen. For example, attackers >> could set the bits in such a way as to target a specific server in a poo= l, >> or they could learn which connections are on the same server and use tha= t >> later for some kind of same server attack. It would be better if that >> information was not in clear text. In fact, the picoquic implementation = use >> a callback to ask for the new value -- presumably from the router. That >> callback could return anything, including an encrypted value. >> >> On the other hand, it is not clear to me that we need full encryption. >> For example, assume that the server that needs a connection ID can ask i= t >> from the router. The router could pick one at random, make sure that it = is >> properly documented in the routing tables and that there is no collision= , >> and then pass it back to the server. No encryption needed, but of course >> lots of state. >> >> If the router does not want to keep the state, it can indeed create a >> connection ID by encrypting a tuple. But it does not >> follow that the encryption needs to be 128 bits. For example, it could u= se >> a 64 bit algorithm like Blowfish. >> >> So I am not sure that we actually need to change the length. And I am a >> bit concerned by the incremental overhead if the connection ID suddenly >> becomes very large. >> >> >> >> On 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> >> Actually, on encryption of connection ID, this is not so simple. >> >> We must assume there is only a single key for many connections because >> the router is not part of a key exchange. This unique value or counter u= sed >> for encrypting a single block cannot be the same for two different >> connections ID=E2=80=99s, but it can be public. This means that it must = be stored >> in the packet header. And, as it turns out, random connection ID chosen = by >> a trusted source, can be used for such a unique value. But then it must = be >> used to encrypt and/or authenticate something else carrying the actual >> routing information. So now you start to really need some extra payload. >> >> Alternatively the routing information is entirely random such as content >> hashed routing. Then you only need to authenticate the routing data. You >> can do that with a HMAC, and CMAC could probably also work. The addition= al >> benefit is that you can probably get away with 64-bits for all routing >> information possibly including the auth tag. Say 48 bits of routing data >> and 16 bits of auth tag. >> >> Kind Regards, >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >> >> On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) >> wrote: >> >> I am interested in exploring this proposal, since it allows for more >> flexible schemes of encoding routing metadata and a checksum. I would a= lso >> like to be explicit about the connection ID size in a packet header, >> though, since it greatly simplifies the implementation. >> >> >> >> - Igor >> >> *From:* Victor Vasiliev [mailto:vasilvv@google.com] >> *Sent:* Thursday, January 11, 2018 6:16 PM >> *To:* IETF QUIC WG >> *Subject:* Increasing QUIC connection ID size >> >> >> >> Hi everyone, >> >> >> >> In the current version of QUIC, the connection ID size is fixed to be a >> 64-bit opaque blob, and that is set as an invariant in the protocol. >> >> >> >> I=E2=80=99ve looked into possibility of using a connection ID to encode = the >> specific server details into it (to provide stability of the connection = in >> case of load balancing changes, especially BGP flaps for anycast IPs), a= nd >> have chatted about this with other people I knew were interested in this= . >> It seems like 64 bits might be too small for this purpose, and we might >> want to leave an opportunity to extend the connection ID size. >> >> >> >> The basic idea is that you want to be able to: >> >> 1. Store some routing metadata in the connection ID. >> 2. Have some entropy that allows distinguish users with identical >> routing metadata. >> 3. Have a checksum to ensure the validity of routing information >> 4. Encrypt the information above to prevent disclosing the route >> information and allow generating uncorrelatable connection IDs. >> >> There are two underlying issues here. The first problem is that all of >> this does not fit well into 64 bits, and you have to seriously compromis= e >> on the strength of the checksum (which is bad especially if you want it = to >> be a MAC rather than a checksum). The second problem is that encrypting >> 64-bit values fast is actually fairly hard since the block ciphers easil= y >> available in hardware have 128-bit block size, and the performance >> requirements on load balancers are tighter than on servers. >> >> >> >> In other words, having a 128-bit connection ID provides for an easy >> secure way to generate unlinkable connection IDs on migration. >> >> >> >> So, the problem we=E2=80=99re trying to solve is that the connection ID = is too >> small. There are two questions I believe the working group should answe= r >> at this point: >> >> 1. Do we want to address this problem at this point in >> standardization process? >> 2. If we don=E2=80=99t address this problem right now, how do we stru= cture >> the standard in a way that we can extend the connection ID in the fut= ure? >> >> There are multiple ways to solve the problem of making connection ID >> larger. One is to just add extra bit to the =E2=80=9Comit connection ID= =E2=80=9D field to >> allow 128-bit connection IDs. Another approach is to allow connection I= D >> size to be explicitly specified by the server, and then assume that the >> load balancer knows that size and no one else on the path needs to read = it. >> >> >> >> There=E2=80=99s also a question of how much of connection IDs do middleb= oxes >> (excluding load balancers and other boxes owned by the same entity as >> either client or server) need to know. We could go for both =E2=80=9Cmi= ddleboxes >> should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddle= boxes should not >> read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s= also a room for >> more flexible formulations like =E2=80=9Cmiddleboxes always get first 64= bits and >> they have useful entropy to distinguish connections=E2=80=9D. >> >> >> >> -- Victor. >> >> >> > --94eb2c0b7042e1ead60562952b44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I think we'll want support for both no matter how we d= o this.

    On F= ri, Jan 12, 2018 at 9:13 AM, Lubashev, Igor <ilubashe@akamai.com&g= t; wrote:
    If the 128-bit option is not in V1, then it will be required= for the 128-bit option to be signaled in the packet's invariant sectio= n (like a bit in the 1st byte). Otherwise, the very load balancers this is designed for will not know whether the con= nection ID has 64- or 128-bit format. (It would need to support both, since= there would be clients stuck at V1.)

    In fact, the security promises of having a 128-bit connection ID option (al= lows for making routing info harder to forge) are greatly diminished, when = a load balancer has to support 64-bit connection IDs "forever".


    -----Original Message-----
    From: Ian Swett [ianswett@google.com]
    Received: Friday, 12 Jan 2018, 8:59AM
    To: Christian Huitema [huitema@huitema.net]
    CC: IETF QUIC WG [quic@ietf.org]
    Subject: Re: Increasing QUIC connection ID size

    I would like to leave QUIC open for longer connection IDs = in future versions, so I'd like to specify the invariants in such a way= that longer connection Ids wouldn't violate them(ie: Victor's sugg= estion of=C2=A0=E2=80=9Cmiddleboxes always get first 64 bits and they have useful entropy to distinguish connections=E2=80=9D.) but I&#= 39;m reluctant to include 128 bit connection IDs in v1 at this point.

    I would also echo Christian's sentiment that the incremental overhead s= tarts becoming fairly large.

    On Thu, Jan 11, 2018 at 9:47 PM, Christian Huite= ma <huitema@huitem= a.net> wrote:
    We have a prototype implementation in Picoquic in = which the connection ID can be split so some bits are random and some bits = are used for routing to a specific server -- thanks Igor for that. It makes= for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the = bits in such a way as to target a specific server in a pool, or they could = learn which connections are on the same server and use that later for some = kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic= implementation use a callback to ask for the new value -- presumably from = the router. That callback could return anything, including an encrypted val= ue.

    On the other hand, it is not clear to me that we need full encryption. For = example, assume that the server that needs a connection ID can ask it from = the router. The router could pick one at random, make sure that it is prope= rly documented in the routing tables and that there is no collision, and then pass it back to the server. No en= cryption needed, but of course lots of state.

    If the router does not want to keep the state, it can indeed create a conne= ction ID by encrypting a <nonce, server-ID> tuple. But it does not fo= llow that the encryption needs to be 128 bits. For example, it could use a = 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit= concerned by the incremental overhead if the connection ID suddenly become= s very large.



    On= 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
    Actually, on encryption of connection ID, this is not so simple.

    We must assume there is only a single key for many connections because the = router is not part of a key exchange. This unique value or counter used for= encrypting a single block cannot be the same for two different connections= ID=E2=80=99s, but it can be public. This means that it must be stored in the packet header. And, as it turns out, r= andom connection ID chosen by a trusted source, can be used for such a uniq= ue value. But then it must be used to encrypt and/or authenticate something= else carrying the actual routing information. So now you start to really need some extra payload.

    Alternatively the routing information is entirely random such as content ha= shed routing. Then you only need to authenticate the routing data. You can = do that with a HMAC, and CMAC could probably also work. The additional bene= fit is that you can probably get away with 64-bits for all routing information possibly including the auth = tag. Say 48 bits of routing data and 16 bits of auth tag.

    Kind Regards,
    Mikkel Fahn=C3=B8= e J=C3=B8rgensen


    On 12 Jan= uary 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it= allows for more flexible schemes of encoding routing metadata and a checks= um.=C2=A0 I would also like to be explicit about the connection ID size in = a packet header, though, since it greatly simplifies the implementation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID si= ze is fixed to be a 64-bit opaque blob, and that is set as an invariant in = the protocol.

    =C2=A0

    I=E2=80=99ve looked into possibility of using a conn= ection ID to encode the specific server details into it (to provide stabili= ty of the connection in case of load balancing changes, especially BGP flap= s for anycast IPs), and have chatted about this with other people I knew were interested in this.=C2=A0 It seems like= 64 bits might be too small for this purpose, and we might want to leave an= opportunity to extend the connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metada= ta in the connection ID.
    2. Have some entropy th= at allows distinguish users with identical routing metadata.
    3. Have a checksum to e= nsure the validity of routing information
    4. Encrypt the informat= ion above to prevent disclosing the route information and allow generating = uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The firs= t problem is that all of this does not fit well into 64 bits, and you have = to seriously compromise on the strength of the checksum (which is bad espec= ially if you want it to be a MAC rather than a checksum).=C2=A0 The second problem is that encrypting 64-bit value= s fast is actually fairly hard since the block ciphers easily available in = hardware have 128-bit block size, and the performance requirements on load = balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provi= des for an easy secure way to generate unlinkable connection IDs on migrati= on.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is tha= t the connection ID is too small.=C2=A0 There are two questions I believe t= he working group should answer at this point:

    1. Do we want to address thi= s problem at this point in standardization process?
    2. If we don=E2=80=99t = address this problem right now, how do we structure the standard in a way t= hat we can extend the connection ID in the future?

    There are multiple ways to solve the problem of maki= ng connection ID larger.=C2=A0 One is to just add extra bit to the =E2=80= =9Comit connection ID=E2=80=9D field to allow 128-bit connection IDs.=C2=A0= Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that= size and no one else on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of conne= ction IDs do middleboxes (excluding load balancers and other boxes owned by= the same entity as either client or server) need to know.=C2=A0 We could g= o for both =E2=80=9Cmiddleboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read conne= ction IDs at all options=E2=80=9D, but I think there=E2=80=99s also a room = for more flexible formulations like =E2=80=9Cmiddleboxes always get first 6= 4 bits and they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.




    --94eb2c0b7042e1ead60562952b44-- From nobody Fri Jan 12 07:51:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D138B12E89A for ; Fri, 12 Jan 2018 07:51:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cpBydV6GFBfA for ; Fri, 12 Jan 2018 07:51:10 -0800 (PST) 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 9BB5112E896 for ; Fri, 12 Jan 2018 07:51:10 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0CFl7Gu028117; Fri, 12 Jan 2018 15:51:01 GMT 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=cpfPwpE2LdVzwQEVmoigRUikhejW1lVkJ7pfa7pARJM=; b=oKcqGJkavEb7KUPvuVex5NTZWJ3B+MLF9k5ODvVgCzLVkeDWm1rDw9+eD+YGytbY1wh2 SnCJT7mcUmx8PeptyThnQ5HePFgmtU6Kn0sRaj+iotctspDZJNdR1EDIRS1PzLZnaUmQ eVaVNmR4usnZ5uZM+s5KE70yYChF4L7PEUpXozc/z/FQ4ZxGhe2AHM5rtZriW2j2Q3iK IeGedcR3pA5rvf8dHk0nGk6Ae8tR9fldL2/zSwBjgUYY5aC1cKGy+OuTmWnpLDOMotKe Jtwxz5lQzjhAUx2hJFwOBCZysYLZKY7vBCxOgFNCQkbnlZq1D642u4uGbPuAtYDM8FPs Ag== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2fda91mbvb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 15:51:00 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0CFjTLk026672; Fri, 12 Jan 2018 10:51:00 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2fd6pcrgt9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 12 Jan 2018 10:50:59 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 12 Jan 2018 10:50:57 -0500 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, 12 Jan 2018 10:50:57 -0500 From: "Lubashev, Igor" To: Ian Swett CC: "quic@ietf.org" , "huitema@huitema.net" Subject: RE: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizIxs65b7ysujkqedmh6APARjaNvVjxAgABe4YCAACejgIAAu4AA//+wgmqAAFmpAP//vvdQ Date: Fri, 12 Jan 2018 15:50:56 +0000 Message-ID: <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <69f4ff2b505d4574b369ed872df9b1be@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.139] Content-Type: multipart/alternative; boundary="_000_808c94738a52489d913279b1e6db100fusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801120216 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 15:51:14 -0000 --_000_808c94738a52489d913279b1e6db100fusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHBvaW50IGhlcmUgaXMgdGhhdCBpZiAxMjgtYml0IGlzIGFuIG9wdGlvbiBmcm9tIFYxLCB0 aGVuIGFsbCBjbGllbnRzIHdpbGwgc3VwcG9ydCBpdCwgYW5kIHRoZSBzZXJ2ZXIgY2FuIGNob29z ZSB0byBhbHdheXMgdXNlIDEyOC1iaXQgY29ubmVjdGlvbiBJRHMuICBUaGUgbG9hZCBiYWxhbmNl ciB0aGVuIGNhbiBiZSBzdXJlIHRoYXQgdmFsaWQgY29ubmVjdGlvbiBJRHMgKGluIHBhY2tldHMg ZmVhdHVyaW5nIHNlcnZlciBjb25uZWN0aW9uIElEKSBjYW4gb25seSBiZSAxMjgtYml0LiAgSWYg VjEgZG9lcyBub3QgaGF2ZSAxMjgtYml0IHN1cHBvcnQsIHRoZW4gdGhlIHNlcnZlciBtdXN0IGRl dmVsb3AgYSBsZXNzIHNlY3VyZSB2ZXJzaW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIHRvIGZpdCBp bnRvIDY0IGJpdHMsIGFuZCB0aGUgbG9hZCBiYWxhbmNlciBtdXN0IHRyZWF0IDY0LWJpdCBjb25u ZWN0aW9uIElEcyBhcyBhY2NlcHRhYmxlLiAgVGhlbiwgdGhlcmUgaXMgbm90aGluZyB0byBwcmV2 ZW50IGFuIGF0dGFja2VyIGZyb20gdXNpbmcgNjQtYml0IGNvbm5lY3Rpb24gSURzLCBpZiB0aGF0 4oCZcyBtb3JlIGNvbnZlbmllbnQgZm9yIHRoZW0uDQoNCkZyb206IElhbiBTd2V0dCBbbWFpbHRv OmlhbnN3ZXR0QGdvb2dsZS5jb21dDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTIsIDIwMTggOToz NSBBTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IHF1aWNA aWV0Zi5vcmc7IGh1aXRlbWFAaHVpdGVtYS5uZXQNClN1YmplY3Q6IFJlOiBJbmNyZWFzaW5nIFFV SUMgY29ubmVjdGlvbiBJRCBzaXplDQoNCkkgdGhpbmsgd2UnbGwgd2FudCBzdXBwb3J0IGZvciBi b3RoIG5vIG1hdHRlciBob3cgd2UgZG8gdGhpcy4NCg0KT24gRnJpLCBKYW4gMTIsIDIwMTggYXQg OToxMyBBTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20+PiB3cm90ZToNCklmIHRoZSAxMjgtYml0IG9wdGlvbiBpcyBub3QgaW4g VjEsIHRoZW4gaXQgd2lsbCBiZSByZXF1aXJlZCBmb3IgdGhlIDEyOC1iaXQgb3B0aW9uIHRvIGJl IHNpZ25hbGVkIGluIHRoZSBwYWNrZXQncyBpbnZhcmlhbnQgc2VjdGlvbiAobGlrZSBhIGJpdCBp biB0aGUgMXN0IGJ5dGUpLiBPdGhlcndpc2UsIHRoZSB2ZXJ5IGxvYWQgYmFsYW5jZXJzIHRoaXMg aXMgZGVzaWduZWQgZm9yIHdpbGwgbm90IGtub3cgd2hldGhlciB0aGUgY29ubmVjdGlvbiBJRCBo YXMgNjQtIG9yIDEyOC1iaXQgZm9ybWF0LiAoSXQgd291bGQgbmVlZCB0byBzdXBwb3J0IGJvdGgs IHNpbmNlIHRoZXJlIHdvdWxkIGJlIGNsaWVudHMgc3R1Y2sgYXQgVjEuKQ0KDQpJbiBmYWN0LCB0 aGUgc2VjdXJpdHkgcHJvbWlzZXMgb2YgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElEIG9w dGlvbiAoYWxsb3dzIGZvciBtYWtpbmcgcm91dGluZyBpbmZvIGhhcmRlciB0byBmb3JnZSkgYXJl IGdyZWF0bHkgZGltaW5pc2hlZCwgd2hlbiBhIGxvYWQgYmFsYW5jZXIgaGFzIHRvIHN1cHBvcnQg NjQtYml0IGNvbm5lY3Rpb24gSURzICJmb3JldmVyIi4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogSWFuIFN3ZXR0IFtpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5z d2V0dEBnb29nbGUuY29tPl0NClJlY2VpdmVkOiBGcmlkYXksIDEyIEphbiAyMDE4LCA4OjU5QU0N ClRvOiBDaHJpc3RpYW4gSHVpdGVtYSBbaHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVt YUBodWl0ZW1hLm5ldD5dDQpDQzogSUVURiBRVUlDIFdHIFtxdWljQGlldGYub3JnPG1haWx0bzpx dWljQGlldGYub3JnPl0NClN1YmplY3Q6IFJlOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJ RCBzaXplDQpJIHdvdWxkIGxpa2UgdG8gbGVhdmUgUVVJQyBvcGVuIGZvciBsb25nZXIgY29ubmVj dGlvbiBJRHMgaW4gZnV0dXJlIHZlcnNpb25zLCBzbyBJJ2QgbGlrZSB0byBzcGVjaWZ5IHRoZSBp bnZhcmlhbnRzIGluIHN1Y2ggYSB3YXkgdGhhdCBsb25nZXIgY29ubmVjdGlvbiBJZHMgd291bGRu J3QgdmlvbGF0ZSB0aGVtKGllOiBWaWN0b3IncyBzdWdnZXN0aW9uIG9mIOKAnG1pZGRsZWJveGVz IGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRv IGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLikgYnV0IEknbSByZWx1Y3RhbnQgdG8gaW5jbHVk ZSAxMjggYml0IGNvbm5lY3Rpb24gSURzIGluIHYxIGF0IHRoaXMgcG9pbnQuDQoNCkkgd291bGQg YWxzbyBlY2hvIENocmlzdGlhbidzIHNlbnRpbWVudCB0aGF0IHRoZSBpbmNyZW1lbnRhbCBvdmVy aGVhZCBzdGFydHMgYmVjb21pbmcgZmFpcmx5IGxhcmdlLg0KDQpPbiBUaHUsIEphbiAxMSwgMjAx OCBhdCA5OjQ3IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KV2UgaGF2ZSBhIHByb3RvdHlwZSBpbXBs ZW1lbnRhdGlvbiBpbiBQaWNvcXVpYyBpbiB3aGljaCB0aGUgY29ubmVjdGlvbiBJRCBjYW4gYmUg c3BsaXQgc28gc29tZSBiaXRzIGFyZSByYW5kb20gYW5kIHNvbWUgYml0cyBhcmUgdXNlZCBmb3Ig cm91dGluZyB0byBhIHNwZWNpZmljIHNlcnZlciAtLSB0aGFua3MgSWdvciBmb3IgdGhhdC4gSXQg bWFrZXMgZm9yIG5pY2UgZXhwZXJpbWVudHMsIGJ1dCBpdCBpcyBhIGRlbmlhbCBvZiBzZXJ2aWNl IHdhaXRpbmcgdG8gaGFwcGVuLiBGb3IgZXhhbXBsZSwgYXR0YWNrZXJzIGNvdWxkIHNldCB0aGUg Yml0cyBpbiBzdWNoIGEgd2F5IGFzIHRvIHRhcmdldCBhIHNwZWNpZmljIHNlcnZlciBpbiBhIHBv b2wsIG9yIHRoZXkgY291bGQgbGVhcm4gd2hpY2ggY29ubmVjdGlvbnMgYXJlIG9uIHRoZSBzYW1l IHNlcnZlciBhbmQgdXNlIHRoYXQgbGF0ZXIgZm9yIHNvbWUga2luZCBvZiBzYW1lIHNlcnZlciBh dHRhY2suIEl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGF0IGluZm9ybWF0aW9uIHdhcyBub3QgaW4g Y2xlYXIgdGV4dC4gSW4gZmFjdCwgdGhlIHBpY29xdWljIGltcGxlbWVudGF0aW9uIHVzZSBhIGNh bGxiYWNrIHRvIGFzayBmb3IgdGhlIG5ldyB2YWx1ZSAtLSBwcmVzdW1hYmx5IGZyb20gdGhlIHJv dXRlci4gVGhhdCBjYWxsYmFjayBjb3VsZCByZXR1cm4gYW55dGhpbmcsIGluY2x1ZGluZyBhbiBl bmNyeXB0ZWQgdmFsdWUuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpdCBpcyBub3QgY2xlYXIgdG8g bWUgdGhhdCB3ZSBuZWVkIGZ1bGwgZW5jcnlwdGlvbi4gRm9yIGV4YW1wbGUsIGFzc3VtZSB0aGF0 IHRoZSBzZXJ2ZXIgdGhhdCBuZWVkcyBhIGNvbm5lY3Rpb24gSUQgY2FuIGFzayBpdCBmcm9tIHRo ZSByb3V0ZXIuIFRoZSByb3V0ZXIgY291bGQgcGljayBvbmUgYXQgcmFuZG9tLCBtYWtlIHN1cmUg dGhhdCBpdCBpcyBwcm9wZXJseSBkb2N1bWVudGVkIGluIHRoZSByb3V0aW5nIHRhYmxlcyBhbmQg dGhhdCB0aGVyZSBpcyBubyBjb2xsaXNpb24sIGFuZCB0aGVuIHBhc3MgaXQgYmFjayB0byB0aGUg c2VydmVyLiBObyBlbmNyeXB0aW9uIG5lZWRlZCwgYnV0IG9mIGNvdXJzZSBsb3RzIG9mIHN0YXRl Lg0KDQpJZiB0aGUgcm91dGVyIGRvZXMgbm90IHdhbnQgdG8ga2VlcCB0aGUgc3RhdGUsIGl0IGNh biBpbmRlZWQgY3JlYXRlIGEgY29ubmVjdGlvbiBJRCBieSBlbmNyeXB0aW5nIGEgPG5vbmNlLCBz ZXJ2ZXItSUQ+IHR1cGxlLiBCdXQgaXQgZG9lcyBub3QgZm9sbG93IHRoYXQgdGhlIGVuY3J5cHRp b24gbmVlZHMgdG8gYmUgMTI4IGJpdHMuIEZvciBleGFtcGxlLCBpdCBjb3VsZCB1c2UgYSA2NCBi aXQgYWxnb3JpdGhtIGxpa2UgQmxvd2Zpc2guDQoNClNvIEkgYW0gbm90IHN1cmUgdGhhdCB3ZSBh Y3R1YWxseSBuZWVkIHRvIGNoYW5nZSB0aGUgbGVuZ3RoLiBBbmQgSSBhbSBhIGJpdCBjb25jZXJu ZWQgYnkgdGhlIGluY3JlbWVudGFsIG92ZXJoZWFkIGlmIHRoZSBjb25uZWN0aW9uIElEIHN1ZGRl bmx5IGJlY29tZXMgdmVyeSBsYXJnZS4NCg0KDQpPbiAxLzExLzIwMTggMjoyNSBQTSwgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiB3cm90ZToNCkFjdHVhbGx5LCBvbiBlbmNyeXB0aW9uIG9mIGNv bm5lY3Rpb24gSUQsIHRoaXMgaXMgbm90IHNvIHNpbXBsZS4NCg0KV2UgbXVzdCBhc3N1bWUgdGhl cmUgaXMgb25seSBhIHNpbmdsZSBrZXkgZm9yIG1hbnkgY29ubmVjdGlvbnMgYmVjYXVzZSB0aGUg cm91dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5IGV4Y2hhbmdlLiBUaGlzIHVuaXF1ZSB2YWx1ZSBv ciBjb3VudGVyIHVzZWQgZm9yIGVuY3J5cHRpbmcgYSBzaW5nbGUgYmxvY2sgY2Fubm90IGJlIHRo ZSBzYW1lIGZvciB0d28gZGlmZmVyZW50IGNvbm5lY3Rpb25zIElE4oCZcywgYnV0IGl0IGNhbiBi ZSBwdWJsaWMuIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJlIHN0b3JlZCBpbiB0aGUgcGFja2V0 IGhlYWRlci4gQW5kLCBhcyBpdCB0dXJucyBvdXQsIHJhbmRvbSBjb25uZWN0aW9uIElEIGNob3Nl biBieSBhIHRydXN0ZWQgc291cmNlLCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBhIHVuaXF1ZSB2YWx1 ZS4gQnV0IHRoZW4gaXQgbXVzdCBiZSB1c2VkIHRvIGVuY3J5cHQgYW5kL29yIGF1dGhlbnRpY2F0 ZSBzb21ldGhpbmcgZWxzZSBjYXJyeWluZyB0aGUgYWN0dWFsIHJvdXRpbmcgaW5mb3JtYXRpb24u IFNvIG5vdyB5b3Ugc3RhcnQgdG8gcmVhbGx5IG5lZWQgc29tZSBleHRyYSBwYXlsb2FkLg0KDQpB bHRlcm5hdGl2ZWx5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGlzIGVudGlyZWx5IHJhbmRvbSBz dWNoIGFzIGNvbnRlbnQgaGFzaGVkIHJvdXRpbmcuIFRoZW4geW91IG9ubHkgbmVlZCB0byBhdXRo ZW50aWNhdGUgdGhlIHJvdXRpbmcgZGF0YS4gWW91IGNhbiBkbyB0aGF0IHdpdGggYSBITUFDLCBh bmQgQ01BQyBjb3VsZCBwcm9iYWJseSBhbHNvIHdvcmsuIFRoZSBhZGRpdGlvbmFsIGJlbmVmaXQg aXMgdGhhdCB5b3UgY2FuIHByb2JhYmx5IGdldCBhd2F5IHdpdGggNjQtYml0cyBmb3IgYWxsIHJv dXRpbmcgaW5mb3JtYXRpb24gcG9zc2libHkgaW5jbHVkaW5nIHRoZSBhdXRoIHRhZy4gU2F5IDQ4 IGJpdHMgb2Ygcm91dGluZyBkYXRhIGFuZCAxNiBiaXRzIG9mIGF1dGggdGFnLg0KDQpLaW5kIFJl Z2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gMTIgSmFudWFyeSAyMDE4 IGF0IDAwLjU3LjIxLCBMdWJhc2hldiwgSWdvciAoaWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbT4pIHdyb3RlOg0KSSBhbSBpbnRlcmVzdGVkIGluIGV4cGxvcmlu ZyB0aGlzIHByb3Bvc2FsLCBzaW5jZSBpdCBhbGxvd3MgZm9yIG1vcmUgZmxleGlibGUgc2NoZW1l cyBvZiBlbmNvZGluZyByb3V0aW5nIG1ldGFkYXRhIGFuZCBhIGNoZWNrc3VtLiAgSSB3b3VsZCBh bHNvIGxpa2UgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBpbiBh IHBhY2tldCBoZWFkZXIsIHRob3VnaCwgc2luY2UgaXQgZ3JlYXRseSBzaW1wbGlmaWVzIHRoZSBp bXBsZW1lbnRhdGlvbi4NCg0KDQogICogICBJZ29yDQpGcm9tOiBWaWN0b3IgVmFzaWxpZXYgW21h aWx0bzp2YXNpbHZ2QGdvb2dsZS5jb208bWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbT5dDQpTZW50 OiBUaHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNDQpUbzogSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IEluY3JlYXNpbmcg UVVJQyBjb25uZWN0aW9uIElEIHNpemUNCg0KSGkgZXZlcnlvbmUsDQoNCkluIHRoZSBjdXJyZW50 IHZlcnNpb24gb2YgUVVJQywgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBpcyBmaXhlZCB0byBiZSBh IDY0LWJpdCBvcGFxdWUgYmxvYiwgYW5kIHRoYXQgaXMgc2V0IGFzIGFuIGludmFyaWFudCBpbiB0 aGUgcHJvdG9jb2wuDQoNCknigJl2ZSBsb29rZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2luZyBh IGNvbm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBpbnRv IGl0ICh0byBwcm92aWRlIHN0YWJpbGl0eSBvZiB0aGUgY29ubmVjdGlvbiBpbiBjYXNlIG9mIGxv YWQgYmFsYW5jaW5nIGNoYW5nZXMsIGVzcGVjaWFsbHkgQkdQIGZsYXBzIGZvciBhbnljYXN0IElQ cyksIGFuZCBoYXZlIGNoYXR0ZWQgYWJvdXQgdGhpcyB3aXRoIG90aGVyIHBlb3BsZSBJIGtuZXcg d2VyZSBpbnRlcmVzdGVkIGluIHRoaXMuICBJdCBzZWVtcyBsaWtlIDY0IGJpdHMgbWlnaHQgYmUg dG9vIHNtYWxsIGZvciB0aGlzIHB1cnBvc2UsIGFuZCB3ZSBtaWdodCB3YW50IHRvIGxlYXZlIGFu IG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBzaXplLg0KDQpUaGUgYmFz aWMgaWRlYSBpcyB0aGF0IHlvdSB3YW50IHRvIGJlIGFibGUgdG86DQoNCiAgMS4gIFN0b3JlIHNv bWUgcm91dGluZyBtZXRhZGF0YSBpbiB0aGUgY29ubmVjdGlvbiBJRC4NCiAgMi4gIEhhdmUgc29t ZSBlbnRyb3B5IHRoYXQgYWxsb3dzIGRpc3Rpbmd1aXNoIHVzZXJzIHdpdGggaWRlbnRpY2FsIHJv dXRpbmcgbWV0YWRhdGEuDQogIDMuICBIYXZlIGEgY2hlY2tzdW0gdG8gZW5zdXJlIHRoZSB2YWxp ZGl0eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uDQogIDQuICBFbmNyeXB0IHRoZSBpbmZvcm1hdGlv biBhYm92ZSB0byBwcmV2ZW50IGRpc2Nsb3NpbmcgdGhlIHJvdXRlIGluZm9ybWF0aW9uIGFuZCBh bGxvdyBnZW5lcmF0aW5nIHVuY29ycmVsYXRhYmxlIGNvbm5lY3Rpb24gSURzLg0KVGhlcmUgYXJl IHR3byB1bmRlcmx5aW5nIGlzc3VlcyBoZXJlLiAgVGhlIGZpcnN0IHByb2JsZW0gaXMgdGhhdCBh bGwgb2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJpdHMsIGFuZCB5b3UgaGF2ZSB0 byBzZXJpb3VzbHkgY29tcHJvbWlzZSBvbiB0aGUgc3RyZW5ndGggb2YgdGhlIGNoZWNrc3VtICh3 aGljaCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ugd2FudCBpdCB0byBiZSBhIE1BQyByYXRoZXIg dGhhbiBhIGNoZWNrc3VtKS4gIFRoZSBzZWNvbmQgcHJvYmxlbSBpcyB0aGF0IGVuY3J5cHRpbmcg NjQtYml0IHZhbHVlcyBmYXN0IGlzIGFjdHVhbGx5IGZhaXJseSBoYXJkIHNpbmNlIHRoZSBibG9j ayBjaXBoZXJzIGVhc2lseSBhdmFpbGFibGUgaW4gaGFyZHdhcmUgaGF2ZSAxMjgtYml0IGJsb2Nr IHNpemUsIGFuZCB0aGUgcGVyZm9ybWFuY2UgcmVxdWlyZW1lbnRzIG9uIGxvYWQgYmFsYW5jZXJz IGFyZSB0aWdodGVyIHRoYW4gb24gc2VydmVycy4NCg0KSW4gb3RoZXIgd29yZHMsIGhhdmluZyBh IDEyOC1iaXQgY29ubmVjdGlvbiBJRCBwcm92aWRlcyBmb3IgYW4gZWFzeSBzZWN1cmUgd2F5IHRv IGdlbmVyYXRlIHVubGlua2FibGUgY29ubmVjdGlvbiBJRHMgb24gbWlncmF0aW9uLg0KDQpTbywg dGhlIHByb2JsZW0gd2XigJlyZSB0cnlpbmcgdG8gc29sdmUgaXMgdGhhdCB0aGUgY29ubmVjdGlv biBJRCBpcyB0b28gc21hbGwuICBUaGVyZSBhcmUgdHdvIHF1ZXN0aW9ucyBJIGJlbGlldmUgdGhl IHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFuc3dlciBhdCB0aGlzIHBvaW50Og0KDQogIDEuICBEbyB3 ZSB3YW50IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtIGF0IHRoaXMgcG9pbnQgaW4gc3RhbmRhcmRp emF0aW9uIHByb2Nlc3M/DQogIDIuICBJZiB3ZSBkb27igJl0IGFkZHJlc3MgdGhpcyBwcm9ibGVt IHJpZ2h0IG5vdywgaG93IGRvIHdlIHN0cnVjdHVyZSB0aGUgc3RhbmRhcmQgaW4gYSB3YXkgdGhh dCB3ZSBjYW4gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIGluIHRoZSBmdXR1cmU/DQpUaGVyZSBh cmUgbXVsdGlwbGUgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBvZiBtYWtpbmcgY29ubmVjdGlv biBJRCBsYXJnZXIuICBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEgYml0IHRvIHRoZSDigJxvbWl0 IGNvbm5lY3Rpb24gSUTigJ0gZmllbGQgdG8gYWxsb3cgMTI4LWJpdCBjb25uZWN0aW9uIElEcy4g IEFub3RoZXIgYXBwcm9hY2ggaXMgdG8gYWxsb3cgY29ubmVjdGlvbiBJRCBzaXplIHRvIGJlIGV4 cGxpY2l0bHkgc3BlY2lmaWVkIGJ5IHRoZSBzZXJ2ZXIsIGFuZCB0aGVuIGFzc3VtZSB0aGF0IHRo ZSBsb2FkIGJhbGFuY2VyIGtub3dzIHRoYXQgc2l6ZSBhbmQgbm8gb25lIGVsc2Ugb24gdGhlIHBh dGggbmVlZHMgdG8gcmVhZCBpdC4NCg0KVGhlcmXigJlzIGFsc28gYSBxdWVzdGlvbiBvZiBob3cg bXVjaCBvZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVib3hlcyAoZXhjbHVkaW5nIGxvYWQgYmFs YW5jZXJzIGFuZCBvdGhlciBib3hlcyBvd25lZCBieSB0aGUgc2FtZSBlbnRpdHkgYXMgZWl0aGVy IGNsaWVudCBvciBzZXJ2ZXIpIG5lZWQgdG8ga25vdy4gIFdlIGNvdWxkIGdvIGZvciBib3RoIOKA nG1pZGRsZWJveGVzIHNob3VsZCBiZSBhbHdheXMgYWJsZSB0byByZWFkIHRoZSBlbnRpcmUgSUTi gJ0gYW5kIOKAnG1pZGRsZWJveGVzIHNob3VsZCBub3QgcmVhZCBjb25uZWN0aW9uIElEcyBhdCBh bGwgb3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGFsc28gYSByb29tIGZvciBtb3Jl IGZsZXhpYmxlIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1pZGRsZWJveGVzIGFsd2F5cyBnZXQgZmly c3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRvIGRpc3Rpbmd1aXNoIGNv bm5lY3Rpb25z4oCdLg0KDQogIC0tIFZpY3Rvci4NCg0KDQoNCg== --_000_808c94738a52489d913279b1e6db100fusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTIzMTk1 ODAwOTg1NjY5ODQ1NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFpcm1haWxvbiwgbGkubTIzMTk1ODAw OTg1NjY5ODQ1NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFpcm1haWxvbiwgZGl2Lm0yMzE5NTgwMDk4 NTY2OTg0NTQ0bTQ0NTIyMTQ2MDE1Njc1MTEyMjRhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6 bV8yMzE5NTgwMDk4NTY2OTg0NTQ0bV80NDUyMjE0NjAxNTY3NTExMjI0YWlybWFpbF9vbjsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUw NDMyMjI2ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQxMDY1MjMzNjt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxDQoJe21zby1saXN0LWlkOjE3NjA3NTU5NDI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjkzNjk0ODgwNjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxOTg0ODQ0NjEwOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTU5NTE0MDk5MDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHBvaW50IGhlcmUgaXMgdGhhdCBpZiAxMjgtYml0 IGlzIGFuIG9wdGlvbiBmcm9tIFYxLCB0aGVuIGFsbCBjbGllbnRzIHdpbGwgc3VwcG9ydCBpdCwg YW5kIHRoZSBzZXJ2ZXIgY2FuIGNob29zZSB0byBhbHdheXMgdXNlIDEyOC1iaXQgY29ubmVjdGlv biBJRHMuJm5ic3A7IFRoZSBsb2FkIGJhbGFuY2VyIHRoZW4gY2FuIGJlIHN1cmUgdGhhdCB2YWxp ZCBjb25uZWN0aW9uIElEcyAoaW4gcGFja2V0cyBmZWF0dXJpbmcNCiBzZXJ2ZXIgY29ubmVjdGlv biBJRCkgY2FuIG9ubHkgYmUgMTI4LWJpdC4mbmJzcDsgSWYgVjEgZG9lcyBub3QgaGF2ZSAxMjgt Yml0IHN1cHBvcnQsIHRoZW4gdGhlIHNlcnZlciBtdXN0IGRldmVsb3AgYSBsZXNzIHNlY3VyZSB2 ZXJzaW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIHRvIGZpdCBpbnRvIDY0IGJpdHMsIGFuZCB0aGUg bG9hZCBiYWxhbmNlciBtdXN0IHRyZWF0IDY0LWJpdCBjb25uZWN0aW9uIElEcyBhcyBhY2NlcHRh YmxlLiZuYnNwOyBUaGVuLCB0aGVyZQ0KIGlzIG5vdGhpbmcgdG8gcHJldmVudCBhbiBhdHRhY2tl ciBmcm9tIHVzaW5nIDY0LWJpdCBjb25uZWN0aW9uIElEcywgaWYgdGhhdOKAmXMgbW9yZSBjb252 ZW5pZW50IGZvciB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSWFu IFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgSmFudWFyeSAxMiwgMjAxOCA5OjM1IEFNPGJyPg0KPGI+VG86PC9iPiBMdWJhc2hldiwg SWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0 Zi5vcmc7IGh1aXRlbWFAaHVpdGVtYS5uZXQ8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEluY3Jl YXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgd2UnbGwgd2FudCBzdXBwb3J0IGZvciBib3RoIG5vIG1hdHRlciBob3cgd2Ug ZG8gdGhpcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgSmFuIDEyLCAyMDE4IGF0IDk6MTMgQU0sIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVm PSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFr YW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JZiB0aGUg MTI4LWJpdCBvcHRpb24gaXMgbm90IGluIFYxLCB0aGVuIGl0IHdpbGwgYmUgcmVxdWlyZWQgZm9y IHRoZSAxMjgtYml0IG9wdGlvbiB0byBiZSBzaWduYWxlZCBpbiB0aGUgcGFja2V0J3MgaW52YXJp YW50IHNlY3Rpb24gKGxpa2UgYSBiaXQgaW4gdGhlIDFzdCBieXRlKS4gT3RoZXJ3aXNlLCB0aGUg dmVyeSBsb2FkIGJhbGFuY2VycyB0aGlzIGlzIGRlc2lnbmVkDQogZm9yIHdpbGwgbm90IGtub3cg d2hldGhlciB0aGUgY29ubmVjdGlvbiBJRCBoYXMgNjQtIG9yIDEyOC1iaXQgZm9ybWF0LiAoSXQg d291bGQgbmVlZCB0byBzdXBwb3J0IGJvdGgsIHNpbmNlIHRoZXJlIHdvdWxkIGJlIGNsaWVudHMg c3R1Y2sgYXQgVjEuKTxicj4NCjxicj4NCkluIGZhY3QsIHRoZSBzZWN1cml0eSBwcm9taXNlcyBv ZiBoYXZpbmcgYSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgb3B0aW9uIChhbGxvd3MgZm9yIG1ha2lu ZyByb3V0aW5nIGluZm8gaGFyZGVyIHRvIGZvcmdlKSBhcmUgZ3JlYXRseSBkaW1pbmlzaGVkLCB3 aGVuIGEgbG9hZCBiYWxhbmNlciBoYXMgdG8gc3VwcG9ydCA2NC1iaXQgY29ubmVjdGlvbiBJRHMg JnF1b3Q7Zm9yZXZlciZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LSA8YnI+DQo8Yj5Gcm9tOjwvYj4gSWFuIFN3ZXR0IFs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+XTxicj4N CjxiPlJlY2VpdmVkOjwvYj4gRnJpZGF5LCAxMiBKYW4gMjAxOCwgODo1OUFNPGJyPg0KPGI+VG86 PC9iPiBDaHJpc3RpYW4gSHVpdGVtYSBbPGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5u ZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPl08YnI+DQo8Yj5DQzo8 L2I+IElFVEYgUVVJQyBXRyBbPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5xdWljQGlldGYub3JnPC9hPl08YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEluY3Jl YXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgd291bGQgbGlrZSB0byBsZWF2ZSBRVUlDIG9wZW4gZm9yIGxvbmdlciBjb25uZWN0aW9u IElEcyBpbiBmdXR1cmUgdmVyc2lvbnMsIHNvIEknZCBsaWtlIHRvIHNwZWNpZnkgdGhlIGludmFy aWFudHMgaW4gc3VjaCBhIHdheSB0aGF0IGxvbmdlciBjb25uZWN0aW9uIElkcyB3b3VsZG4ndCB2 aW9sYXRlIHRoZW0oaWU6IFZpY3RvcidzIHN1Z2dlc3Rpb24gb2YmbmJzcDvigJxtaWRkbGVib3hl cyBhbHdheXMgZ2V0IGZpcnN0DQogNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5 IHRvIGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLikgYnV0IEknbSByZWx1Y3RhbnQgdG8gaW5j bHVkZSAxMjggYml0IGNvbm5lY3Rpb24gSURzIGluIHYxIGF0IHRoaXMgcG9pbnQuDQo8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIHdvdWxkIGFsc28g ZWNobyBDaHJpc3RpYW4ncyBzZW50aW1lbnQgdGhhdCB0aGUgaW5jcmVtZW50YWwgb3ZlcmhlYWQg c3RhcnRzIGJlY29taW5nIGZhaXJseSBsYXJnZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMTEsIDIwMTggYXQgOTo0NyBQ TSwgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEu bmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBoYXZlIGEgcHJvdG90eXBlIGltcGxlbWVudGF0aW9uIGluIFBpY29xdWljIGluIHdoaWNoIHRo ZSBjb25uZWN0aW9uIElEIGNhbiBiZSBzcGxpdCBzbyBzb21lIGJpdHMgYXJlIHJhbmRvbSBhbmQg c29tZSBiaXRzIGFyZSB1c2VkIGZvciByb3V0aW5nIHRvIGEgc3BlY2lmaWMgc2VydmVyIC0tIHRo YW5rcyBJZ29yIGZvciB0aGF0LiBJdCBtYWtlcyBmb3IgbmljZSBleHBlcmltZW50cywgYnV0IGl0 IGlzIGEgZGVuaWFsDQogb2Ygc2VydmljZSB3YWl0aW5nIHRvIGhhcHBlbi4gRm9yIGV4YW1wbGUs IGF0dGFja2VycyBjb3VsZCBzZXQgdGhlIGJpdHMgaW4gc3VjaCBhIHdheSBhcyB0byB0YXJnZXQg YSBzcGVjaWZpYyBzZXJ2ZXIgaW4gYSBwb29sLCBvciB0aGV5IGNvdWxkIGxlYXJuIHdoaWNoIGNv bm5lY3Rpb25zIGFyZSBvbiB0aGUgc2FtZSBzZXJ2ZXIgYW5kIHVzZSB0aGF0IGxhdGVyIGZvciBz b21lIGtpbmQgb2Ygc2FtZSBzZXJ2ZXIgYXR0YWNrLiBJdCB3b3VsZCBiZQ0KIGJldHRlciBpZiB0 aGF0IGluZm9ybWF0aW9uIHdhcyBub3QgaW4gY2xlYXIgdGV4dC4gSW4gZmFjdCwgdGhlIHBpY29x dWljIGltcGxlbWVudGF0aW9uIHVzZSBhIGNhbGxiYWNrIHRvIGFzayBmb3IgdGhlIG5ldyB2YWx1 ZSAtLSBwcmVzdW1hYmx5IGZyb20gdGhlIHJvdXRlci4gVGhhdCBjYWxsYmFjayBjb3VsZCByZXR1 cm4gYW55dGhpbmcsIGluY2x1ZGluZyBhbiBlbmNyeXB0ZWQgdmFsdWUuPGJyPg0KPGJyPg0KT24g dGhlIG90aGVyIGhhbmQsIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgZnVsbCBl bmNyeXB0aW9uLiBGb3IgZXhhbXBsZSwgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB0aGF0IG5lZWRz IGEgY29ubmVjdGlvbiBJRCBjYW4gYXNrIGl0IGZyb20gdGhlIHJvdXRlci4gVGhlIHJvdXRlciBj b3VsZCBwaWNrIG9uZSBhdCByYW5kb20sIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIHByb3Blcmx5IGRv Y3VtZW50ZWQgaW4gdGhlIHJvdXRpbmcgdGFibGVzDQogYW5kIHRoYXQgdGhlcmUgaXMgbm8gY29s bGlzaW9uLCBhbmQgdGhlbiBwYXNzIGl0IGJhY2sgdG8gdGhlIHNlcnZlci4gTm8gZW5jcnlwdGlv biBuZWVkZWQsIGJ1dCBvZiBjb3Vyc2UgbG90cyBvZiBzdGF0ZS48YnI+DQo8YnI+DQpJZiB0aGUg cm91dGVyIGRvZXMgbm90IHdhbnQgdG8ga2VlcCB0aGUgc3RhdGUsIGl0IGNhbiBpbmRlZWQgY3Jl YXRlIGEgY29ubmVjdGlvbiBJRCBieSBlbmNyeXB0aW5nIGEgJmx0O25vbmNlLCBzZXJ2ZXItSUQm Z3Q7IHR1cGxlLiBCdXQgaXQgZG9lcyBub3QgZm9sbG93IHRoYXQgdGhlIGVuY3J5cHRpb24gbmVl ZHMgdG8gYmUgMTI4IGJpdHMuIEZvciBleGFtcGxlLCBpdCBjb3VsZCB1c2UgYSA2NCBiaXQgYWxn b3JpdGhtIGxpa2UgQmxvd2Zpc2guDQo8YnI+DQo8YnI+DQpTbyBJIGFtIG5vdCBzdXJlIHRoYXQg d2UgYWN0dWFsbHkgbmVlZCB0byBjaGFuZ2UgdGhlIGxlbmd0aC4gQW5kIEkgYW0gYSBiaXQgY29u Y2VybmVkIGJ5IHRoZSBpbmNyZW1lbnRhbCBvdmVyaGVhZCBpZiB0aGUgY29ubmVjdGlvbiBJRCBz dWRkZW5seSBiZWNvbWVzIHZlcnkgbGFyZ2UuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAx LzExLzIwMTggMjoyNSBQTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IGlkPSJtXzIzMTk1ODAwOTg1NjY5ODQ1NDRtXzQ0NTIy MTQ2MDE1Njc1MTEyMjRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5BY3R1YWxseSwgb24gZW5jcnlwdGlvbiBvZiBjb25uZWN0aW9uIElE LCB0aGlzIGlzIG5vdCBzbyBzaW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtXzIzMTk1ODAwOTg1NjY5ODQ1NDRtXzQ0NTIyMTQ2MDE1Njc1MTEyMjRibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjMxOTU4MDA5ODU2 Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUxMTIyNGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPldlIG11c3QgYXNzdW1lIHRoZXJlIGlzIG9u bHkgYSBzaW5nbGUga2V5IGZvciBtYW55IGNvbm5lY3Rpb25zIGJlY2F1c2UgdGhlIHJvdXRlciBp cyBub3QgcGFydCBvZiBhIGtleSBleGNoYW5nZS4gVGhpcyB1bmlxdWUgdmFsdWUgb3IgY291bnRl ciB1c2VkIGZvciBlbmNyeXB0aW5nIGEgc2luZ2xlDQogYmxvY2sgY2Fubm90IGJlIHRoZSBzYW1l IGZvciB0d28gZGlmZmVyZW50IGNvbm5lY3Rpb25zIElE4oCZcywgYnV0IGl0IGNhbiBiZSBwdWJs aWMuIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJlIHN0b3JlZCBpbiB0aGUgcGFja2V0IGhlYWRl ci4gQW5kLCBhcyBpdCB0dXJucyBvdXQsIHJhbmRvbSBjb25uZWN0aW9uIElEIGNob3NlbiBieSBh IHRydXN0ZWQgc291cmNlLCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBhIHVuaXF1ZSB2YWx1ZS4gQnV0 IHRoZW4NCiBpdCBtdXN0IGJlIHVzZWQgdG8gZW5jcnlwdCBhbmQvb3IgYXV0aGVudGljYXRlIHNv bWV0aGluZyBlbHNlIGNhcnJ5aW5nIHRoZSBhY3R1YWwgcm91dGluZyBpbmZvcm1hdGlvbi4gU28g bm93IHlvdSBzdGFydCB0byByZWFsbHkgbmVlZCBzb21lIGV4dHJhIHBheWxvYWQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIzMTk1ODAwOTg1NjY5ODQ1NDRtXzQ0 NTIyMTQ2MDE1Njc1MTEyMjRibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUxMTIyNGJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFs dGVybmF0aXZlbHkgdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMgZW50aXJlbHkgcmFuZG9tIHN1 Y2ggYXMgY29udGVudCBoYXNoZWQgcm91dGluZy4gVGhlbiB5b3Ugb25seSBuZWVkIHRvIGF1dGhl bnRpY2F0ZSB0aGUgcm91dGluZyBkYXRhLiBZb3UgY2FuIGRvIHRoYXQgd2l0aCBhIEhNQUMsDQog YW5kIENNQUMgY291bGQgcHJvYmFibHkgYWxzbyB3b3JrLiBUaGUgYWRkaXRpb25hbCBiZW5lZml0 IGlzIHRoYXQgeW91IGNhbiBwcm9iYWJseSBnZXQgYXdheSB3aXRoIDY0LWJpdHMgZm9yIGFsbCBy b3V0aW5nIGluZm9ybWF0aW9uIHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgYXV0aCB0YWcuIFNheSA0 OCBiaXRzIG9mIHJvdXRpbmcgZGF0YSBhbmQgMTYgYml0cyBvZiBhdXRoIHRhZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdiBpZD0ibV8yMzE5NTgwMDk4NTY2OTg0NTQ0bV80NDUyMjE0NjAxNTY3NTEx MjI0Ymxvb3Bfc2lnbl8xNTE1NzE2MTM3MjAzMzMzODg4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0ibTIzMTk1ODAwOTg1NjY5ODQ1 NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFpcm1haWxvbiI+T24gMTIgSmFudWFyeSAyMDE4IGF0IDAw LjU3LjIxLCBMdWJhc2hldiwgSWdvciAoPGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20iIHRhcmdldD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPikgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SSBhbSBpbnRlcmVzdGVkIGluIGV4cGxvcmluZyB0aGlzIHByb3Bvc2FsLCBzaW5jZSBpdCBhbGxv d3MgZm9yIG1vcmUgZmxleGlibGUgc2NoZW1lcyBvZiBlbmNvZGluZyByb3V0aW5nIG1ldGFkYXRh IGFuZCBhIGNoZWNrc3VtLiZuYnNwOyBJIHdvdWxkIGFsc28gbGlrZSB0byBiZSBleHBsaWNpdCBh Ym91dCB0aGUgY29ubmVjdGlvbg0KIElEIHNpemUgaW4gYSBwYWNrZXQgaGVhZGVyLCB0aG91Z2gs IHNpbmNlIGl0IGdyZWF0bHkgc2ltcGxpZmllcyB0aGUgaW1wbGVtZW50YXRpb24uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVs IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWdvciA8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFZpY3RvciBWYXNpbGlldiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNpbHZ2 QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDEx LCAyMDE4IDY6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6 ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBldmVyeW9uZSw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgUVVJQywgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBp cyBmaXhlZCB0byBiZSBhIDY0LWJpdCBvcGFxdWUgYmxvYiwgYW5kIHRoYXQgaXMgc2V0IGFzIGFu IGludmFyaWFudCBpbiB0aGUgcHJvdG9jb2wuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J4oCZdmUgbG9va2VkIGludG8gcG9zc2liaWxp dHkgb2YgdXNpbmcgYSBjb25uZWN0aW9uIElEIHRvIGVuY29kZSB0aGUgc3BlY2lmaWMgc2VydmVy IGRldGFpbHMgaW50byBpdCAodG8gcHJvdmlkZSBzdGFiaWxpdHkgb2YgdGhlIGNvbm5lY3Rpb24g aW4gY2FzZSBvZiBsb2FkIGJhbGFuY2luZyBjaGFuZ2VzLCBlc3BlY2lhbGx5DQogQkdQIGZsYXBz IGZvciBhbnljYXN0IElQcyksIGFuZCBoYXZlIGNoYXR0ZWQgYWJvdXQgdGhpcyB3aXRoIG90aGVy IHBlb3BsZSBJIGtuZXcgd2VyZSBpbnRlcmVzdGVkIGluIHRoaXMuJm5ic3A7IEl0IHNlZW1zIGxp a2UgNjQgYml0cyBtaWdodCBiZSB0b28gc21hbGwgZm9yIHRoaXMgcHVycG9zZSwgYW5kIHdlIG1p Z2h0IHdhbnQgdG8gbGVhdmUgYW4gb3Bwb3J0dW5pdHkgdG8gZXh0ZW5kIHRoZSBjb25uZWN0aW9u IElEIHNpemUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgYmFzaWMgaWRlYSBpcyB0aGF0IHlvdSB3YW50IHRvIGJlIGFibGUgdG86 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwx IGxmbzIiPg0KU3RvcmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0aW9uIElE LiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSGF2ZSBzb21lIGVudHJvcHkgdGhhdCBhbGxvd3Mg ZGlzdGluZ3Vpc2ggdXNlcnMgd2l0aCBpZGVudGljYWwgcm91dGluZyBtZXRhZGF0YS4gPG86cD4N CjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzIiPg0KSGF2ZSBhIGNoZWNrc3VtIHRvIGVuc3VyZSB0aGUgdmFsaWRp dHkgb2Ygcm91dGluZyBpbmZvcm1hdGlvbiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzIiPg0KRW5jcnlw dCB0aGUgaW5mb3JtYXRpb24gYWJvdmUgdG8gcHJldmVudCBkaXNjbG9zaW5nIHRoZSByb3V0ZSBp bmZvcm1hdGlvbiBhbmQgYWxsb3cgZ2VuZXJhdGluZyB1bmNvcnJlbGF0YWJsZSBjb25uZWN0aW9u IElEcy4NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGVyZSBhcmUgdHdvIHVuZGVybHlpbmcgaXNzdWVzIGhlcmUuJm5ic3A7IFRo ZSBmaXJzdCBwcm9ibGVtIGlzIHRoYXQgYWxsIG9mIHRoaXMgZG9lcyBub3QgZml0IHdlbGwgaW50 byA2NCBiaXRzLCBhbmQgeW91IGhhdmUgdG8gc2VyaW91c2x5IGNvbXByb21pc2Ugb24gdGhlIHN0 cmVuZ3RoIG9mIHRoZSBjaGVja3N1bQ0KICh3aGljaCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ug d2FudCBpdCB0byBiZSBhIE1BQyByYXRoZXIgdGhhbiBhIGNoZWNrc3VtKS4mbmJzcDsgVGhlIHNl Y29uZCBwcm9ibGVtIGlzIHRoYXQgZW5jcnlwdGluZyA2NC1iaXQgdmFsdWVzIGZhc3QgaXMgYWN0 dWFsbHkgZmFpcmx5IGhhcmQgc2luY2UgdGhlIGJsb2NrIGNpcGhlcnMgZWFzaWx5IGF2YWlsYWJs ZSBpbiBoYXJkd2FyZSBoYXZlIDEyOC1iaXQgYmxvY2sgc2l6ZSwgYW5kIHRoZSBwZXJmb3JtYW5j ZQ0KIHJlcXVpcmVtZW50cyBvbiBsb2FkIGJhbGFuY2VycyBhcmUgdGlnaHRlciB0aGFuIG9uIHNl cnZlcnMuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JbiBvdGhlciB3b3JkcywgaGF2aW5nIGEgMTI4LWJpdCBjb25u ZWN0aW9uIElEIHByb3ZpZGVzIGZvciBhbiBlYXN5IHNlY3VyZSB3YXkgdG8gZ2VuZXJhdGUgdW5s aW5rYWJsZSBjb25uZWN0aW9uIElEcyBvbiBtaWdyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TbywgdGhlIHByb2JsZW0gd2Xi gJlyZSB0cnlpbmcgdG8gc29sdmUgaXMgdGhhdCB0aGUgY29ubmVjdGlvbiBJRCBpcyB0b28gc21h bGwuJm5ic3A7IFRoZXJlIGFyZSB0d28gcXVlc3Rpb25zIEkgYmVsaWV2ZSB0aGUgd29ya2luZyBn cm91cCBzaG91bGQgYW5zd2VyIGF0IHRoaXMgcG9pbnQ6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KRG8gd2Ugd2FudCB0byBh ZGRyZXNzIHRoaXMgcHJvYmxlbSBhdCB0aGlzIHBvaW50IGluIHN0YW5kYXJkaXphdGlvbiBwcm9j ZXNzPyA8bzpwPg0KPC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQpJZiB3ZSBkb27igJl0IGFkZHJlc3MgdGhp cyBwcm9ibGVtIHJpZ2h0IG5vdywgaG93IGRvIHdlIHN0cnVjdHVyZSB0aGUgc3RhbmRhcmQgaW4g YSB3YXkgdGhhdCB3ZSBjYW4gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIGluIHRoZSBmdXR1cmU/ DQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgbWFr aW5nIGNvbm5lY3Rpb24gSUQgbGFyZ2VyLiZuYnNwOyBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEg Yml0IHRvIHRoZSDigJxvbWl0IGNvbm5lY3Rpb24gSUTigJ0gZmllbGQgdG8gYWxsb3cgMTI4LWJp dCBjb25uZWN0aW9uIElEcy4mbmJzcDsgQW5vdGhlcg0KIGFwcHJvYWNoIGlzIHRvIGFsbG93IGNv bm5lY3Rpb24gSUQgc2l6ZSB0byBiZSBleHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUgc2VydmVy LCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0IHNpemUg YW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBwYXRoIG5lZWRzIHRvIHJlYWQgaXQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZeKAmXMg YWxzbyBhIHF1ZXN0aW9uIG9mIGhvdyBtdWNoIG9mIGNvbm5lY3Rpb24gSURzIGRvIG1pZGRsZWJv eGVzIChleGNsdWRpbmcgbG9hZCBiYWxhbmNlcnMgYW5kIG90aGVyIGJveGVzIG93bmVkIGJ5IHRo ZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIgY2xpZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiZu YnNwOw0KIFdlIGNvdWxkIGdvIGZvciBib3RoIOKAnG1pZGRsZWJveGVzIHNob3VsZCBiZSBhbHdh eXMgYWJsZSB0byByZWFkIHRoZSBlbnRpcmUgSUTigJ0gYW5kIOKAnG1pZGRsZWJveGVzIHNob3Vs ZCBub3QgcmVhZCBjb25uZWN0aW9uIElEcyBhdCBhbGwgb3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsg dGhlcmXigJlzIGFsc28gYSByb29tIGZvciBtb3JlIGZsZXhpYmxlIGZvcm11bGF0aW9ucyBsaWtl IOKAnG1pZGRsZWJveGVzIGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleQ0KIGhhdmUg dXNlZnVsIGVudHJvcHkgdG8gZGlzdGluZ3Vpc2ggY29ubmVjdGlvbnPigJ0uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgLS0g VmljdG9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_808c94738a52489d913279b1e6db100fusma1exdag1mb5msgcorpak_-- From nobody Fri Jan 12 08:03:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9AB41270AC for ; Fri, 12 Jan 2018 08:03:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 QsVMEjc7xN5y for ; Fri, 12 Jan 2018 08:03:45 -0800 (PST) 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 4283512420B for ; Fri, 12 Jan 2018 08:03:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zJ6xD0QcCzMnc6; Fri, 12 Jan 2018 17:03:44 +0100 (CET) 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 evlHl0OBl63R; Fri, 12 Jan 2018 17:03:43 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE26.versanet.de [87.123.206.38]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 12 Jan 2018 17:03:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Deadlocking in the transport From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 12 Jan 2018 17:03:42 +0100 Cc: Jana Iyengar , QUIC WG , Charles 'Buck' Krasic Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> 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, 12 Jan 2018 16:03:48 -0000 I disagree. I think it can be good to provide the transport hints about = dependencies in application data which then could be used by the = transport to optimize the sent-out scheduling, but I don=E2=80=99t think = the transport should provide guarantees for ordered processing between = streams. For me the whole point of having streams in the transport is to = resolve dependencies between independent data. Therefore, I think it would probably be good to mention this deadlock = problem in the main draft but I don=E2=80=99t think we should add strict = priorities as a transport feature to QUIC. There are several ways how an = application can avoid (don=E2=80=99t have dependencies by using the same = stream for dependent data or wait until data has be sent before sending = dependent data) or resolve (read all streams and implement an additional = application layer buffer) such a deadlock and these should be explained = in the applicability document respectively. My 2c, Mirja > Am 10.01.2018 um 23:42 schrieb Martin Thomson = : >=20 > On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar wrote: >> Yes, I think there's easy misinterpretation here -- something I = realized >> today as I've had conversations about this. What I meant was = specifically at >> the API between the app and the transport, at the sender. This is = basically >> saying that to avoid deadlock due to dependencies across streams, the >> transport write API must allow the app to express strict priorities. >=20 > Ahh, excellent, then I think at least we two are in agreement. It > seems like there is an emerging acceptance of the problem and proposed > approach, I guess we might start considering how to address it. >=20 > I think that this needs to be in the main spec. Failing to document > this sort of pitfall could be fatal. Does anyone disagree? >=20 From nobody Fri Jan 12 08:57:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3D12D942 for ; Fri, 12 Jan 2018 08:57:38 -0800 (PST) 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 uk2I_0Zs41ca for ; Fri, 12 Jan 2018 08:57:33 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A53712D861 for ; Fri, 12 Jan 2018 08:57:33 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id f34so1250780ioi.13 for ; Fri, 12 Jan 2018 08:57:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=2PEjS2gkNSOzDkrlKKUOCC5KEPPbMIirIc+1r/js2HM=; b=eAmKFbEgLFXJ/lpJ4u6vtC5/g0aXGbTebmc8PoanHnWFFbyaVZRYZkhP1ufocv/aZ/ c+LfYA2K8QxXlFqgyin5ZWQ2lTf16Z4xr1WAH5vKpei4MRWA1q0oAwMjNoaDovSU9SEj VSnR15b2TRwthjx5/wlWj4sK7IWagsXaLLWr5ZCFblqBVwR6XxWPtJOlLta5zN+18lys A/Mk2I5Q88sv2LDU7kRJGIKriRwDxW+Evq8awY6o5f19MqA7e/Ho0tRriQB1okNl6vIi 5yK7fLNenv12mjJquSWgjSgHEQLfzTQx+T6GyYM3foL7rnWAoxg3AP5mbK5tjhvlNPUf Ut0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=2PEjS2gkNSOzDkrlKKUOCC5KEPPbMIirIc+1r/js2HM=; b=fc2AYlWtrtoQUbGyY/hrRQFysVuDwFarwZEX2IVuvKz86SlGjX+kAH8H77Qb9GPYgA rnJwUpCiJGxyALLl2oVC5WF0hNGaoa60Te9DfIa3kchCcQa73m5WMsGPNW2+US+zFIUs VjZZ5rh3ZTs/gQmQ+PRbBLEa9thaRR/DdVrGictG5NiQ26GfwAFvtIAIt1TuZtcS2njz lKstimb+Q88Ssv33GAbpJMPjBv/9A3TBl2Ooo5G3WnMsjnFBNemI6e0GklDENA3aPuUT Z2uHD51YC42BnnYF+myDm0matHQ75mJlzKiKffW/1e7BCyuhD/pA8RoJHKrmH9CzlTdW nlSg== X-Gm-Message-State: AKGB3mKyIFxJ9fdDMWN2No5k3eoOzdlyRaDD9fZy8A/sidybZkG2cclF YkhZl3jhpljJcs3Ed+IdgXHKxyUoIt5AbXlwxDY= X-Google-Smtp-Source: ACJfBounakIkpZSNInLDrAdtrsxfwL+D5sNkbS2LgzDd/YtIoibih4FEjR5YPXbuc8Z2XlQwgBTciapMdUkavgzwlWU= X-Received: by 10.107.57.3 with SMTP id g3mr27130472ioa.297.1515776252486; Fri, 12 Jan 2018 08:57:32 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 12 Jan 2018 11:57:31 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 12 Jan 2018 11:57:31 -0500 Message-ID: Subject: RE: Increasing QUIC connection ID size To: "Lubashev, Igor" , Ian Swett Cc: "huitema@huitema.net" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114ac18016a78d05629729fb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 16:57:38 -0000 --001a114ac18016a78d05629729fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It could also be fixed 62 bit connection identifier and 2 msg of the first CID byte stores the additional length. The requirement is then that the first 62 bits must have =E2=80=9Cenough entropy=E2=80=9D and the remaining = bits are application or deployment specific. This will force routers to support 128-bits, but it will allow them to require it if so desired. A router need not be concerned with the variable length aspect if the QUIC invariant ensures that a packet length is at least long enough to read 128 bits from CID start. It can just assume the length it expects and then validate as needed with auth tag or length, or just assume it is safe under the conditions. In all cases the QUIC endpoint MUST include the CID in the additional data authentication to ensure routing data has not been tampered. One could also take this a step further and shorten the first 64 bits, but that is probably a rats nest: 16, 32, 64, 128 bits. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 16.51.19, Lubashev, Igor (ilubashe@akamai.com) wrote: The point here is that if 128-bit is an option from V1, then all clients will support it, and the server can choose to always use 128-bit connection IDs. The load balancer then can be sure that valid connection IDs (in packets featuring server connection ID) can only be 128-bit. If V1 does not have 128-bit support, then the server must develop a less secure version of the connection ID to fit into 64 bits, and the load balancer must treat 64-bit connection IDs as acceptable. Then, there is nothing to prevent an attacker from using 64-bit connection IDs, if that=E2=80=99s mor= e convenient for them. *From:* Ian Swett [mailto:ianswett@google.com] *Sent:* Friday, January 12, 2018 9:35 AM *To:* Lubashev, Igor *Cc:* quic@ietf.org; huitema@huitema.net *Subject:* Re: Increasing QUIC connection ID size I think we'll want support for both no matter how we do this. On Fri, Jan 12, 2018 at 9:13 AM, Lubashev, Igor wrote= : If the 128-bit option is not in V1, then it will be required for the 128-bit option to be signaled in the packet's invariant section (like a bit in the 1st byte). Otherwise, the very load balancers this is designed for will not know whether the connection ID has 64- or 128-bit format. (It would need to support both, since there would be clients stuck at V1.) In fact, the security promises of having a 128-bit connection ID option (allows for making routing info harder to forge) are greatly diminished, when a load balancer has to support 64-bit connection IDs "forever". -----Original Message----- *From:* Ian Swett [ianswett@google.com] *Received:* Friday, 12 Jan 2018, 8:59AM *To:* Christian Huitema [huitema@huitema.net] *CC:* IETF QUIC WG [quic@ietf.org] *Subject:* Re: Increasing QUIC connection ID size I would like to leave QUIC open for longer connection IDs in future versions, so I'd like to specify the invariants in such a way that longer connection Ids wouldn't violate them(ie: Victor's suggestion of =E2=80=9Cmiddleboxes always get first 64 bits and they have useful entro= py to distinguish connections=E2=80=9D.) but I'm reluctant to include 128 bit con= nection IDs in v1 at this point. I would also echo Christian's sentiment that the incremental overhead starts becoming fairly large. On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema wrote: We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value. On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state. If the router does not want to keep the state, it can indeed create a connection ID by encrypting a tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish. So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large. On 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: Actually, on encryption of connection ID, this is not so simple. We must assume there is only a single key for many connections because the router is not part of a key exchange. This unique value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but it can be public. This means that it must be stored in th= e packet header. And, as it turns out, random connection ID chosen by a trusted source, can be used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the actual routing information. So now you start to really need some extra payload. Alternatively the routing information is entirely random such as content hashed routing. Then you only need to authenticate the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can probably get away with 64-bits for all routing information possibly including the auth tag. Say 48 bits of routing data and 16 bits of auth tag. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 January 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote: I am interested in exploring this proposal, since it allows for more flexible schemes of encoding routing metadata and a checksum. I would also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implementation. - Igor *From:* Victor Vasiliev [mailto:vasilvv@google.com] *Sent:* Thursday, January 11, 2018 6:16 PM *To:* IETF QUIC WG *Subject:* Increasing QUIC connection ID size Hi everyone, In the current version of QUIC, the connection ID size is fixed to be a 64-bit opaque blob, and that is set as an invariant in the protocol. I=E2=80=99ve looked into possibility of using a connection ID to encode the specific server details into it (to provide stability of the connection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people I knew were interested in this. It seems like 64 bits might be too small for this purpose, and we might want to leave an opportunity to extend the connection ID size. The basic idea is that you want to be able to: 1. Store some routing metadata in the connection ID. 2. Have some entropy that allows distinguish users with identical routing metadata. 3. Have a checksum to ensure the validity of routing information 4. Encrypt the information above to prevent disclosing the route information and allow generating uncorrelatable connection IDs. There are two underlying issues here. The first problem is that all of this does not fit well into 64 bits, and you have to seriously compromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum). The second problem is that encrypting 64-bit values fast is actually fairly hard since the block ciphers easily available in hardware have 128-bit block size, and the performance requirements on load balancers are tighter than on servers. In other words, having a 128-bit connection ID provides for an easy secure way to generate unlinkable connection IDs on migration. So, the problem we=E2=80=99re trying to solve is that the connection ID is = too small. There are two questions I believe the working group should answer at this point: 1. Do we want to address this problem at this point in standardization process? 2. If we don=E2=80=99t address this problem right now, how do we structu= re the standard in a way that we can extend the connection ID in the future? There are multiple ways to solve the problem of making connection ID larger. One is to just add extra bit to the =E2=80=9Comit connection ID=E2= =80=9D field to allow 128-bit connection IDs. Another approach is to allow connection ID size to be explicitly specified by the server, and then assume that the load balancer knows that size and no one else on the path needs to read it. There=E2=80=99s also a question of how much of connection IDs do middleboxe= s (excluding load balancers and other boxes owned by the same entity as either client or server) need to know. We could go for both =E2=80=9Cmiddl= eboxes should be always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddlebox= es should not read connection IDs at all options=E2=80=9D, but I think there=E2=80=99s al= so a room for more flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bi= ts and they have useful entropy to distinguish connections=E2=80=9D. -- Victor. --001a114ac18016a78d05629729fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = It could also be fix= ed 62 bit connection identifier and 2 msg of the first CID byte stores the = additional length. The requirement is then that the first 62 bits must have= =E2=80=9Cenough entropy=E2=80=9D and the remaining bits are application or= deployment specific. This will force routers to support 128-bits, but it w= ill allow them to require it if so desired.

    A router need not be concerned with the variable len= gth aspect if the QUIC invariant ensures that a packet length is at least l= ong enough to read 128 bits from CID start. It can just assume the length i= t expects and then validate as needed with auth tag or length, or just assu= me it is safe under the conditions.

    In all cases the QUIC endpoint MUST include the CID in the a= dditional data authentication to ensure routing data has not been tampered.=

    One could also take = this a step further and shorten the first 64 bits, but that is probably a r= ats nest: 16, 32, 64, 128 bits.



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


    On 12 January 2018 at 16.51.19, Lubashev, Igor (ilubashe@akamai.com) wrote:

    The point here is that if 128-bit is an option from = V1, then all clients will support it, and the server can choose to always u= se 128-bit connection IDs.=C2=A0 The load balancer then can be sure that va= lid connection IDs (in packets featuring server connection ID) can only be 128-bit.=C2=A0 If V1 does not have 128-b= it support, then the server must develop a less secure version of the conne= ction ID to fit into 64 bits, and the load balancer must treat 64-bit conne= ction IDs as acceptable.=C2=A0 Then, there is nothing to prevent an attacker from using 64-bit connection IDs, if tha= t=E2=80=99s more convenient for them.

    =C2=A0

    From: Ian Swett [mailto:ianswett@google.com]
    Sent: Friday, January 12, 2018 9:35 AM
    To: Lubashev, Igor <ilubas= he@akamai.com>
    Cc: quic@ietf.org; huitema@huitema.net
    Subject: Re: Increasing QUIC connection ID size

    =C2=A0

    I think we'll want support for both no matter ho= w we do this.

    =C2=A0

    On Fri, Jan 12, 2018 at 9:13 AM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

    If the 128-bit option is= not in V1, then it will be required for the 128-bit option to be signaled = in the packet's invariant section (like a bit in the 1st byte). Otherwi= se, the very load balancers this is designed for will not know whether the connection ID has 64- or 128-bit format. (It= would need to support both, since there would be clients stuck at V1.)

    In fact, the security promises of having a 128-bit connection ID option (al= lows for making routing info harder to forge) are greatly diminished, when = a load balancer has to support 64-bit connection IDs "forever".



    -----Original Message-----
    From: Ian Swett [ianswett@google.com]
    Received: Friday, 12 Jan 2018, 8:59AM
    To: Christian Huitema [huitema@huitema.net]
    CC: IETF QUIC WG [quic@ietf.org]
    Subject: Re: Increasing QUIC connection ID size

    I would like to leave QUIC open for longer connectio= n IDs in future versions, so I'd like to specify the invariants in such= a way that longer connection Ids wouldn't violate them(ie: Victor'= s suggestion of=C2=A0=E2=80=9Cmiddleboxes always get first 64 bits and they have useful entropy to distinguish connections=E2=80=9D.)= but I'm reluctant to include 128 bit connection IDs in v1 at this poin= t.


    I would also echo Christian's sentiment that the incremental overhead s= tarts becoming fairly large.

    =C2=A0

    On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema &= lt;huitema@huitema= .net> wrote:

    We have a prototype implementation in Picoquic in wh= ich the connection ID can be split so some bits are random and some bits ar= e used for routing to a specific server -- thanks Igor for that. It makes f= or nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in= such a way as to target a specific server in a pool, or they could learn w= hich connections are on the same server and use that later for some kind of= same server attack. It would be better if that information was not in clear text. In fact, the picoquic im= plementation use a callback to ask for the new value -- presumably from the= router. That callback could return anything, including an encrypted value.=

    On the other hand, it is not clear to me that we need full encryption. For = example, assume that the server that needs a connection ID can ask it from = the router. The router could pick one at random, make sure that it is prope= rly documented in the routing tables and that there is no collision, and then pass it back to the server. No en= cryption needed, but of course lots of state.

    If the router does not want to keep the state, it can indeed create a conne= ction ID by encrypting a <nonce, server-ID> tuple. But it does not fo= llow that the encryption needs to be 128 bits. For example, it could use a = 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit= concerned by the incremental overhead if the connection ID suddenly become= s very large.



    On 1/11/2018 2:25 PM, Mikkel Fahn=C3=B8e J=C3=B8rgen= sen wrote:

    Actually, on encryption of connection ID, this is= not so simple.

    =C2=A0

    We must assume there is only a single key for man= y connections because the router is not part of a key exchange. This unique= value or counter used for encrypting a single block cannot be the same for two different connections ID=E2=80=99s, but i= t can be public. This means that it must be stored in the packet header. An= d, as it turns out, random connection ID chosen by a trusted source, can be= used for such a unique value. But then it must be used to encrypt and/or authenticate something else carrying the= actual routing information. So now you start to really need some extra pay= load.

    =C2=A0

    Alternatively the routing information is entirely= random such as content hashed routing. Then you only need to authenticate = the routing data. You can do that with a HMAC, and CMAC could probably also work. The additional benefit is that you can = probably get away with 64-bits for all routing information possibly includi= ng the auth tag. Say 48 bits of routing data and 16 bits of auth tag.

    =C2=A0

    Kind Regards,

    Mikkel Fahn=C3=B8e= J=C3=B8rgensen

    =C2=A0

    On 12 Januar= y 2018 at 00.57.21, Lubashev, Igor (ilubashe@akamai.com) wrote:

    I am interested in exploring this proposal, since it allows for mo= re flexible schemes of encoding routing metadata and a checksum.=C2=A0 I wo= uld also like to be explicit about the connection ID size in a packet header, though, since it greatly simplifies the implem= entation.

    =C2=A0

    • Igor

    From: Victor Vasiliev [mailto:vasilvv@google.com]
    Sent: Thursday, January 11, 2018 6:16 PM
    To: IETF QUIC WG <quic@ietf.org>
    Subject: Increasing QUIC connection ID size

    =C2=A0

    Hi everyone,

    =C2=A0

    In the current version of QUIC, the connection ID size is fixed to= be a 64-bit opaque blob, and that is set as an invariant in the protocol.<= /p>

    =C2=A0

    I=E2=80=99ve looked into possibility of using a connection ID to e= ncode the specific server details into it (to provide stability of the conn= ection in case of load balancing changes, especially BGP flaps for anycast IPs), and have chatted about this with other people = I knew were interested in this.=C2=A0 It seems like 64 bits might be too sm= all for this purpose, and we might want to leave an opportunity to extend t= he connection ID size.

    =C2=A0

    The basic idea is that you want to be able to:

    1. Store some routing metadata in the connection ID.
    2. Have some entropy that allows distinguish users with identical routing meta= data.=20
    3. Have a checksum to ensure the validity of routing information
    4. Encrypt the information above to prevent disclosing the route information a= nd allow generating uncorrelatable connection IDs.

    There are two underlying issues here.=C2=A0 The first problem is t= hat all of this does not fit well into 64 bits, and you have to seriously c= ompromise on the strength of the checksum (which is bad especially if you want it to be a MAC rather than a checksum= ).=C2=A0 The second problem is that encrypting 64-bit values fast is actual= ly fairly hard since the block ciphers easily available in hardware have 12= 8-bit block size, and the performance requirements on load balancers are tighter than on servers.=C2=A0=C2=A0

    =C2=A0

    In other words, having a 128-bit connection ID provides for an eas= y secure way to generate unlinkable connection IDs on migration.

    =C2=A0

    So, the problem we=E2=80=99re trying to solve is that the connecti= on ID is too small.=C2=A0 There are two questions I believe the working gro= up should answer at this point:

    1. Do we want to address this problem at this point in standardization process= ?=20
    2. If we don=E2=80=99t address this problem right now, how do we structure the= standard in a way that we can extend the connection ID in the future?

    There are multiple ways to solve the problem of making connection = ID larger.=C2=A0 One is to just add extra bit to the =E2=80=9Comit connecti= on ID=E2=80=9D field to allow 128-bit connection IDs.=C2=A0 Another approach is to allow connection ID size to be explicitly specified by the = server, and then assume that the load balancer knows that size and no one e= lse on the path needs to read it.

    =C2=A0

    There=E2=80=99s also a question of how much of connection IDs do m= iddleboxes (excluding load balancers and other boxes owned by the same enti= ty as either client or server) need to know.=C2=A0 We could go for both =E2=80=9Cmiddleboxes should be always able to read th= e entire ID=E2=80=9D and =E2=80=9Cmiddleboxes should not read connection ID= s at all options=E2=80=9D, but I think there=E2=80=99s also a room for more= flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits a= nd they have useful entropy to distinguish connections=E2=80=9D.

    =C2=A0

    =C2=A0 -- Victor.

    =C2=A0

    =C2=A0

    =C2=A0

    --001a114ac18016a78d05629729fb-- From nobody Fri Jan 12 09:46:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CB012D82E for ; Fri, 12 Jan 2018 09:46:22 -0800 (PST) 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 (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 d9-neHC3s1zq for ; Fri, 12 Jan 2018 09:46:17 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30639129C6E for ; Fri, 12 Jan 2018 09:46:15 -0800 (PST) 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=Sm79O4MESRt1jkhqKfStOAM3sH+DQu+i/dfk9cfd8jw=; b=VKIZbPtsyLUPBkxR/5olhn6PfPbjFKA5ymRxqijlNNKE1rzQupXhZeoHl99plvboJtW2RondhiPSjf91Ip27Ajr1HcmlrNnFz+7GcUJVi9s5+YetopiCIj1evVGCUTpMdoNvB3Lzp2TNHFX4Pg2dx/KypjJb/idmlknaGSZ1wI4= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0469.namprd21.prod.outlook.com (10.172.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.428.12; Fri, 12 Jan 2018 17:46:12 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0428.002; Fri, 12 Jan 2018 17:46:12 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lubashev, Igor" , Ian Swett CC: "quic@ietf.org" , huitema Subject: RE: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizIyJhSpmciQrEaeNJfcAn7eW6NvWU8AgAAH/ICAACekgIAAu38AgAAEVICAAAXYAIAAFUUAgAASm4CAAAlmAA== Date: Fri, 12 Jan 2018 17:46:12 +0000 Message-ID: References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:a::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0469; 7:mp7Ckc/P3GdenzmqoUCDpDUgg94qxoeLP65wu+ap+GfMGBbdRqzQNasOUAkqMA8m9cEEhk0vpPwia789vYX1aMRgPLscyjq7GoDHOL6gkYKaUH3YeClx5PF9naeV4ZwYnwSv5a27eU2chBUO6AtA0l/rPn4bE0VZMQHwRTyFp1dmwTPhNKcOl31bYOcbe+THW15T8bsjo1wGQYBvtHnXaPQuEjZpNmrcytECUhx5BQ19OWiWOQm+7zDv/2hwb4Eq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e9a94cc2-4819-48f7-be47-08d559e45f28 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020085)(4652020)(4534115)(4602075)(4627211)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0469; x-ms-traffictypediagnostic: CY4PR21MB0469: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(10201501046)(3002001)(93006095)(93001095)(3231023)(944501146)(6055026)(61426038)(61427038)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0469; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:CY4PR21MB0469; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(39380400002)(366004)(376002)(53754006)(13464003)(199004)(189003)(24454002)(7696005)(6506007)(6116002)(102836004)(53546011)(790700001)(76176011)(25786009)(6246003)(59450400001)(19609705001)(4326008)(54896002)(53946003)(55016002)(236005)(53936002)(2900100001)(478600001)(9686003)(6306002)(99286004)(110136005)(54906003)(22452003)(316002)(93886005)(86362001)(33656002)(561944003)(39060400002)(14454004)(10290500003)(86612001)(5660300001)(8990500004)(2950100002)(97736004)(10090500001)(74316002)(229853002)(2906002)(7736002)(8676002)(6436002)(8936002)(81166006)(77096006)(81156014)(3280700002)(3660700001)(68736007)(106356001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0469; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nA0/5H7CNmW+Hh87KhINiN0+oaQ56/PyezZbk7MdatZqjAqSuN4e6Oq4MCL9sw0Qk5FjsgUxIg4WUB5QYBrO4A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01331A05F3F44C335FF78156B6170CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9a94cc2-4819-48f7-be47-08d559e45f28 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 17:46:12.5813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0469 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 17:46:22 -0000 --_000_CY4PR21MB01331A05F3F44C335FF78156B6170CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SU1PIHdlIG5lZWQgdG8gc2V0dGxlIG9uIGEgc2l6ZSBmb3IgQ0lEIGFuZCBtYWtlIGl0IGFuIGlu dmFyaWFudCBpbiB2MS4gTGV04oCZcyBhbHNvIG5vdCBpbnRyb2R1Y2UgbW9yZSBlbmNvZGluZyBp bnRvIG9uZSBvZiB0aGUgdmVyeSBmZXcgZmllbGRzIHRoYXQgaXMgcGxhaW50ZXh0LiBXZSBzaG91 bGQgYWltIGZvciBlYXN5IGFuZCBmYXN0IGFkb3B0aW9uIG9mIFFVSUMgYnkgbWlkZGxld2FyZS4g UmVxdWlyaW5nIGluZnJhc3RydWN0dXJlIGNvbXBvbmVudHMgbGlrZSBsb2FkIGJhbGFuY2VyIG9y IEREb1MgcHJvdGVjdGlvbiB0byBkZWNyeXB0IGlzIGdvaW5nIHRvIG1lYW4gYW4gb3JkZXIgb2Yg bWFnbml0dWRlIHJlZHVjdGlvbiBpbiBwZXJmb3JtYW5jZSBhbmQgd2lsbCBiZSBoYXJkIGZvciBk ZXBsb3ltZW50IGFuZCBzaGFyZWQga2V5cyBhcmUgY2VydGFpbmx5IG5vdCBhbiBvcHRpb24gZm9y IElhYVMgc2NlbmFyaW8uDQoNClBhcnRpY3VsYXJseSBpbiByZWxhdGlvbiB0byBsb2FkIGJhbGFu Y2VyIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBjYXNlczoNCg0KICAxLiAgQ29ubmVjdGlvbiByZW1h aW5zIG9uIHRoZSBzYW1lIDQtdHVwbGUgZm9yIGl0cyBsaWZldGltZS4gSGVyZSB0b2RheeKAmXMg dW5tb2RpZmllZCBsb2FkIGJhbGFuY2VycyBqdXN0IHdvcmsgc2luY2UgdGhleSBoYXNoIG9uIDIt IG9yIDQtdHVwbGUgKFVEUC9JUCkuDQogIDIuICBOQVQgcmViaW5kaW5nLiBGb3IgdGhpcyBsb2Fk IGJhbGFuY2VyIG5lZWRzIHRvIGhhc2ggYmFzZWQgb24gQ0lEIGFuZCBub3QgNC10dXBsZS4gU28g dGhlcmUgbmVlZHMgdG8gYmUgUVVJQyAodmVyc2lvbiBzcGVjaWZpYykgYXdhcmVuZXNzLiBOb3Qg YSBkZWFsIGJyZWFrZXIgYW5kIHNlZW1zIGRvYWJsZS4gQnV0IGl0IGRvZXMgaW1wbHkgdGhhdCBz ZXJ2ZXIgd2lsbCBhbHdheXMgaGF2ZSB0byBmb3JjZSBpbmNsdXNpb24gb2YgQ0lEIGZyb20gY2xp ZW50Lg0KICAzLiAgQ29ubmVjdGlvbiBtaWdyYXRpb24uIFRoaXMgaXMgY29tcGxpY2F0ZWQgYmVj YXVzZSBpdCBzZWVtcyB0byByZXF1aXJlIHRoZSBzZXJ2ZXIgdG8gcGljayBhIG5ldyBjb25uZWN0 aW9uIElEIHN1Y2ggdGhhdCBsb2FkIGJhbGFuY2VyIHdpbGwgcGljayB0aGUgc2FtZSBzZXJ2ZXIg YWdhaW4uIFRoaXMgY291cGxpbmcgd2lsbCBiZSBwcm9ibGVtYXRpYyBpbiBJYWFTIHNjZW5hcmlv IHdoZXJlIHRoZSBsb2FkIGJhbGFuY2VyIG1heSBiZSBvd25lZCBieSB0aGUgY2xvdWQgcHJvdmlk ZXIgYW5kIHRoZSBiYWNrZW5kIHNlcnZlciB0ZXJtaW5hdGluZyBRVUlDIG93bmVkIGJ5IGEgdGVu YW50LiBGb3IgdGhpcyByZWFzb24gaXQgc2VlbXMgdG8gbWUgdGhhdCB0byBzdXBwb3J0IGNvbm5l Y3Rpb24gbWlncmF0aW9uIHdlIG5lZWQgYSBzdGFuZGFyZCBsb2FkIGJhbGFuY2luZyBzY2hlbWUg ZGVmaW5lZCBpbiBhIOKAnGRlcGxveW1lbnQgaXNzdWVz4oCdIHNlY3Rpb24gaW4gdGhlIFJGQy4g QW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCg0KTXkgcHJlZmVyZW5jZSBmb3IgQ0lEIGlzIHN0aWxs IDY0LWJpdCBzaW5jZSB3ZSBoYXZlIGdvbmUgb3V0IG9mIG91ciB3YXkgdG8gc2F2ZSBzcGFjZSBp biB0aGUgaGVhZGVycyB1c2luZyBWTEUgYnV0IDEyOC1iaXQgaXMgbm90IGEgZGVhbCBicmVha2Vy LiBXZSBzaG91bGQgYWxzbyBsZWF2ZSB0aGUgZW5jb2Rpbmcgb2YgdGhlIENJRCB0byB0aGUgc2Vy dmVyIHJhdGhlciB0aGFuIHNwZWNpZnkgYW55IHBhcnRpY3VsYXIgc2NoZW1lIGJ1dCBzcGVjaWZ5 aW5nIHdoYXQgbG9hZCBiYWxhbmNlcnMgc2hvdWxkIGRvIHNlZW1zIGltcG9ydGFudCBmb3Igc3Vw cG9ydGluZyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4NCg0KVGhhbmtzDQoNCkZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTIsIDIwMTggODo1OCBBTQ0KVG86IEx1 YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBn b29nbGUuY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5u ZXQ+DQpTdWJqZWN0OiBSRTogSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZQ0KDQpJ dCBjb3VsZCBhbHNvIGJlIGZpeGVkIDYyIGJpdCBjb25uZWN0aW9uIGlkZW50aWZpZXIgYW5kIDIg bXNnIG9mIHRoZSBmaXJzdCBDSUQgYnl0ZSBzdG9yZXMgdGhlIGFkZGl0aW9uYWwgbGVuZ3RoLiBU aGUgcmVxdWlyZW1lbnQgaXMgdGhlbiB0aGF0IHRoZSBmaXJzdCA2MiBiaXRzIG11c3QgaGF2ZSDi gJxlbm91Z2ggZW50cm9weeKAnSBhbmQgdGhlIHJlbWFpbmluZyBiaXRzIGFyZSBhcHBsaWNhdGlv biBvciBkZXBsb3ltZW50IHNwZWNpZmljLiBUaGlzIHdpbGwgZm9yY2Ugcm91dGVycyB0byBzdXBw b3J0IDEyOC1iaXRzLCBidXQgaXQgd2lsbCBhbGxvdyB0aGVtIHRvIHJlcXVpcmUgaXQgaWYgc28g ZGVzaXJlZC4NCg0KQSByb3V0ZXIgbmVlZCBub3QgYmUgY29uY2VybmVkIHdpdGggdGhlIHZhcmlh YmxlIGxlbmd0aCBhc3BlY3QgaWYgdGhlIFFVSUMgaW52YXJpYW50IGVuc3VyZXMgdGhhdCBhIHBh Y2tldCBsZW5ndGggaXMgYXQgbGVhc3QgbG9uZyBlbm91Z2ggdG8gcmVhZCAxMjggYml0cyBmcm9t IENJRCBzdGFydC4gSXQgY2FuIGp1c3QgYXNzdW1lIHRoZSBsZW5ndGggaXQgZXhwZWN0cyBhbmQg dGhlbiB2YWxpZGF0ZSBhcyBuZWVkZWQgd2l0aCBhdXRoIHRhZyBvciBsZW5ndGgsIG9yIGp1c3Qg YXNzdW1lIGl0IGlzIHNhZmUgdW5kZXIgdGhlIGNvbmRpdGlvbnMuDQoNCkluIGFsbCBjYXNlcyB0 aGUgUVVJQyBlbmRwb2ludCBNVVNUIGluY2x1ZGUgdGhlIENJRCBpbiB0aGUgYWRkaXRpb25hbCBk YXRhIGF1dGhlbnRpY2F0aW9uIHRvIGVuc3VyZSByb3V0aW5nIGRhdGEgaGFzIG5vdCBiZWVuIHRh bXBlcmVkLg0KDQpPbmUgY291bGQgYWxzbyB0YWtlIHRoaXMgYSBzdGVwIGZ1cnRoZXIgYW5kIHNo b3J0ZW4gdGhlIGZpcnN0IDY0IGJpdHMsIGJ1dCB0aGF0IGlzIHByb2JhYmx5IGEgcmF0cyBuZXN0 OiAxNiwgMzIsIDY0LCAxMjggYml0cy4NCg0KDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4NCg0KDQpPbiAxMiBKYW51YXJ5IDIwMTggYXQgMTYuNTEuMTksIEx1YmFz aGV2LCBJZ29yIChpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Pikgd3JvdGU6DQpUaGUgcG9pbnQgaGVyZSBpcyB0aGF0IGlmIDEyOC1iaXQgaXMgYW4gb3B0aW9u IGZyb20gVjEsIHRoZW4gYWxsIGNsaWVudHMgd2lsbCBzdXBwb3J0IGl0LCBhbmQgdGhlIHNlcnZl ciBjYW4gY2hvb3NlIHRvIGFsd2F5cyB1c2UgMTI4LWJpdCBjb25uZWN0aW9uIElEcy4gIFRoZSBs b2FkIGJhbGFuY2VyIHRoZW4gY2FuIGJlIHN1cmUgdGhhdCB2YWxpZCBjb25uZWN0aW9uIElEcyAo aW4gcGFja2V0cyBmZWF0dXJpbmcgc2VydmVyIGNvbm5lY3Rpb24gSUQpIGNhbiBvbmx5IGJlIDEy OC1iaXQuICBJZiBWMSBkb2VzIG5vdCBoYXZlIDEyOC1iaXQgc3VwcG9ydCwgdGhlbiB0aGUgc2Vy dmVyIG11c3QgZGV2ZWxvcCBhIGxlc3Mgc2VjdXJlIHZlcnNpb24gb2YgdGhlIGNvbm5lY3Rpb24g SUQgdG8gZml0IGludG8gNjQgYml0cywgYW5kIHRoZSBsb2FkIGJhbGFuY2VyIG11c3QgdHJlYXQg NjQtYml0IGNvbm5lY3Rpb24gSURzIGFzIGFjY2VwdGFibGUuICBUaGVuLCB0aGVyZSBpcyBub3Ro aW5nIHRvIHByZXZlbnQgYW4gYXR0YWNrZXIgZnJvbSB1c2luZyA2NC1iaXQgY29ubmVjdGlvbiBJ RHMsIGlmIHRoYXTigJlzIG1vcmUgY29udmVuaWVudCBmb3IgdGhlbS4NCg0KRnJvbTogSWFuIFN3 ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv bT5dDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMTIsIDIwMTggOTozNSBBTQ0KVG86IEx1YmFzaGV2 LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4N CkNjOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPjsgaHVpdGVtYUBodWl0ZW1h Lm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4NClN1YmplY3Q6IFJlOiBJbmNyZWFzaW5n IFFVSUMgY29ubmVjdGlvbiBJRCBzaXplDQoNCkkgdGhpbmsgd2UnbGwgd2FudCBzdXBwb3J0IGZv ciBib3RoIG5vIG1hdHRlciBob3cgd2UgZG8gdGhpcy4NCg0KT24gRnJpLCBKYW4gMTIsIDIwMTgg YXQgOToxMyBBTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCklmIHRoZSAxMjgtYml0IG9wdGlvbiBpcyBub3Qg aW4gVjEsIHRoZW4gaXQgd2lsbCBiZSByZXF1aXJlZCBmb3IgdGhlIDEyOC1iaXQgb3B0aW9uIHRv IGJlIHNpZ25hbGVkIGluIHRoZSBwYWNrZXQncyBpbnZhcmlhbnQgc2VjdGlvbiAobGlrZSBhIGJp dCBpbiB0aGUgMXN0IGJ5dGUpLiBPdGhlcndpc2UsIHRoZSB2ZXJ5IGxvYWQgYmFsYW5jZXJzIHRo aXMgaXMgZGVzaWduZWQgZm9yIHdpbGwgbm90IGtub3cgd2hldGhlciB0aGUgY29ubmVjdGlvbiBJ RCBoYXMgNjQtIG9yIDEyOC1iaXQgZm9ybWF0LiAoSXQgd291bGQgbmVlZCB0byBzdXBwb3J0IGJv dGgsIHNpbmNlIHRoZXJlIHdvdWxkIGJlIGNsaWVudHMgc3R1Y2sgYXQgVjEuKQ0KDQpJbiBmYWN0 LCB0aGUgc2VjdXJpdHkgcHJvbWlzZXMgb2YgaGF2aW5nIGEgMTI4LWJpdCBjb25uZWN0aW9uIElE IG9wdGlvbiAoYWxsb3dzIGZvciBtYWtpbmcgcm91dGluZyBpbmZvIGhhcmRlciB0byBmb3JnZSkg YXJlIGdyZWF0bHkgZGltaW5pc2hlZCwgd2hlbiBhIGxvYWQgYmFsYW5jZXIgaGFzIHRvIHN1cHBv cnQgNjQtYml0IGNvbm5lY3Rpb24gSURzICJmb3JldmVyIi4NCg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogSWFuIFN3ZXR0IFtpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tPl0NClJlY2VpdmVkOiBGcmlkYXksIDEyIEphbiAyMDE4LCA4OjU5 QU0NClRvOiBDaHJpc3RpYW4gSHVpdGVtYSBbaHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVp dGVtYUBodWl0ZW1hLm5ldD5dDQpDQzogSUVURiBRVUlDIFdHIFtxdWljQGlldGYub3JnPG1haWx0 bzpxdWljQGlldGYub3JnPl0NClN1YmplY3Q6IFJlOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlv biBJRCBzaXplDQpJIHdvdWxkIGxpa2UgdG8gbGVhdmUgUVVJQyBvcGVuIGZvciBsb25nZXIgY29u bmVjdGlvbiBJRHMgaW4gZnV0dXJlIHZlcnNpb25zLCBzbyBJJ2QgbGlrZSB0byBzcGVjaWZ5IHRo ZSBpbnZhcmlhbnRzIGluIHN1Y2ggYSB3YXkgdGhhdCBsb25nZXIgY29ubmVjdGlvbiBJZHMgd291 bGRuJ3QgdmlvbGF0ZSB0aGVtKGllOiBWaWN0b3IncyBzdWdnZXN0aW9uIG9mIOKAnG1pZGRsZWJv eGVzIGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5 IHRvIGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLikgYnV0IEknbSByZWx1Y3RhbnQgdG8gaW5j bHVkZSAxMjggYml0IGNvbm5lY3Rpb24gSURzIGluIHYxIGF0IHRoaXMgcG9pbnQuDQoNCkkgd291 bGQgYWxzbyBlY2hvIENocmlzdGlhbidzIHNlbnRpbWVudCB0aGF0IHRoZSBpbmNyZW1lbnRhbCBv dmVyaGVhZCBzdGFydHMgYmVjb21pbmcgZmFpcmx5IGxhcmdlLg0KDQpPbiBUaHUsIEphbiAxMSwg MjAxOCBhdCA5OjQ3IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KV2UgaGF2ZSBhIHByb3RvdHlwZSBp bXBsZW1lbnRhdGlvbiBpbiBQaWNvcXVpYyBpbiB3aGljaCB0aGUgY29ubmVjdGlvbiBJRCBjYW4g YmUgc3BsaXQgc28gc29tZSBiaXRzIGFyZSByYW5kb20gYW5kIHNvbWUgYml0cyBhcmUgdXNlZCBm b3Igcm91dGluZyB0byBhIHNwZWNpZmljIHNlcnZlciAtLSB0aGFua3MgSWdvciBmb3IgdGhhdC4g SXQgbWFrZXMgZm9yIG5pY2UgZXhwZXJpbWVudHMsIGJ1dCBpdCBpcyBhIGRlbmlhbCBvZiBzZXJ2 aWNlIHdhaXRpbmcgdG8gaGFwcGVuLiBGb3IgZXhhbXBsZSwgYXR0YWNrZXJzIGNvdWxkIHNldCB0 aGUgYml0cyBpbiBzdWNoIGEgd2F5IGFzIHRvIHRhcmdldCBhIHNwZWNpZmljIHNlcnZlciBpbiBh IHBvb2wsIG9yIHRoZXkgY291bGQgbGVhcm4gd2hpY2ggY29ubmVjdGlvbnMgYXJlIG9uIHRoZSBz YW1lIHNlcnZlciBhbmQgdXNlIHRoYXQgbGF0ZXIgZm9yIHNvbWUga2luZCBvZiBzYW1lIHNlcnZl ciBhdHRhY2suIEl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGF0IGluZm9ybWF0aW9uIHdhcyBub3Qg aW4gY2xlYXIgdGV4dC4gSW4gZmFjdCwgdGhlIHBpY29xdWljIGltcGxlbWVudGF0aW9uIHVzZSBh IGNhbGxiYWNrIHRvIGFzayBmb3IgdGhlIG5ldyB2YWx1ZSAtLSBwcmVzdW1hYmx5IGZyb20gdGhl IHJvdXRlci4gVGhhdCBjYWxsYmFjayBjb3VsZCByZXR1cm4gYW55dGhpbmcsIGluY2x1ZGluZyBh biBlbmNyeXB0ZWQgdmFsdWUuDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBpdCBpcyBub3QgY2xlYXIg dG8gbWUgdGhhdCB3ZSBuZWVkIGZ1bGwgZW5jcnlwdGlvbi4gRm9yIGV4YW1wbGUsIGFzc3VtZSB0 aGF0IHRoZSBzZXJ2ZXIgdGhhdCBuZWVkcyBhIGNvbm5lY3Rpb24gSUQgY2FuIGFzayBpdCBmcm9t IHRoZSByb3V0ZXIuIFRoZSByb3V0ZXIgY291bGQgcGljayBvbmUgYXQgcmFuZG9tLCBtYWtlIHN1 cmUgdGhhdCBpdCBpcyBwcm9wZXJseSBkb2N1bWVudGVkIGluIHRoZSByb3V0aW5nIHRhYmxlcyBh bmQgdGhhdCB0aGVyZSBpcyBubyBjb2xsaXNpb24sIGFuZCB0aGVuIHBhc3MgaXQgYmFjayB0byB0 aGUgc2VydmVyLiBObyBlbmNyeXB0aW9uIG5lZWRlZCwgYnV0IG9mIGNvdXJzZSBsb3RzIG9mIHN0 YXRlLg0KDQpJZiB0aGUgcm91dGVyIGRvZXMgbm90IHdhbnQgdG8ga2VlcCB0aGUgc3RhdGUsIGl0 IGNhbiBpbmRlZWQgY3JlYXRlIGEgY29ubmVjdGlvbiBJRCBieSBlbmNyeXB0aW5nIGEgPG5vbmNl LCBzZXJ2ZXItSUQ+IHR1cGxlLiBCdXQgaXQgZG9lcyBub3QgZm9sbG93IHRoYXQgdGhlIGVuY3J5 cHRpb24gbmVlZHMgdG8gYmUgMTI4IGJpdHMuIEZvciBleGFtcGxlLCBpdCBjb3VsZCB1c2UgYSA2 NCBiaXQgYWxnb3JpdGhtIGxpa2UgQmxvd2Zpc2guDQoNClNvIEkgYW0gbm90IHN1cmUgdGhhdCB3 ZSBhY3R1YWxseSBuZWVkIHRvIGNoYW5nZSB0aGUgbGVuZ3RoLiBBbmQgSSBhbSBhIGJpdCBjb25j ZXJuZWQgYnkgdGhlIGluY3JlbWVudGFsIG92ZXJoZWFkIGlmIHRoZSBjb25uZWN0aW9uIElEIHN1 ZGRlbmx5IGJlY29tZXMgdmVyeSBsYXJnZS4NCg0KT24gMS8xMS8yMDE4IDI6MjUgUE0sIE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gd3JvdGU6DQpBY3R1YWxseSwgb24gZW5jcnlwdGlvbiBvZiBj b25uZWN0aW9uIElELCB0aGlzIGlzIG5vdCBzbyBzaW1wbGUuDQoNCldlIG11c3QgYXNzdW1lIHRo ZXJlIGlzIG9ubHkgYSBzaW5nbGUga2V5IGZvciBtYW55IGNvbm5lY3Rpb25zIGJlY2F1c2UgdGhl IHJvdXRlciBpcyBub3QgcGFydCBvZiBhIGtleSBleGNoYW5nZS4gVGhpcyB1bmlxdWUgdmFsdWUg b3IgY291bnRlciB1c2VkIGZvciBlbmNyeXB0aW5nIGEgc2luZ2xlIGJsb2NrIGNhbm5vdCBiZSB0 aGUgc2FtZSBmb3IgdHdvIGRpZmZlcmVudCBjb25uZWN0aW9ucyBJROKAmXMsIGJ1dCBpdCBjYW4g YmUgcHVibGljLiBUaGlzIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBzdG9yZWQgaW4gdGhlIHBhY2tl dCBoZWFkZXIuIEFuZCwgYXMgaXQgdHVybnMgb3V0LCByYW5kb20gY29ubmVjdGlvbiBJRCBjaG9z ZW4gYnkgYSB0cnVzdGVkIHNvdXJjZSwgY2FuIGJlIHVzZWQgZm9yIHN1Y2ggYSB1bmlxdWUgdmFs dWUuIEJ1dCB0aGVuIGl0IG11c3QgYmUgdXNlZCB0byBlbmNyeXB0IGFuZC9vciBhdXRoZW50aWNh dGUgc29tZXRoaW5nIGVsc2UgY2FycnlpbmcgdGhlIGFjdHVhbCByb3V0aW5nIGluZm9ybWF0aW9u LiBTbyBub3cgeW91IHN0YXJ0IHRvIHJlYWxseSBuZWVkIHNvbWUgZXh0cmEgcGF5bG9hZC4NCg0K QWx0ZXJuYXRpdmVseSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBpcyBlbnRpcmVseSByYW5kb20g c3VjaCBhcyBjb250ZW50IGhhc2hlZCByb3V0aW5nLiBUaGVuIHlvdSBvbmx5IG5lZWQgdG8gYXV0 aGVudGljYXRlIHRoZSByb3V0aW5nIGRhdGEuIFlvdSBjYW4gZG8gdGhhdCB3aXRoIGEgSE1BQywg YW5kIENNQUMgY291bGQgcHJvYmFibHkgYWxzbyB3b3JrLiBUaGUgYWRkaXRpb25hbCBiZW5lZml0 IGlzIHRoYXQgeW91IGNhbiBwcm9iYWJseSBnZXQgYXdheSB3aXRoIDY0LWJpdHMgZm9yIGFsbCBy b3V0aW5nIGluZm9ybWF0aW9uIHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgYXV0aCB0YWcuIFNheSA0 OCBiaXRzIG9mIHJvdXRpbmcgZGF0YSBhbmQgMTYgYml0cyBvZiBhdXRoIHRhZy4NCg0KS2luZCBS ZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDEyIEphbnVhcnkgMjAx OCBhdCAwMC41Ny4yMSwgTHViYXNoZXYsIElnb3IgKGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRv OmlsdWJhc2hlQGFrYW1haS5jb20+KSB3cm90ZToNCkkgYW0gaW50ZXJlc3RlZCBpbiBleHBsb3Jp bmcgdGhpcyBwcm9wb3NhbCwgc2luY2UgaXQgYWxsb3dzIGZvciBtb3JlIGZsZXhpYmxlIHNjaGVt ZXMgb2YgZW5jb2Rpbmcgcm91dGluZyBtZXRhZGF0YSBhbmQgYSBjaGVja3N1bS4gIEkgd291bGQg YWxzbyBsaWtlIHRvIGJlIGV4cGxpY2l0IGFib3V0IHRoZSBjb25uZWN0aW9uIElEIHNpemUgaW4g YSBwYWNrZXQgaGVhZGVyLCB0aG91Z2gsIHNpbmNlIGl0IGdyZWF0bHkgc2ltcGxpZmllcyB0aGUg aW1wbGVtZW50YXRpb24uDQoNCg0KICAqICAgSWdvcg0KRnJvbTogVmljdG9yIFZhc2lsaWV2IFtt YWlsdG86dmFzaWx2dkBnb29nbGUuY29tPG1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20+XQ0KU2Vu dDogVGh1cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNjoxNiBQTQ0KVG86IElFVEYgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBJbmNyZWFzaW5n IFFVSUMgY29ubmVjdGlvbiBJRCBzaXplDQoNCkhpIGV2ZXJ5b25lLA0KDQpJbiB0aGUgY3VycmVu dCB2ZXJzaW9uIG9mIFFVSUMsIHRoZSBjb25uZWN0aW9uIElEIHNpemUgaXMgZml4ZWQgdG8gYmUg YSA2NC1iaXQgb3BhcXVlIGJsb2IsIGFuZCB0aGF0IGlzIHNldCBhcyBhbiBpbnZhcmlhbnQgaW4g dGhlIHByb3RvY29sLg0KDQpJ4oCZdmUgbG9va2VkIGludG8gcG9zc2liaWxpdHkgb2YgdXNpbmcg YSBjb25uZWN0aW9uIElEIHRvIGVuY29kZSB0aGUgc3BlY2lmaWMgc2VydmVyIGRldGFpbHMgaW50 byBpdCAodG8gcHJvdmlkZSBzdGFiaWxpdHkgb2YgdGhlIGNvbm5lY3Rpb24gaW4gY2FzZSBvZiBs b2FkIGJhbGFuY2luZyBjaGFuZ2VzLCBlc3BlY2lhbGx5IEJHUCBmbGFwcyBmb3IgYW55Y2FzdCBJ UHMpLCBhbmQgaGF2ZSBjaGF0dGVkIGFib3V0IHRoaXMgd2l0aCBvdGhlciBwZW9wbGUgSSBrbmV3 IHdlcmUgaW50ZXJlc3RlZCBpbiB0aGlzLiAgSXQgc2VlbXMgbGlrZSA2NCBiaXRzIG1pZ2h0IGJl IHRvbyBzbWFsbCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudCB0byBsZWF2ZSBh biBvcHBvcnR1bml0eSB0byBleHRlbmQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZS4NCg0KVGhlIGJh c2ljIGlkZWEgaXMgdGhhdCB5b3Ugd2FudCB0byBiZSBhYmxlIHRvOg0KDQogIDEuICBTdG9yZSBz b21lIHJvdXRpbmcgbWV0YWRhdGEgaW4gdGhlIGNvbm5lY3Rpb24gSUQuDQogIDIuICBIYXZlIHNv bWUgZW50cm9weSB0aGF0IGFsbG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50aWNhbCBy b3V0aW5nIG1ldGFkYXRhLg0KICAzLiAgSGF2ZSBhIGNoZWNrc3VtIHRvIGVuc3VyZSB0aGUgdmFs aWRpdHkgb2Ygcm91dGluZyBpbmZvcm1hdGlvbg0KICA0LiAgRW5jcnlwdCB0aGUgaW5mb3JtYXRp b24gYWJvdmUgdG8gcHJldmVudCBkaXNjbG9zaW5nIHRoZSByb3V0ZSBpbmZvcm1hdGlvbiBhbmQg YWxsb3cgZ2VuZXJhdGluZyB1bmNvcnJlbGF0YWJsZSBjb25uZWN0aW9uIElEcy4NClRoZXJlIGFy ZSB0d28gdW5kZXJseWluZyBpc3N1ZXMgaGVyZS4gIFRoZSBmaXJzdCBwcm9ibGVtIGlzIHRoYXQg YWxsIG9mIHRoaXMgZG9lcyBub3QgZml0IHdlbGwgaW50byA2NCBiaXRzLCBhbmQgeW91IGhhdmUg dG8gc2VyaW91c2x5IGNvbXByb21pc2Ugb24gdGhlIHN0cmVuZ3RoIG9mIHRoZSBjaGVja3N1bSAo d2hpY2ggaXMgYmFkIGVzcGVjaWFsbHkgaWYgeW91IHdhbnQgaXQgdG8gYmUgYSBNQUMgcmF0aGVy IHRoYW4gYSBjaGVja3N1bSkuICBUaGUgc2Vjb25kIHByb2JsZW0gaXMgdGhhdCBlbmNyeXB0aW5n IDY0LWJpdCB2YWx1ZXMgZmFzdCBpcyBhY3R1YWxseSBmYWlybHkgaGFyZCBzaW5jZSB0aGUgYmxv Y2sgY2lwaGVycyBlYXNpbHkgYXZhaWxhYmxlIGluIGhhcmR3YXJlIGhhdmUgMTI4LWJpdCBibG9j ayBzaXplLCBhbmQgdGhlIHBlcmZvcm1hbmNlIHJlcXVpcmVtZW50cyBvbiBsb2FkIGJhbGFuY2Vy cyBhcmUgdGlnaHRlciB0aGFuIG9uIHNlcnZlcnMuDQoNCkluIG90aGVyIHdvcmRzLCBoYXZpbmcg YSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgcHJvdmlkZXMgZm9yIGFuIGVhc3kgc2VjdXJlIHdheSB0 byBnZW5lcmF0ZSB1bmxpbmthYmxlIGNvbm5lY3Rpb24gSURzIG9uIG1pZ3JhdGlvbi4NCg0KU28s IHRoZSBwcm9ibGVtIHdl4oCZcmUgdHJ5aW5nIHRvIHNvbHZlIGlzIHRoYXQgdGhlIGNvbm5lY3Rp b24gSUQgaXMgdG9vIHNtYWxsLiAgVGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgSSBiZWxpZXZlIHRo ZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhbnN3ZXIgYXQgdGhpcyBwb2ludDoNCg0KICAxLiAgRG8g d2Ugd2FudCB0byBhZGRyZXNzIHRoaXMgcHJvYmxlbSBhdCB0aGlzIHBvaW50IGluIHN0YW5kYXJk aXphdGlvbiBwcm9jZXNzPw0KICAyLiAgSWYgd2UgZG9u4oCZdCBhZGRyZXNzIHRoaXMgcHJvYmxl bSByaWdodCBub3csIGhvdyBkbyB3ZSBzdHJ1Y3R1cmUgdGhlIHN0YW5kYXJkIGluIGEgd2F5IHRo YXQgd2UgY2FuIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBpbiB0aGUgZnV0dXJlPw0KVGhlcmUg YXJlIG11bHRpcGxlIHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgbWFraW5nIGNvbm5lY3Rp b24gSUQgbGFyZ2VyLiAgT25lIGlzIHRvIGp1c3QgYWRkIGV4dHJhIGJpdCB0byB0aGUg4oCcb21p dCBjb25uZWN0aW9uIElE4oCdIGZpZWxkIHRvIGFsbG93IDEyOC1iaXQgY29ubmVjdGlvbiBJRHMu ICBBbm90aGVyIGFwcHJvYWNoIGlzIHRvIGFsbG93IGNvbm5lY3Rpb24gSUQgc2l6ZSB0byBiZSBl eHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUgc2VydmVyLCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0 aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0IHNpemUgYW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBw YXRoIG5lZWRzIHRvIHJlYWQgaXQuDQoNClRoZXJl4oCZcyBhbHNvIGEgcXVlc3Rpb24gb2YgaG93 IG11Y2ggb2YgY29ubmVjdGlvbiBJRHMgZG8gbWlkZGxlYm94ZXMgKGV4Y2x1ZGluZyBsb2FkIGJh bGFuY2VycyBhbmQgb3RoZXIgYm94ZXMgb3duZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFzIGVpdGhl ciBjbGllbnQgb3Igc2VydmVyKSBuZWVkIHRvIGtub3cuICBXZSBjb3VsZCBnbyBmb3IgYm90aCDi gJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3YXlzIGFibGUgdG8gcmVhZCB0aGUgZW50aXJlIElE 4oCdIGFuZCDigJxtaWRkbGVib3hlcyBzaG91bGQgbm90IHJlYWQgY29ubmVjdGlvbiBJRHMgYXQg YWxsIG9wdGlvbnPigJ0sIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyBhbHNvIGEgcm9vbSBmb3IgbW9y ZSBmbGV4aWJsZSBmb3JtdWxhdGlvbnMgbGlrZSDigJxtaWRkbGVib3hlcyBhbHdheXMgZ2V0IGZp cnN0IDY0IGJpdHMgYW5kIHRoZXkgaGF2ZSB1c2VmdWwgZW50cm9weSB0byBkaXN0aW5ndWlzaCBj b25uZWN0aW9uc+KAnS4NCg0KICAtLSBWaWN0b3IuDQoNCg0KDQo= --_000_CY4PR21MB01331A05F3F44C335FF78156B6170CY4PR21MB0133namp_ 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 MiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBh cmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNv LXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJ e21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1s ZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNv LXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAubTIzMTk1ODAwOTg1NjY5ODQ1NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFpcm1haWxv biwgbGkubTIzMTk1ODAwOTg1NjY5ODQ1NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFpcm1haWxvbiwg ZGl2Lm0yMzE5NTgwMDk4NTY2OTg0NTQ0bTQ0NTIyMTQ2MDE1Njc1MTEyMjRhaXJtYWlsb24NCgl7 bXNvLXN0eWxlLW5hbWU6bTIzMTk1ODAwOTg1NjY5ODQ1NDRtNDQ1MjIxNDYwMTU2NzUxMTIyNGFp cm1haWxvbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEwMTE4Nzc4MjsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMDIyNTM0NDI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDoxNjY5NTU5ODg2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY2NjgyOTEz Mjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxODEyOTM4NjU4Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotOTgzMTQ4OTM2O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjIwODMwOTI0NDA7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yNzA5OTk3 NjggNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyB3ZSBuZWVkIHRvIHNldHRs ZSBvbiBhIHNpemUgZm9yIENJRCBhbmQgbWFrZSBpdCBhbiBpbnZhcmlhbnQgaW4gdjEuIExldOKA mXMgYWxzbyBub3QgaW50cm9kdWNlIG1vcmUgZW5jb2RpbmcgaW50byBvbmUgb2YgdGhlIHZlcnkg ZmV3IGZpZWxkcyB0aGF0IGlzIHBsYWludGV4dC4gV2Ugc2hvdWxkIGFpbSBmb3IgZWFzeSBhbmQg ZmFzdCBhZG9wdGlvbiBvZiBRVUlDIGJ5IG1pZGRsZXdhcmUuIFJlcXVpcmluZw0KIGluZnJhc3Ry dWN0dXJlIGNvbXBvbmVudHMgbGlrZSBsb2FkIGJhbGFuY2VyIG9yIEREb1MgcHJvdGVjdGlvbiB0 byBkZWNyeXB0IGlzIGdvaW5nIHRvIG1lYW4gYW4gb3JkZXIgb2YgbWFnbml0dWRlIHJlZHVjdGlv biBpbiBwZXJmb3JtYW5jZSBhbmQgd2lsbCBiZSBoYXJkIGZvciBkZXBsb3ltZW50IGFuZCBzaGFy ZWQga2V5cyBhcmUgY2VydGFpbmx5IG5vdCBhbiBvcHRpb24gZm9yIElhYVMgc2NlbmFyaW8uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhcnRpY3VsYXJseSBpbiByZWxhdGlvbiB0byBsb2FkIGJh bGFuY2VyIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBjYXNlczo8bzpwPjwvbzpwPjwvcD4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEg bGZvNCI+Q29ubmVjdGlvbiByZW1haW5zIG9uIHRoZSBzYW1lIDQtdHVwbGUgZm9yIGl0cyBsaWZl dGltZS4gSGVyZSB0b2RheeKAmXMgdW5tb2RpZmllZCBsb2FkIGJhbGFuY2VycyBqdXN0IHdvcmsg c2luY2UgdGhleSBoYXNoIG9uIDItIG9yIDQtdHVwbGUgKFVEUC9JUCkuDQo8bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwzIGxldmVsMSBsZm80Ij5OQVQgcmViaW5kaW5nLiBGb3IgdGhpcyBsb2FkIGJhbGFu Y2VyIG5lZWRzIHRvIGhhc2ggYmFzZWQgb24gQ0lEIGFuZCBub3QgNC10dXBsZS4gU28gdGhlcmUg bmVlZHMgdG8gYmUgUVVJQyAodmVyc2lvbiBzcGVjaWZpYykgYXdhcmVuZXNzLiBOb3QgYSBkZWFs IGJyZWFrZXIgYW5kIHNlZW1zIGRvYWJsZS4gQnV0IGl0DQogZG9lcyBpbXBseSB0aGF0IHNlcnZl ciB3aWxsIGFsd2F5cyBoYXZlIHRvIGZvcmNlIGluY2x1c2lvbiBvZiBDSUQgZnJvbSBjbGllbnQu IDxvOnA+DQo8L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+Q29ubmVjdGlvbiBtaWdyYXRp b24uIFRoaXMgaXMgY29tcGxpY2F0ZWQgYmVjYXVzZSBpdCBzZWVtcyB0byByZXF1aXJlIHRoZSBz ZXJ2ZXIgdG8gcGljayBhIG5ldyBjb25uZWN0aW9uIElEIHN1Y2ggdGhhdCBsb2FkIGJhbGFuY2Vy IHdpbGwgcGljayB0aGUgc2FtZSBzZXJ2ZXIgYWdhaW4uIFRoaXMgY291cGxpbmcNCiB3aWxsIGJl IHByb2JsZW1hdGljIGluIElhYVMgc2NlbmFyaW8gd2hlcmUgdGhlIGxvYWQgYmFsYW5jZXIgbWF5 IGJlIG93bmVkIGJ5IHRoZSBjbG91ZCBwcm92aWRlciBhbmQgdGhlIGJhY2tlbmQgc2VydmVyIHRl cm1pbmF0aW5nIFFVSUMgb3duZWQgYnkgYSB0ZW5hbnQuIEZvciB0aGlzIHJlYXNvbiBpdCBzZWVt cyB0byBtZSB0aGF0IHRvIHN1cHBvcnQgY29ubmVjdGlvbiBtaWdyYXRpb24gd2UgbmVlZCBhIHN0 YW5kYXJkIGxvYWQgYmFsYW5jaW5nDQogc2NoZW1lIGRlZmluZWQgaW4gYSDigJxkZXBsb3ltZW50 IGlzc3Vlc+KAnSBzZWN0aW9uIGluIHRoZSBSRkMuIEFtIEkgbWlzc2luZyBzb21ldGhpbmc/PG86 cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHByZWZlcmVuY2UgZm9yIENJRCBpcyBzdGls bCA2NC1iaXQgc2luY2Ugd2UgaGF2ZSBnb25lIG91dCBvZiBvdXIgd2F5IHRvIHNhdmUgc3BhY2Ug aW4gdGhlIGhlYWRlcnMgdXNpbmcgVkxFIGJ1dCAxMjgtYml0IGlzIG5vdCBhIGRlYWwgYnJlYWtl ci4gV2Ugc2hvdWxkIGFsc28gbGVhdmUgdGhlIGVuY29kaW5nIG9mIHRoZSBDSUQgdG8gdGhlIHNl cnZlciByYXRoZXIgdGhhbiBzcGVjaWZ5IGFueSBwYXJ0aWN1bGFyDQogc2NoZW1lIGJ1dCBzcGVj aWZ5aW5nIHdoYXQgbG9hZCBiYWxhbmNlcnMgc2hvdWxkIGRvIHNlZW1zIGltcG9ydGFudCBmb3Ig c3VwcG9ydGluZyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+ U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAxMiwgMjAxOCA4OjU4IEFNPGJyPg0KPGI+VG86PC9i PiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IElhbiBTd2V0dCAm bHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc7 IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJFOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXplPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5JdCBjb3VsZCBhbHNvIGJlIGZpeGVkIDYyIGJpdCBjb25uZWN0aW9uIGlk ZW50aWZpZXIgYW5kIDIgbXNnIG9mIHRoZSBmaXJzdCBDSUQgYnl0ZSBzdG9yZXMgdGhlIGFkZGl0 aW9uYWwgbGVuZ3RoLiBUaGUgcmVxdWlyZW1lbnQgaXMgdGhlbiB0aGF0IHRoZSBmaXJzdCA2MiBi aXRzIG11c3QgaGF2ZQ0KIOKAnGVub3VnaCBlbnRyb3B54oCdIGFuZCB0aGUgcmVtYWluaW5nIGJp dHMgYXJlIGFwcGxpY2F0aW9uIG9yIGRlcGxveW1lbnQgc3BlY2lmaWMuIFRoaXMgd2lsbCBmb3Jj ZSByb3V0ZXJzIHRvIHN1cHBvcnQgMTI4LWJpdHMsIGJ1dCBpdCB3aWxsIGFsbG93IHRoZW0gdG8g cmVxdWlyZSBpdCBpZiBzbyBkZXNpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5BIHJvdXRlciBuZWVkIG5vdCBiZSBjb25jZXJuZWQgd2l0aCB0aGUgdmFyaWFibGUgbGVu Z3RoIGFzcGVjdCBpZiB0aGUgUVVJQyBpbnZhcmlhbnQgZW5zdXJlcyB0aGF0IGEgcGFja2V0IGxl bmd0aCBpcyBhdCBsZWFzdCBsb25nIGVub3VnaCB0byByZWFkIDEyOCBiaXRzIGZyb20gQ0lEIHN0 YXJ0Lg0KIEl0IGNhbiBqdXN0IGFzc3VtZSB0aGUgbGVuZ3RoIGl0IGV4cGVjdHMgYW5kIHRoZW4g dmFsaWRhdGUgYXMgbmVlZGVkIHdpdGggYXV0aCB0YWcgb3IgbGVuZ3RoLCBvciBqdXN0IGFzc3Vt ZSBpdCBpcyBzYWZlIHVuZGVyIHRoZSBjb25kaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5JbiBhbGwgY2FzZXMgdGhlIFFVSUMgZW5kcG9pbnQgTVVTVCBpbmNsdWRl IHRoZSBDSUQgaW4gdGhlIGFkZGl0aW9uYWwgZGF0YSBhdXRoZW50aWNhdGlvbiB0byBlbnN1cmUg cm91dGluZyBkYXRhIGhhcyBub3QgYmVlbiB0YW1wZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+T25lIGNvdWxkIGFsc28gdGFrZSB0aGlzIGEgc3RlcCBmdXJ0aGVyIGFu ZCBzaG9ydGVuIHRoZSBmaXJzdCA2NCBiaXRzLCBidXQgdGhhdCBpcyBwcm9iYWJseSBhIHJhdHMg bmVzdDogMTYsIDMyLCA2NCwgMTI4IGJpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxNTc3NTczNTcyMTcxMDA4MCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTIgSmFudWFy eSAyMDE4IGF0IDE2LjUxLjE5LCBMdWJhc2hldiwgSWdvciAoPGEgaHJlZj0ibWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBwb2ludCBoZXJlIGlzIHRoYXQgaWYgMTI4LWJpdCBp cyBhbiBvcHRpb24gZnJvbSBWMSwgdGhlbiBhbGwgY2xpZW50cyB3aWxsIHN1cHBvcnQgaXQsIGFu ZCB0aGUgc2VydmVyIGNhbiBjaG9vc2UNCiB0byBhbHdheXMgdXNlIDEyOC1iaXQgY29ubmVjdGlv biBJRHMuJm5ic3A7IFRoZSBsb2FkIGJhbGFuY2VyIHRoZW4gY2FuIGJlIHN1cmUgdGhhdCB2YWxp ZCBjb25uZWN0aW9uIElEcyAoaW4gcGFja2V0cyBmZWF0dXJpbmcgc2VydmVyIGNvbm5lY3Rpb24g SUQpIGNhbiBvbmx5IGJlIDEyOC1iaXQuJm5ic3A7IElmIFYxIGRvZXMgbm90IGhhdmUgMTI4LWJp dCBzdXBwb3J0LCB0aGVuIHRoZSBzZXJ2ZXIgbXVzdCBkZXZlbG9wIGEgbGVzcyBzZWN1cmUgdmVy c2lvbiBvZg0KIHRoZSBjb25uZWN0aW9uIElEIHRvIGZpdCBpbnRvIDY0IGJpdHMsIGFuZCB0aGUg bG9hZCBiYWxhbmNlciBtdXN0IHRyZWF0IDY0LWJpdCBjb25uZWN0aW9uIElEcyBhcyBhY2NlcHRh YmxlLiZuYnNwOyBUaGVuLCB0aGVyZSBpcyBub3RoaW5nIHRvIHByZXZlbnQgYW4gYXR0YWNrZXIg ZnJvbSB1c2luZyA2NC1iaXQgY29ubmVjdGlvbiBJRHMsIGlmIHRoYXTigJlzIG1vcmUgY29udmVu aWVudCBmb3IgdGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDEyLCAyMDE4IDk6MzUgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1 YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1 YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpodWl0ZW1h QGh1aXRlbWEubmV0Ij4NCmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXplPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPkkgdGhpbmsgd2UnbGwgd2FudCBzdXBwb3J0IGZvciBib3RoIG5vIG1h dHRlciBob3cgd2UgZG8gdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+T24gRnJpLCBKYW4gMTIsIDIwMTggYXQgOToxMyBBTSwgTHViYXNoZXYsIElnb3Ig Jmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SWYgdGhlIDEyOC1iaXQgb3B0aW9uIGlzIG5vdCBpbiBWMSwgdGhlbiBpdCB3aWxsIGJlIHJlcXVp cmVkIGZvciB0aGUgMTI4LWJpdCBvcHRpb24gdG8gYmUgc2lnbmFsZWQNCiBpbiB0aGUgcGFja2V0 J3MgaW52YXJpYW50IHNlY3Rpb24gKGxpa2UgYSBiaXQgaW4gdGhlIDFzdCBieXRlKS4gT3RoZXJ3 aXNlLCB0aGUgdmVyeSBsb2FkIGJhbGFuY2VycyB0aGlzIGlzIGRlc2lnbmVkIGZvciB3aWxsIG5v dCBrbm93IHdoZXRoZXIgdGhlIGNvbm5lY3Rpb24gSUQgaGFzIDY0LSBvciAxMjgtYml0IGZvcm1h dC4gKEl0IHdvdWxkIG5lZWQgdG8gc3VwcG9ydCBib3RoLCBzaW5jZSB0aGVyZSB3b3VsZCBiZSBj bGllbnRzIHN0dWNrIGF0DQogVjEuKTxicj4NCjxicj4NCkluIGZhY3QsIHRoZSBzZWN1cml0eSBw cm9taXNlcyBvZiBoYXZpbmcgYSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgb3B0aW9uIChhbGxvd3Mg Zm9yIG1ha2luZyByb3V0aW5nIGluZm8gaGFyZGVyIHRvIGZvcmdlKSBhcmUgZ3JlYXRseSBkaW1p bmlzaGVkLCB3aGVuIGEgbG9hZCBiYWxhbmNlciBoYXMgdG8gc3VwcG9ydCA2NC1iaXQgY29ubmVj dGlvbiBJRHMgJnF1b3Q7Zm9yZXZlciZxdW90Oy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0gPGJyPg0KPGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbPGEgaHJlZj0ibWFpbHRvOmlh bnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9h Pl08YnI+DQo8Yj5SZWNlaXZlZDo8L2I+IEZyaWRheSwgMTIgSmFuIDIwMTgsIDg6NTlBTTxicj4N CjxiPlRvOjwvYj4gQ2hyaXN0aWFuIEh1aXRlbWEgWzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT5dPGJyPg0K PGI+Q0M6PC9iPiBJRVRGIFFVSUMgV0cgWzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT5dPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBJbmNyZWFzaW5nIFFVSUMgY29ubmVjdGlvbiBJRCBzaXplPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pkkgd291bGQgbGlrZSB0byBsZWF2ZSBRVUlDIG9wZW4gZm9yIGxvbmdlciBjb25uZWN0aW9uIElE cyBpbiBmdXR1cmUgdmVyc2lvbnMsIHNvIEknZCBsaWtlIHRvIHNwZWNpZnkgdGhlIGludmFyaWFu dHMNCiBpbiBzdWNoIGEgd2F5IHRoYXQgbG9uZ2VyIGNvbm5lY3Rpb24gSWRzIHdvdWxkbid0IHZp b2xhdGUgdGhlbShpZTogVmljdG9yJ3Mgc3VnZ2VzdGlvbiBvZiZuYnNwO+KAnG1pZGRsZWJveGVz IGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRv IGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLikgYnV0IEknbSByZWx1Y3RhbnQgdG8gaW5jbHVk ZSAxMjggYml0IGNvbm5lY3Rpb24gSURzIGluIHYxIGF0IHRoaXMgcG9pbnQuDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KSSB3b3VsZCBhbHNvIGVjaG8gQ2hyaXN0aWFuJ3Mgc2VudGltZW50IHRoYXQg dGhlIGluY3JlbWVudGFsIG92ZXJoZWFkIHN0YXJ0cyBiZWNvbWluZyBmYWlybHkgbGFyZ2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gVGh1 LCBKYW4gMTEsIDIwMTggYXQgOTo0NyBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9 Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0 ZW1hLm5ldDwvYT4mZ3Q7DQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2UgaGF2ZSBhIHByb3RvdHlwZSBpbXBs ZW1lbnRhdGlvbiBpbiBQaWNvcXVpYyBpbiB3aGljaCB0aGUgY29ubmVjdGlvbiBJRCBjYW4gYmUg c3BsaXQgc28gc29tZSBiaXRzIGFyZSByYW5kb20NCiBhbmQgc29tZSBiaXRzIGFyZSB1c2VkIGZv ciByb3V0aW5nIHRvIGEgc3BlY2lmaWMgc2VydmVyIC0tIHRoYW5rcyBJZ29yIGZvciB0aGF0LiBJ dCBtYWtlcyBmb3IgbmljZSBleHBlcmltZW50cywgYnV0IGl0IGlzIGEgZGVuaWFsIG9mIHNlcnZp Y2Ugd2FpdGluZyB0byBoYXBwZW4uIEZvciBleGFtcGxlLCBhdHRhY2tlcnMgY291bGQgc2V0IHRo ZSBiaXRzIGluIHN1Y2ggYSB3YXkgYXMgdG8gdGFyZ2V0IGEgc3BlY2lmaWMgc2VydmVyIGluIGEg cG9vbCwNCiBvciB0aGV5IGNvdWxkIGxlYXJuIHdoaWNoIGNvbm5lY3Rpb25zIGFyZSBvbiB0aGUg c2FtZSBzZXJ2ZXIgYW5kIHVzZSB0aGF0IGxhdGVyIGZvciBzb21lIGtpbmQgb2Ygc2FtZSBzZXJ2 ZXIgYXR0YWNrLiBJdCB3b3VsZCBiZSBiZXR0ZXIgaWYgdGhhdCBpbmZvcm1hdGlvbiB3YXMgbm90 IGluIGNsZWFyIHRleHQuIEluIGZhY3QsIHRoZSBwaWNvcXVpYyBpbXBsZW1lbnRhdGlvbiB1c2Ug YSBjYWxsYmFjayB0byBhc2sgZm9yIHRoZSBuZXcgdmFsdWUNCiAtLSBwcmVzdW1hYmx5IGZyb20g dGhlIHJvdXRlci4gVGhhdCBjYWxsYmFjayBjb3VsZCByZXR1cm4gYW55dGhpbmcsIGluY2x1ZGlu ZyBhbiBlbmNyeXB0ZWQgdmFsdWUuPGJyPg0KPGJyPg0KT24gdGhlIG90aGVyIGhhbmQsIGl0IGlz IG5vdCBjbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgZnVsbCBlbmNyeXB0aW9uLiBGb3IgZXhhbXBs ZSwgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB0aGF0IG5lZWRzIGEgY29ubmVjdGlvbiBJRCBjYW4g YXNrIGl0IGZyb20gdGhlIHJvdXRlci4gVGhlIHJvdXRlciBjb3VsZCBwaWNrIG9uZSBhdCByYW5k b20sIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIHByb3Blcmx5IGRvY3VtZW50ZWQgaW4gdGhlIHJvdXRp bmcgdGFibGVzDQogYW5kIHRoYXQgdGhlcmUgaXMgbm8gY29sbGlzaW9uLCBhbmQgdGhlbiBwYXNz IGl0IGJhY2sgdG8gdGhlIHNlcnZlci4gTm8gZW5jcnlwdGlvbiBuZWVkZWQsIGJ1dCBvZiBjb3Vy c2UgbG90cyBvZiBzdGF0ZS48YnI+DQo8YnI+DQpJZiB0aGUgcm91dGVyIGRvZXMgbm90IHdhbnQg dG8ga2VlcCB0aGUgc3RhdGUsIGl0IGNhbiBpbmRlZWQgY3JlYXRlIGEgY29ubmVjdGlvbiBJRCBi eSBlbmNyeXB0aW5nIGEgJmx0O25vbmNlLCBzZXJ2ZXItSUQmZ3Q7IHR1cGxlLiBCdXQgaXQgZG9l cyBub3QgZm9sbG93IHRoYXQgdGhlIGVuY3J5cHRpb24gbmVlZHMgdG8gYmUgMTI4IGJpdHMuIEZv ciBleGFtcGxlLCBpdCBjb3VsZCB1c2UgYSA2NCBiaXQgYWxnb3JpdGhtIGxpa2UgQmxvd2Zpc2gu DQo8YnI+DQo8YnI+DQpTbyBJIGFtIG5vdCBzdXJlIHRoYXQgd2UgYWN0dWFsbHkgbmVlZCB0byBj aGFuZ2UgdGhlIGxlbmd0aC4gQW5kIEkgYW0gYSBiaXQgY29uY2VybmVkIGJ5IHRoZSBpbmNyZW1l bnRhbCBvdmVyaGVhZCBpZiB0aGUgY29ubmVjdGlvbiBJRCBzdWRkZW5seSBiZWNvbWVzIHZlcnkg bGFyZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAxLzExLzIw MTggMjoyNSBQTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBpZD0ibV8yMzE5NTgwMDk4NTY2OTg0NTQ0bV80NDUy MjE0NjAxNTY3NTExMjI0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5BY3R1YWxseSwgb24gZW5jcnlwdGlvbiBvZiBjb25uZWN0aW9u IElELCB0aGlzIGlzIG5vdCBzbyBzaW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJtXzIzMTk1ODAwOTg1NjY5ODQ1NDRtXzQ0NTIyMTQ2MDE1Njc1MTEyMjRibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMzE5NTgw MDk4NTY2OTg0NTQ0bV80NDUyMjE0NjAxNTY3NTExMjI0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XZSBtdXN0IGFzc3VtZSB0aGVy ZSBpcyBvbmx5IGEgc2luZ2xlIGtleSBmb3IgbWFueSBjb25uZWN0aW9ucyBiZWNhdXNlIHRoZSBy b3V0ZXIgaXMgbm90IHBhcnQgb2YgYSBrZXkgZXhjaGFuZ2UuDQogVGhpcyB1bmlxdWUgdmFsdWUg b3IgY291bnRlciB1c2VkIGZvciBlbmNyeXB0aW5nIGEgc2luZ2xlIGJsb2NrIGNhbm5vdCBiZSB0 aGUgc2FtZSBmb3IgdHdvIGRpZmZlcmVudCBjb25uZWN0aW9ucyBJROKAmXMsIGJ1dCBpdCBjYW4g YmUgcHVibGljLiBUaGlzIG1lYW5zIHRoYXQgaXQgbXVzdCBiZSBzdG9yZWQgaW4gdGhlIHBhY2tl dCBoZWFkZXIuIEFuZCwgYXMgaXQgdHVybnMgb3V0LCByYW5kb20gY29ubmVjdGlvbiBJRCBjaG9z ZW4gYnkgYSB0cnVzdGVkDQogc291cmNlLCBjYW4gYmUgdXNlZCBmb3Igc3VjaCBhIHVuaXF1ZSB2 YWx1ZS4gQnV0IHRoZW4gaXQgbXVzdCBiZSB1c2VkIHRvIGVuY3J5cHQgYW5kL29yIGF1dGhlbnRp Y2F0ZSBzb21ldGhpbmcgZWxzZSBjYXJyeWluZyB0aGUgYWN0dWFsIHJvdXRpbmcgaW5mb3JtYXRp b24uIFNvIG5vdyB5b3Ugc3RhcnQgdG8gcmVhbGx5IG5lZWQgc29tZSBleHRyYSBwYXlsb2FkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMzE5NTgwMDk4NTY2OTg0 NTQ0bV80NDUyMjE0NjAxNTY3NTExMjI0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUx MTIyNGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+QWx0ZXJuYXRpdmVseSB0aGUgcm91dGluZyBpbmZvcm1hdGlvbiBpcyBlbnRpcmVs eSByYW5kb20gc3VjaCBhcyBjb250ZW50IGhhc2hlZCByb3V0aW5nLiBUaGVuIHlvdSBvbmx5IG5l ZWQgdG8NCiBhdXRoZW50aWNhdGUgdGhlIHJvdXRpbmcgZGF0YS4gWW91IGNhbiBkbyB0aGF0IHdp dGggYSBITUFDLCBhbmQgQ01BQyBjb3VsZCBwcm9iYWJseSBhbHNvIHdvcmsuIFRoZSBhZGRpdGlv bmFsIGJlbmVmaXQgaXMgdGhhdCB5b3UgY2FuIHByb2JhYmx5IGdldCBhd2F5IHdpdGggNjQtYml0 cyBmb3IgYWxsIHJvdXRpbmcgaW5mb3JtYXRpb24gcG9zc2libHkgaW5jbHVkaW5nIHRoZSBhdXRo IHRhZy4gU2F5IDQ4IGJpdHMgb2Ygcm91dGluZyBkYXRhIGFuZA0KIDE2IGJpdHMgb2YgYXV0aCB0 YWcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlk PSJtXzIzMTk1ODAwOTg1NjY5ODQ1NDRtXzQ0NTIyMTQ2MDE1Njc1MTEyMjRibG9vcF9zaWduXzE1 MTU3MTYxMzcyMDMzMzM4ODgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJtMjMxOTU4MDA5ODU2Njk4NDU0NG00NDUyMjE0NjAxNTY3NTEx MjI0YWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTIgSmFudWFyeSAyMDE4IGF0IDAw LjU3LjIxLCBMdWJhc2hldiwgSWdvciAoPGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20iIHRhcmdldD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIGludGVyZXN0ZWQgaW4gZXhwbG9yaW5nIHRo aXMgcHJvcG9zYWwsIHNpbmNlIGl0IGFsbG93cyBmb3IgbW9yZSBmbGV4aWJsZSBzY2hlbWVzIG9m IGVuY29kaW5nIHJvdXRpbmcgbWV0YWRhdGENCiBhbmQgYSBjaGVja3N1bS4mbmJzcDsgSSB3b3Vs ZCBhbHNvIGxpa2UgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZSBp biBhIHBhY2tldCBoZWFkZXIsIHRob3VnaCwgc2luY2UgaXQgZ3JlYXRseSBzaW1wbGlmaWVzIHRo ZSBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZ29yIDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+ PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+IFZpY3RvciBWYXNpbGlldiBbbWFpbHRvOjxh IGhyZWY9Im1haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj52YXNpbHZ2 QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDEx LCAyMDE4IDY6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6 ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgZXZlcnlvbmUsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGN1 cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUgY29ubmVjdGlvbiBJRCBzaXplIGlzIGZpeGVkIHRv IGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBhbmQgdGhhdCBpcyBzZXQgYXMNCiBhbiBpbnZhcmlh bnQgaW4gdGhlIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPknigJl2ZSBsb29rZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2luZyBh IGNvbm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBpbnRv IGl0ICh0byBwcm92aWRlDQogc3RhYmlsaXR5IG9mIHRoZSBjb25uZWN0aW9uIGluIGNhc2Ugb2Yg bG9hZCBiYWxhbmNpbmcgY2hhbmdlcywgZXNwZWNpYWxseSBCR1AgZmxhcHMgZm9yIGFueWNhc3Qg SVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkga25l dyB3ZXJlIGludGVyZXN0ZWQgaW4gdGhpcy4mbmJzcDsgSXQgc2VlbXMgbGlrZSA2NCBiaXRzIG1p Z2h0IGJlIHRvbyBzbWFsbCBmb3IgdGhpcyBwdXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudA0KIHRv IGxlYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBzaXplLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBi YXNpYyBpZGVhIGlzIHRoYXQgeW91IHdhbnQgdG8gYmUgYWJsZSB0bzo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+U3RvcmUgc29tZSByb3V0aW5nIG1ldGFkYXRhIGluIHRoZSBjb25uZWN0aW9uIElELg0KPG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxl dmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IYXZlIHNvbWUgZW50cm9weSB0aGF0IGFs bG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50aWNhbCByb3V0aW5nIG1ldGFkYXRhLg0K PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omwx IGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IYXZlIGEgY2hlY2tzdW0gdG8gZW5z dXJlIHRoZSB2YWxpZGl0eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uDQo8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkVuY3J5cHQgdGhlIGluZm9ybWF0aW9uIGFib3ZlIHRvIHByZXZl bnQgZGlzY2xvc2luZyB0aGUgcm91dGUgaW5mb3JtYXRpb24gYW5kIGFsbG93IGdlbmVyYXRpbmcg dW5jb3JyZWxhdGFibGUgY29ubmVjdGlvbiBJRHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwv b2w+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5UaGVyZSBhcmUgdHdvIHVuZGVybHlpbmcgaXNzdWVzIGhlcmUuJm5ic3A7IFRoZSBmaXJz dCBwcm9ibGVtIGlzIHRoYXQgYWxsIG9mIHRoaXMgZG9lcyBub3QgZml0IHdlbGwgaW50byA2NCBi aXRzLCBhbmQNCiB5b3UgaGF2ZSB0byBzZXJpb3VzbHkgY29tcHJvbWlzZSBvbiB0aGUgc3RyZW5n dGggb2YgdGhlIGNoZWNrc3VtICh3aGljaCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ugd2FudCBp dCB0byBiZSBhIE1BQyByYXRoZXIgdGhhbiBhIGNoZWNrc3VtKS4mbmJzcDsgVGhlIHNlY29uZCBw cm9ibGVtIGlzIHRoYXQgZW5jcnlwdGluZyA2NC1iaXQgdmFsdWVzIGZhc3QgaXMgYWN0dWFsbHkg ZmFpcmx5IGhhcmQgc2luY2UgdGhlIGJsb2NrIGNpcGhlcnMgZWFzaWx5IGF2YWlsYWJsZQ0KIGlu IGhhcmR3YXJlIGhhdmUgMTI4LWJpdCBibG9jayBzaXplLCBhbmQgdGhlIHBlcmZvcm1hbmNlIHJl cXVpcmVtZW50cyBvbiBsb2FkIGJhbGFuY2VycyBhcmUgdGlnaHRlciB0aGFuIG9uIHNlcnZlcnMu Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+SW4gb3RoZXIgd29yZHMsIGhhdmluZyBhIDEyOC1iaXQgY29ubmVjdGlvbiBJRCBw cm92aWRlcyBmb3IgYW4gZWFzeSBzZWN1cmUgd2F5IHRvIGdlbmVyYXRlIHVubGlua2FibGUgY29u bmVjdGlvbg0KIElEcyBvbiBtaWdyYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U28sIHRoZSBwcm9ibGVtIHdl4oCZcmUgdHJ5aW5nIHRv IHNvbHZlIGlzIHRoYXQgdGhlIGNvbm5lY3Rpb24gSUQgaXMgdG9vIHNtYWxsLiZuYnNwOyBUaGVy ZSBhcmUgdHdvIHF1ZXN0aW9ucyBJIGJlbGlldmUNCiB0aGUgd29ya2luZyBncm91cCBzaG91bGQg YW5zd2VyIGF0IHRoaXMgcG9pbnQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRvIHdlIHdhbnQgdG8gYWRk cmVzcyB0aGlzIHByb2JsZW0gYXQgdGhpcyBwb2ludCBpbiBzdGFuZGFyZGl6YXRpb24gcHJvY2Vz cz8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMiBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgd2UgZG9u4oCZdCBhZGRy ZXNzIHRoaXMgcHJvYmxlbSByaWdodCBub3csIGhvdyBkbyB3ZSBzdHJ1Y3R1cmUgdGhlIHN0YW5k YXJkIGluIGEgd2F5IHRoYXQgd2UgY2FuIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJRCBpbiB0aGUg ZnV0dXJlPw0KPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlcmUgYXJlIG11bHRpcGxl IHdheXMgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgbWFraW5nIGNvbm5lY3Rpb24gSUQgbGFyZ2Vy LiZuYnNwOyBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEgYml0IHRvIHRoZQ0KIOKAnG9taXQgY29u bmVjdGlvbiBJROKAnSBmaWVsZCB0byBhbGxvdyAxMjgtYml0IGNvbm5lY3Rpb24gSURzLiZuYnNw OyBBbm90aGVyIGFwcHJvYWNoIGlzIHRvIGFsbG93IGNvbm5lY3Rpb24gSUQgc2l6ZSB0byBiZSBl eHBsaWNpdGx5IHNwZWNpZmllZCBieSB0aGUgc2VydmVyLCBhbmQgdGhlbiBhc3N1bWUgdGhhdCB0 aGUgbG9hZCBiYWxhbmNlciBrbm93cyB0aGF0IHNpemUgYW5kIG5vIG9uZSBlbHNlIG9uIHRoZSBw YXRoIG5lZWRzIHRvIHJlYWQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhlcmXigJlzIGFsc28gYSBxdWVzdGlvbiBvZiBob3cgbXVjaCBv ZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVib3hlcyAoZXhjbHVkaW5nIGxvYWQgYmFsYW5jZXJz IGFuZCBvdGhlciBib3hlcw0KIG93bmVkIGJ5IHRoZSBzYW1lIGVudGl0eSBhcyBlaXRoZXIgY2xp ZW50IG9yIHNlcnZlcikgbmVlZCB0byBrbm93LiZuYnNwOyBXZSBjb3VsZCBnbyBmb3IgYm90aCDi gJxtaWRkbGVib3hlcyBzaG91bGQgYmUgYWx3YXlzIGFibGUgdG8gcmVhZCB0aGUgZW50aXJlIElE 4oCdIGFuZCDigJxtaWRkbGVib3hlcyBzaG91bGQgbm90IHJlYWQgY29ubmVjdGlvbiBJRHMgYXQg YWxsIG9wdGlvbnPigJ0sIGJ1dCBJIHRoaW5rIHRoZXJl4oCZcyBhbHNvIGEgcm9vbSBmb3IgbW9y ZSBmbGV4aWJsZQ0KIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1pZGRsZWJveGVzIGFsd2F5cyBnZXQg Zmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5IHRvIGRpc3Rpbmd1aXNo IGNvbm5lY3Rpb25z4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOyAtLSBWaWN0b3IuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_CY4PR21MB01331A05F3F44C335FF78156B6170CY4PR21MB0133namp_-- From nobody Fri Jan 12 10:01:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E6F12D871 for ; Fri, 12 Jan 2018 10:01:46 -0800 (PST) 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=QOOOdHIO; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=aQzHsiDC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFX_hdxs7nxo for ; Fri, 12 Jan 2018 10:01:44 -0800 (PST) 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 A947912D87A for ; Fri, 12 Jan 2018 10:01:42 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0CI0VQO016304; Fri, 12 Jan 2018 10:01:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=Gcm1g9ZdxiSiUwOmpW9PjgyxG+eEhL8dWRL1dDhyRdc=; b=QOOOdHIO3it4E5fSON1u1F2P6swyDWqFTmPEpNd4aoPWtODY1SYu5SkToVlEe3GsiimA KqnsT3gxP/yS3pVuk8VK1Ur7pxsohV9rD91q0GP/DlK9EUHhx24ylNUkgpinSSi/tCma iwH9OenlSnXT0aVk0WC7FOn0Bcv8cWkZYNU= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fereat3bv-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jan 2018 10:01:38 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 12 Jan 2018 13:01:36 -0500 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=Gcm1g9ZdxiSiUwOmpW9PjgyxG+eEhL8dWRL1dDhyRdc=; b=aQzHsiDCYcNy2hltcqt4dt0ppeneiZpTowr1A/Ubec8a+UuyGYhw1G8pecqBDjS5QhuaLu8URABf6JwNDKxoOC/KqTNR8C9/Ief2AYDChLf/NOtc3IRU+ozPzG80lsqVSlaAKP/U1TgeS3igH0TZvkm8R0BFT+Jh/+TOydQCqDA= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.366.8; Fri, 12 Jan 2018 18:01:16 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 18:01:16 +0000 From: Roberto Peon To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Thomson CC: Jana Iyengar , QUIC WG , "Charles 'Buck' Krasic" Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNsqpwAgAC3uoCAAB3vgIAAA6iAgAAEuYCAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADWgIACtUUA//+auwA= Date: Fri, 12 Jan 2018 18:01:16 +0000 Message-ID: <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:6ba8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2191; 7:sMGokbWdRB6BdI809BI2/zpPoIljZWMvnViCVCY/Ggx7NJUsY0P2Mf6me2PTSw6j550aEu4LEkvq0rLytU47DY3Tlhkm7MgCHPACUuMwX1tuCQpoXe3MBEEcftAP3zGbof9KULqFhxM1fjNCioiVHR3TbUwncPr/qtGIiuFOXqygCrfNU3rtg9bNJlrKSRg9ml1T6CyM2pVckGMCPy9007NSqLZGZ3xk1jzfD/1FNekCDkERLuP0ee5gop6d3Shw; 20:PStqKGzY+aS4Zxzsh88anKdKXWB8sZCzD0mUH98NRIxOVYejVIiG7vT0Gr9NwHwLJ6XztT8qNcPohqyecPYn6GVBmulWrXZRFKJT1RiCM5cY4aijjjYz2m0xnWd6k1rQSDij5X0Rph+vhANeRZPkXqcFVKtlnTCNOLXdnYlaFZE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7a5164bf-bbcd-436e-5301-08d559e679c4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020085)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2191; x-ms-traffictypediagnostic: SN6PR1501MB2191: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(8121501046)(5005006)(3002001)(3231023)(11241501184)(944501146)(93006095)(93001095)(10201501046)(6041268)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR1501MB2191; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2191; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(366004)(376002)(396003)(189003)(199004)(24454002)(51444003)(97736004)(25786009)(4326008)(81166006)(3480700004)(68736007)(39060400002)(8676002)(5250100002)(81156014)(6246003)(8936002)(3660700001)(82746002)(106356001)(105586002)(316002)(6486002)(229853002)(93886005)(2900100001)(6116002)(6506007)(33656002)(102836004)(54906003)(53936002)(6512007)(86362001)(14454004)(53546011)(76176011)(83716003)(3280700002)(36756003)(99286004)(305945005)(2950100002)(110136005)(6346003)(7736002)(6436002)(2906002)(478600001)(5660300001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2191; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:3; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LQlko2PGzLQIl4xuZlChIjUVkvSivt6Wbb7r+2fClSMrGtntNxpkRzJdbmU62rScXZpr3VvOMVRureNewKVULw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7a5164bf-bbcd-436e-5301-08d559e679c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 18:01:16.1959 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2191 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 18:01:46 -0000 VGhlIHRyYW5zcG9ydCAqQ0FOTk9UKiBwcm92aWRlIG9yZGVyaW5nIGd1YXJhbnRlZXMgdy5yLnQu IHByaW9yaXRpemF0aW9uIGJlY2F1c2UgZmxvd3MgYXJlIGVuZC10by1lbmQsIHdoZXJlYXMgY29u bmVjdGlvbnMgYXJlIHBvaW50IHRvIHBvaW50Lg0KRmxvdy1jb250cm9sLCBiZWluZyBhIHByb3Bl cnR5IG9mIGZsb3dzLCBlbmRzIHVwIGJlaW5nIGFzc2VydGVkIGVuZC10by1lbmQgdGhvdWdoIHRo ZSBtZWNoYW5pc20gYXQgZWFjaCBob3AgaXMgcG9pbnQtdG8tcG9pbnQuDQoNCkNvbnNpZGVyIHRo ZSDigJhzdGFuZGFyZOKAmSBjbGllbnQtPnByb3h5LT5zZXJ2ZXIgdG9wb2xvZ3kuDQpJZiB0aGUg c2VydmVyIGFzc2VydHMgZmxvdyBjb250cm9sLCB0aGUgcHJveHkgbXVzdCByZXNwZWN0IGl0LiAN CkFzIHRoZSBjbGllbnQ8LT5wcm94eSBob3AgaXMgYXN5bmNocm9ub3VzIGZyb20gdGhlIHByb3h5 PC0+c2VydmVyIGhvcCBpbiBtb3N0IGNpcmN1bXN0YW5jZXMgd2l0aCBhIGxvYWRiYWxhbmNpbmcg KGkuZS4gc2hhcmVkIGZsb3cpIHByb3h5LCB0aGUgcHJveHkgY2Fubm90IGd1YXJhbnRlZSBmbG93 LWNvbnRyb2wgd2luZG93IHdpbGwgYmUgYXZhaWxhYmxlIGZvciBzZW5kaW5nIHRvIHRoZSBzZXJ2 ZXIgZXZlbiB3aGVuIGZsb3cgY29udHJvbCB3aW5kb3cgaXMgYXZhaWxhYmxlIGZyb20gdGhlIGNs aWVudDwtPnByb3h5Lg0KDQpQcmVlbXB0aW9uL2NhbmNlbGxhdGlvbi9yZXRyeSwgdGhlIGFkZGl0 aW9uIG9mIG1vcmUgcmVzb3VyY2VzLCBvciBmaW5lciBtYW5hZ2VtZW50IG9mIHJlc291cmNlcyBj YW4gYmUgdXNlZCB0byByZXNvbHZlIHRoZSAodHJhbnNpdGl2ZSkgZGVhZGxvY2suDQoNCg0KVGhl IHN1Yi1jYXNlIG9mIGNvbXByZXNzaW9uIG1heSBiZSBzb2x2YWJsZSB3aXRob3V0IHNvbHZpbmcg dGhlIGdlbmVyYWwgY2FzZSBhcyBjb21wcmVzc2lvbiBpcyBwb2ludC10by1wb2ludC4NCi09Ug0K DQoNCk9uIDEvMTIvMTgsIDg6MDQgQU0sICJRVUlDIG9uIGJlaGFsZiBvZiBNaXJqYSBLw7xobGV3 aW5kIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoPiB3cm90ZToNCg0KICAgIEkgZGlzYWdyZWUuIEkgdGhpbmsgaXQgY2Fu IGJlIGdvb2QgdG8gcHJvdmlkZSB0aGUgdHJhbnNwb3J0IGhpbnRzIGFib3V0IGRlcGVuZGVuY2ll cyBpbiBhcHBsaWNhdGlvbiBkYXRhIHdoaWNoIHRoZW4gY291bGQgYmUgdXNlZCBieSB0aGUgdHJh bnNwb3J0IHRvIG9wdGltaXplIHRoZSBzZW50LW91dCBzY2hlZHVsaW5nLCBidXQgSSBkb27igJl0 IHRoaW5rIHRoZSB0cmFuc3BvcnQgc2hvdWxkIHByb3ZpZGUgZ3VhcmFudGVlcyBmb3Igb3JkZXJl ZCBwcm9jZXNzaW5nIGJldHdlZW4gc3RyZWFtcy4gRm9yIG1lIHRoZSB3aG9sZSBwb2ludCBvZiBo YXZpbmcgc3RyZWFtcyBpbiB0aGUgdHJhbnNwb3J0IGlzIHRvIHJlc29sdmUgZGVwZW5kZW5jaWVz IGJldHdlZW4gaW5kZXBlbmRlbnQgZGF0YS4NCiAgICANCiAgICBUaGVyZWZvcmUsIEkgdGhpbmsg aXQgd291bGQgcHJvYmFibHkgYmUgZ29vZCB0byBtZW50aW9uIHRoaXMgZGVhZGxvY2sgcHJvYmxl bSBpbiB0aGUgbWFpbiBkcmFmdCBidXQgSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCBhZGQgc3Ry aWN0IHByaW9yaXRpZXMgYXMgYSB0cmFuc3BvcnQgZmVhdHVyZSB0byBRVUlDLiBUaGVyZSBhcmUg c2V2ZXJhbCB3YXlzIGhvdyBhbiBhcHBsaWNhdGlvbiBjYW4gYXZvaWQgKGRvbuKAmXQgaGF2ZSBk ZXBlbmRlbmNpZXMgYnkgdXNpbmcgdGhlIHNhbWUgc3RyZWFtIGZvciBkZXBlbmRlbnQgZGF0YSBv ciB3YWl0IHVudGlsIGRhdGEgaGFzIGJlIHNlbnQgYmVmb3JlIHNlbmRpbmcgZGVwZW5kZW50IGRh dGEpIG9yIHJlc29sdmUgKHJlYWQgYWxsIHN0cmVhbXMgYW5kIGltcGxlbWVudCBhbiBhZGRpdGlv bmFsIGFwcGxpY2F0aW9uIGxheWVyIGJ1ZmZlcikgc3VjaCBhIGRlYWRsb2NrIGFuZCB0aGVzZSBz aG91bGQgYmUgZXhwbGFpbmVkIGluIHRoZSBhcHBsaWNhYmlsaXR5IGRvY3VtZW50IHJlc3BlY3Rp dmVseS4NCiAgICANCiAgICBNeSAyYywNCiAgICBNaXJqYQ0KICAgIA0KICAgIA0KICAgID4gQW0g MTAuMDEuMjAxOCB1bSAyMzo0MiBzY2hyaWViIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+Og0KICAgID4gDQogICAgPiBPbiBUaHUsIEphbiAxMSwgMjAxOCBhdCA5OjM5 IEFNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPiB3cm90ZToNCiAgICA+PiBZZXMsIEkg dGhpbmsgdGhlcmUncyBlYXN5IG1pc2ludGVycHJldGF0aW9uIGhlcmUgLS0gc29tZXRoaW5nIEkg cmVhbGl6ZWQNCiAgICA+PiB0b2RheSBhcyBJJ3ZlIGhhZCBjb252ZXJzYXRpb25zIGFib3V0IHRo aXMuIFdoYXQgSSBtZWFudCB3YXMgc3BlY2lmaWNhbGx5IGF0DQogICAgPj4gdGhlIEFQSSBiZXR3 ZWVuIHRoZSBhcHAgYW5kIHRoZSB0cmFuc3BvcnQsIGF0IHRoZSBzZW5kZXIuIFRoaXMgaXMgYmFz aWNhbGx5DQogICAgPj4gc2F5aW5nIHRoYXQgdG8gYXZvaWQgZGVhZGxvY2sgZHVlIHRvIGRlcGVu ZGVuY2llcyBhY3Jvc3Mgc3RyZWFtcywgdGhlDQogICAgPj4gdHJhbnNwb3J0IHdyaXRlIEFQSSBt dXN0IGFsbG93IHRoZSBhcHAgdG8gZXhwcmVzcyBzdHJpY3QgcHJpb3JpdGllcy4NCiAgICA+IA0K ICAgID4gQWhoLCBleGNlbGxlbnQsIHRoZW4gSSB0aGluayBhdCBsZWFzdCB3ZSB0d28gYXJlIGlu IGFncmVlbWVudC4gIEl0DQogICAgPiBzZWVtcyBsaWtlIHRoZXJlIGlzIGFuIGVtZXJnaW5nIGFj Y2VwdGFuY2Ugb2YgdGhlIHByb2JsZW0gYW5kIHByb3Bvc2VkDQogICAgPiBhcHByb2FjaCwgSSBn dWVzcyB3ZSBtaWdodCBzdGFydCBjb25zaWRlcmluZyBob3cgdG8gYWRkcmVzcyBpdC4NCiAgICA+ IA0KICAgID4gSSB0aGluayB0aGF0IHRoaXMgbmVlZHMgdG8gYmUgaW4gdGhlIG1haW4gc3BlYy4g IEZhaWxpbmcgdG8gZG9jdW1lbnQNCiAgICA+IHRoaXMgc29ydCBvZiBwaXRmYWxsIGNvdWxkIGJl IGZhdGFsLiAgRG9lcyBhbnlvbmUgZGlzYWdyZWU/DQogICAgPiANCiAgICANCiAgICANCg0K From nobody Fri Jan 12 10:53:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09FF0127201 for ; Fri, 12 Jan 2018 10:53:20 -0800 (PST) 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=mtAemNNm; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=RIHhhbQB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-eJ-k1rDGLd for ; Fri, 12 Jan 2018 10:53:16 -0800 (PST) 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 82E02126D0C for ; Fri, 12 Jan 2018 10:53:16 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0CIpNqk018964; Fri, 12 Jan 2018 10:53:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=S8n2I15v2SFbPUcSQ7rbElMJwQhUW5PJR2bG7a5R5b4=; b=mtAemNNm0iELU4MYVH9KtD5Kdw2c/1WSMoH5w5AALvvFACdoAWvopiko9diLmVckAQOo VQQOvd9z5cy0TwT5dCtSO6vC7jEC+cnRNP0NuxI6ap1C8BPSxzaQvtBIi8w+HovA+ImO k1OF8BQg7oyLBXfk5pZwDeDMYNUrOXdXBhA= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fex7ch54m-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jan 2018 10:53:12 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 12 Jan 2018 10:53:11 -0800 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=S8n2I15v2SFbPUcSQ7rbElMJwQhUW5PJR2bG7a5R5b4=; b=RIHhhbQB5qYTgsX/iPE7+pVgQB9fwxsjRUWy+icThkr4UHEcLEMnrZgl4ZI6sQxUYpxipEI/AhiTGoj3OBGny5WgDmvebrQZlV2mKC6lYpm4TVpp4BmPyQvER8es+McCIJoOPYZrfAplIjplJhXRVnzf/dMobA+X8Cgq8mAB9Nw= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2190.namprd15.prod.outlook.com (52.132.120.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 18:53:02 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 18:53:02 +0000 From: Roberto Peon To: "Lubashev, Igor" , Jana Iyengar CC: QUIC WG , Martin Thomson Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNtCOaAgAJivQD//3yugIAAjUGAgAEj3RI= Date: Fri, 12 Jan 2018 18:53:02 +0000 Message-ID: References: <18061ACE-08F7-4219-81E6-0B73BBC56170@fb.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:63ef] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2190; 20:orcnb0MHaMLlxMGo5EIfZC30LNNQr5vtIQSasGpfc0bZCSASVc7BU2xvz9fU3w0rWzxx5pn3tLfxiMrIufJX3PC7XMafZXW5xI3Etimbnp80eXaul/171UZIH131+2mBA2/dKRyDSBh0kefkBACQ00fmoyCyg9W7Keeg231C3lc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1bb0dc16-fb8b-45b9-c63d-08d559edb541 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020085)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2190; x-ms-traffictypediagnostic: SN6PR1501MB2190: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(85827821059158)(67672495146484)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(11241501184)(944501146)(93006095)(93001095)(10201501046)(3002001)(6041268)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:SN6PR1501MB2190; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2190; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(346002)(376002)(366004)(24454002)(199004)(54094003)(189003)(8936002)(5250100002)(86362001)(8676002)(54896002)(110136005)(2906002)(6436002)(55016002)(3480700004)(54906003)(14454004)(59450400001)(316002)(93886005)(53546011)(6506007)(102836004)(236005)(76176011)(74316002)(9686003)(81156014)(7696005)(53936002)(81166006)(2900100001)(6116002)(68736007)(7736002)(229853002)(3660700001)(99286004)(106356001)(33656002)(105586002)(97736004)(5660300001)(478600001)(39060400002)(6246003)(4326008)(25786009)(3280700002)(2950100002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2190; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: n/XKylHx2VWk1P45buZT5WxurWm/7s0X1AdOljCbeOmDmzwbW+2Y0z+rn6bvTI7QV3RmLJLDf0gbxRjRvKOYrg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR1501MB2191934520466DD727CA0BDCCD170SN6PR1501MB2191_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1bb0dc16-fb8b-45b9-c63d-08d559edb541 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 18:53:02.4494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2190 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 18:53:20 -0000 --_000_SN6PR1501MB2191934520466DD727CA0BDCCD170SN6PR1501MB2191_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm talking about this in the context of e2e application-level deadlocks. If we simply increase the global flow control window when things are blocke= d , the wrong stream may make forward progress; there is no way to indicate= a particular stream should make forward progress. This may be ok-- The standard way this is resolved today is a timeout, erro= r, and retry. Since detecting and resolving all of these races is not reasonably solvable= , this (timeout, retry) is the ultimate mechanism for any application to re= solve issues anyway. Imho, the 'blocked on flow control' message, if reliably sent by blocked se= nders, will give info on shared-resource (i.e. proxy-> server) deadlocks, a= nd thus better inform actors' timeouts. -=3DR Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: "Lubashev, Igor" Date: 1/11/18 5:28 PM (GMT-08:00) To: Roberto Peon , Jana Iyengar Cc: QUIC WG , Martin Thomson Subject: RE: Deadlocking in the transport Transport cannot solve the problem of deadlocking due to a higher protocol= =92s data priority on its own. The application would need to cooperate car= efully. The problem is that it is not only the receiver that is influencing flow co= ntrol, because sender transport has buffers as well. The sender transport = can refuse to accept higher-priority data from the application, if its buff= ers are already full with lower-priority data. So you can end up with receiver refusing to grant additional credits for st= ream Y (because it cannot process stream Y w/o stream X). If the sender=92= s buffers are full of stream Y data, it cannot send that data and cannot ac= cept any additional data (for stream X). The application must be careful not to enqueue stream Y data to the transpo= rt before it enqueues all data from stream X that stream Y data depends on. * Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Thursday, January 11, 2018 8:03 PM To: Jana Iyengar Cc: QUIC WG ; Martin Thomson Subject: Re: Deadlocking in the transport The receiver would be the one to provide the override; The sender could hin= t to the receiver that it should wish this by signaling it is blocked (or d= eadlocked) on flow control. -=3DR From: Jana Iyengar > Date: Thursday, January 11, 2018 at 4:53 PM To: Roberto Peon > Cc: Martin Thomson >, QUIC WG > Subject: Re: Deadlocking in the transport Roberto, I'm not convinced that we need something as heavy-weight as this... specifi= cally, flow control so far has been in the receiver's control, which is als= o the thing that owns the resource it is trying to limit exhaustion of. Thi= s moves it out to the sender, which would require a receiver to now commit = memory based on what a sender believes is important. Reasoning about this s= eems non-trivial. I worry about how all this degree of freedom will get abu= sed, and potential sharp edges. If we can ensure priority consumption of the shared resource, that seems ad= equate to resolve the problem on hand. Do you think something more is requi= red? - jana On Wed, Jan 10, 2018 at 12:26 PM, Roberto Peon > wrote: Another option: Allow a flow-control =91override=92 which allows a receiver to state that t= hey really want data on a particular stream, and ignore the global flow con= trol for this. How you=92d do it: A receiver can send a flow-control override for a stream. This includes the= stream id to which the global window temporarily does not apply, the recei= ver=92s current stream flow-control offset, and the offset the receiver wou= ld wish to be able to receive. A receiver must continue to (re)send the override (i.e. rexmit) until it is= ack=92d. It cannot send other flow-control for that stream until the overr= ide is ack=92d. Thus: global-flow-control-override: , = The sender (which receives the override) credits the global flow control wi= th the difference between the data sent beyond the receivers currently-know= n flow-control offset upon receipt of the override. This synchronizes the global state between the receiver and the sender. The sender can then send the data on the stream (without touching any other= flow control data). Why: This allows for a receiver to resolve priority inversions which would other= wise lead to deadlock, even when the data/dep leading to this was not known= to the transport. This extends beyond such issues beyond just header compr= ession. Since the global flow-control exists to protect the app from resource exhau= stion, this poses no additional risk to the application. Simply increasing the global flow control provides less strong guarantees= =97any stream might consume it, which doesn=92t resolve the dep inversion. = Rejiggering priorities can help to resolve this, but would require the send= er to send priorities to the client, which is problematic w.r.t.races and j= ust a web of ick. Having a custom frame type is also a less strong guarantee as it requires t= he knowledge that the dep exists to be present at the time of sending, whic= h is often impossible. -=3DR On 1/9/18, 10:17 PM, "QUIC on behalf of Martin Thomson" on behalf of martin.thomson@gmail.com> wrote: Building a complex application protocol on top of QUIC continues to produce surprises. Today in the header compression design team meeting we discussed a deadlocking issue that I think warrants sharing with the larger group. This has implications for how people build a QUIC transport layer. It might need changes to the API that is exposed by that layer. This isn't really that new, but I don't think we've properly addressed the problem. ## The Basic Problem If a protocol creates a dependency between streams, there is a potential for flow control to deadlock. Say that I send X on stream 3 and Y on stream 7. Processing Y requires that X is processed first. X cannot be sent due to flow control but Y is sent. This is always possible even if X is appropriately prioritized. The receiver then leaves Y in its receive buffer until X is received. The receiver cannot give flow control credit for consuming Y because it can't consume Y until X is sent. But the sender needs flow control credit to send X. We are deadlocked. It doesn't matter whether the stream or connection flow control is causing the problem, either produces the same result. (To give some background on this, we were considering a preface to header blocks that identified the header table state that was necessary to process the header block. This would allow for concurrent population of the header table and sending message that depended on the header table state that is under construction. A receiver would read the identifier and then leave the remainder of the header block in the receive buffer until the header table was ready.) ## Options It seems like there are a few decent options for managing this. These are what occurred to me (there are almost certainly more options): 1. Don't do that. We might concede in this case that seeking the incremental improvement to compression efficiency isn't worth the risk. That is, we might make a general statement that this sort of inter-stream blocking is a bad idea. 2. Force receivers to consume data or reset streams in the case of unfulfilled dependencies. The former seems like it might be too much like magical thinking, in the sense that it requires that receivers conjure more memory up, but if the receiver were required to read Y and release the flow control credit, then all would be fine. For instance, we could require that the receiver reset a stream if it couldn't read and handle data. It seems like a bad arrangement though: you either have to allocate more memory than you would like or suffer the time and opportunity cost of having to do Y over. 3. Create an exception for flow control. This is what Google QUIC does for its headers stream. Roberto observed that we could alternatively create a frame type that was excluded from flow control. If this were used for data that had dependencies, then it would be impossible to deadlock. It would be similarly difficult to account for memory allocation, though if it were possible to process on receipt, then this *might* work. We'd have to do something to address out-of-order delivery though. It's possible that the stream abstraction is not appropriate in this case. 4. Block the problem at the source. It was suggested that in cases where there is a potential dependency, then it can't be a problem if the transport refused to accept data that it didn't have flow control credit for. Writes to the transport would consume flow control credit immediately. That way applications would only be able to write X if there was a chance that it would be delivered. Applications that have ordering requirements can ensure that Y is written after X is accepted by the transport and thereby avoid the deadlock. Writes might block rather than fail, if the API wasn't into the whole non-blocking I/O thing. The transport might still have to buffer X for other reasons, like congestion control, but it can guarantee that flow control isn't going to block delivery. ## My Preference Right now, I'm inclined toward option 4. Option 1 seems a little too much of a constraint. Protocols create this sort of inter-dependency naturally. There's a certain purity in having the flow control exert back pressure all the way to the next layer up. Not being able to build a transport with unconstrained writes is potentially creating undesirable externalities on transport users. Now they have to worry about flow control as well. Personally, I'm inclined to say that this is something that application protocols and their users should be exposed to. We've seen with the JS streams API that it's valuable to have back pressure available at the application layer and also how it is possible to do that relatively elegantly. I'm almost certain that I haven't thought about all the potential alternatives. I wonder if there isn't some experience with this problem in SCTP that might lend some insights. --_000_SN6PR1501MB2191934520466DD727CA0BDCCD170SN6PR1501MB2191_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    I'm talking about this in the context of e2e application-level deadloc= ks.

    If we simply increase the global flow control window when things are b= locked , the wrong stream may make forward progress; there is no way to ind= icate a particular stream should make forward progress.

    This may be ok-- The standard way this is resolved today is a timeout,= error, and retry. 

    Since detecting and resolving all of these races is not reasonably sol= vable, this (timeout, retry) is the ultimate mechanism for any application = to resolve issues anyway.

    Imho, the 'blocked on flow control' message, if reliably = sent by blocked senders, will give info on shared-resource (i.e. proxy->= server) deadlocks, and thus better inform actors' timeouts. 

    -=3DR



    Sent via the Samsu= ng Galaxy S7, an AT&T 4G LTE smartphone


    -------- Original message --------
    From: "Lubashev, Igor" <ilubashe@akamai.com>
    Date: 1/11/18 5:28 PM (GMT-08:00)
    To: Roberto Peon <fenix@fb.com>, Jana Iyengar <jri@google.com= >
    Cc: QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@g= mail.com>
    Subject: RE: Deadlocking in the transport

    Transport cannot solve the problem of deadlocking du= e to a higher protocol=92s data priority on its own.  The application = would need to cooperate carefully.

     

    The problem is that it is not only the receiver that= is influencing flow control, because sender transport has buffers as well.=   The sender transport can refuse to accept higher-priority data from = the application, if its buffers are already full with lower-priority data.

     

    So you can end up with receiver refusing to grant ad= ditional credits for stream Y (because it cannot process stream Y w/o strea= m X).  If the sender=92s buffers are full of stream Y data, it cannot = send that data and cannot accept any additional data (for stream X).

     

    The application must be careful not to enqueue strea= m Y data to the transport before it enqueues all data from stream X that st= ream Y data depends on.

     

    • Igor

     

     

    From: Roberto Peon [mailto:fenix@fb.com]
    Sent: Thursday, January 11, 2018 8:03 PM
    To: Jana Iyengar <jri@google.com>
    Cc: QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson= @gmail.com>
    Subject: Re: Deadlocking in the transport

     

    The receiver would be the one to provide the overrid= e; The sender could hint to the receiver that it should wish this by signal= ing it is blocked (or deadlocked) on flow control.

    -=3DR

     

    Fro= m: Jana Iyengar <jri@google.com>
    Date: Thursday, January 11, 2018 at 4:53 PM
    To: Roberto Peon <fenix@fb.com>
    Cc: Martin Thomson <    m= artin.thomson@gmail.com>, QUIC WG <quic@ietf.org>
    Subject: Re: Deadlocking in the transport

     

    Roberto,

     

    I'm not convinced that we need something as heavy-we= ight as this... specifically, flow control so far has been in the receiver'= s control, which is also the thing that owns the resource it is trying to l= imit exhaustion of. This moves it out to the sender, which would require a receiver to now commit memory bas= ed on what a sender believes is important. Reasoning about this seems non-t= rivial. I worry about how all this degree of freedom will get abused, and p= otential sharp edges.

     

    If we can ensure priority consumption of the shared = resource, that seems adequate to resolve the problem on hand. Do you think = something more is required?

     

    - jana

     

    On Wed, Jan 10, 2018 at 12:26 PM, Roberto Peon <<= a href=3D"mailto:fenix@fb.com" target=3D"_blank">fenix@fb.com> wrote= :

    Another option:
    Allow a flow-control =91override=92 which allows a receiver to state that t= hey really want data on a particular stream, and ignore the global flow con= trol for this.

    How you=92d do it:
    A receiver can send a flow-control override for a stream. This includes the= stream id to which the global window temporarily does not apply, the recei= ver=92s current stream flow-control offset, and the offset the receiver wou= ld wish to be able to receive.
    A receiver must continue to (re)send the override (i.e. rexmit) until it is= ack=92d. It cannot send other flow-control for that stream until the overr= ide is ack=92d.
    Thus:
      global-flow-control-override: <stream-id> <current-flow-con= trol-offset>, <override-flow-control-offset>

    The sender (which receives the override) credits the global flow control wi= th the difference between the data sent beyond the receivers currently-know= n flow-control offset upon receipt of the override.
    This synchronizes the global state between the receiver and the sender.
    The sender can then send the data on the stream (without touching any other= flow control data).

    Why:
    This allows for a receiver to resolve priority inversions which would other= wise lead to deadlock, even when the data/dep leading to this was not known= to the transport. This extends beyond such issues beyond just header compr= ession.

    Since the global flow-control exists to protect the app from resource exhau= stion, this poses no additional risk to the application.
    Simply increasing the global flow control provides less strong guarantees= =97any stream might consume it, which doesn=92t resolve the dep inversion. = Rejiggering priorities can help to resolve this, but would require the send= er to send priorities to the client, which is problematic w.r.t.races and just a web of ick.

    Having a custom frame type is also a less strong guarantee as it requires t= he knowledge that the dep exists to be present at the time of sending, whic= h is often impossible.

    -=3DR


    On 1/9/18, 10:17 PM, "QUIC on behalf of Martin Thomson" <quic-bounces@ietf.org on behalf of martin.thomson@gmail.com>= ; wrote:

        Building a complex application protocol on top of QUIC contin= ues to
        produce surprises.

        Today in the header compression design team meeting we discus= sed a
        deadlocking issue that I think warrants sharing with the larg= er group.
        This has implications for how people build a QUIC transport l= ayer.  It
        might need changes to the API that is exposed by that layer.<= br>
        This isn't really that new, but I don't think we've properly = addressed
        the problem.


        ## The Basic Problem

        If a protocol creates a dependency between streams, there is = a
        potential for flow control to deadlock.

        Say that I send X on stream 3 and Y on stream 7.  Proces= sing Y
        requires that X is processed first.

        X cannot be sent due to flow control but Y is sent.  Thi= s is always
        possible even if X is appropriately prioritized.  The re= ceiver then
        leaves Y in its receive buffer until X is received.

        The receiver cannot give flow control credit for consuming Y = because
        it can't consume Y until X is sent.  But the sender need= s flow control
        credit to send X.  We are deadlocked.

        It doesn't matter whether the stream or connection flow contr= ol is
        causing the problem, either produces the same result.

        (To give some background on this, we were considering a prefa= ce to
        header blocks that identified the header table state that was=
        necessary to process the header block.  This would allow= for
        concurrent population of the header table and sending message= that
        depended on the header table state that is under construction= .  A
        receiver would read the identifier and then leave the remaind= er of the
        header block in the receive buffer until the header table was= ready.)


        ## Options

        It seems like there are a few decent options for managing thi= s.  These
        are what occurred to me (there are almost certainly more opti= ons):

        1. Don't do that.  We might concede in this case that se= eking the
        incremental improvement to compression efficiency isn't worth= the
        risk.  That is, we might make a general statement that t= his sort of
        inter-stream blocking is a bad idea.

        2. Force receivers to consume data or reset streams in the ca= se of
        unfulfilled dependencies.  The former seems like it migh= t be too much
        like magical thinking, in the sense that it requires that rec= eivers
        conjure more memory up, but if the receiver were required to = read Y
        and release the flow control credit, then all would be fine.&= nbsp; For
        instance, we could require that the receiver reset a stream i= f it
        couldn't read and handle data.  It seems like a bad arra= ngement
        though: you either have to allocate more memory than you woul= d like or
        suffer the time and opportunity cost of having to do Y over.<= br>
        3. Create an exception for flow control.  This is what G= oogle QUIC
        does for its headers stream.  Roberto observed that we c= ould
        alternatively create a frame type that was excluded from flow= control.
        If this were used for data that had dependencies, then it wou= ld be
        impossible to deadlock.  It would be similarly difficult= to account
        for memory allocation, though if it were possible to process = on
        receipt, then this *might* work.  We'd have to do someth= ing to address
        out-of-order delivery though.  It's possible that the st= ream
        abstraction is not appropriate in this case.

        4. Block the problem at the source.  It was suggested th= at in cases
        where there is a potential dependency, then it can't be a pro= blem if
        the transport refused to accept data that it didn't have flow= control
        credit for.  Writes to the transport would consume flow = control credit
        immediately.  That way applications would only be able t= o write X if
        there was a chance that it would be delivered.  Applicat= ions that have
        ordering requirements can ensure that Y is written after X is= accepted
        by the transport and thereby avoid the deadlock.  Writes= might block
        rather than fail, if the API wasn't into the whole non-blocki= ng I/O
        thing.  The transport might still have to buffer X for o= ther reasons,
        like congestion control, but it can guarantee that flow contr= ol isn't
        going to block delivery.


        ## My Preference

        Right now, I'm inclined toward option 4. Option 1 seems a lit= tle too
        much of a constraint.  Protocols create this sort of int= er-dependency
        naturally.

        There's a certain purity in having the flow control exert bac= k
        pressure all the way to the next layer up.  Not being ab= le to build a
        transport with unconstrained writes is potentially creating     undesirable externalities on transport users.  Now they = have to worry
        about flow control as well.  Personally, I'm inclined to= say that this
        is something that application protocols and their users shoul= d be
        exposed to.  We've seen with the JS streams API that it'= s valuable to
        have back pressure available at the application layer and als= o how it
        is possible to do that relatively elegantly.

        I'm almost certain that I haven't thought about all the poten= tial
        alternatives.  I wonder if there isn't some experience w= ith this
        problem in SCTP that might lend some insights.

     

    --_000_SN6PR1501MB2191934520466DD727CA0BDCCD170SN6PR1501MB2191_-- From nobody Fri Jan 12 11:56:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5255B127077 for ; Fri, 12 Jan 2018 11:56:56 -0800 (PST) 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=HLhtC3Le; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=cKFFKoeA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2uX0H6fii8v for ; Fri, 12 Jan 2018 11:56:52 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4236D1242F5 for ; Fri, 12 Jan 2018 11:56:52 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0CJracu027883; Fri, 12 Jan 2018 11:56:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=YmiUahvd0oh0gctEdqz/FvrCsM5Phwyg9B7dCrHmjx0=; b=HLhtC3LeR5ErJByZKKpSgFNr1YJgyNYu6sR0dA1BRoNzHFzuYjuqel6wH26ZvcAZ66cR WNGvGR+xyBQOmC5tVztX3hwvu6tizokPMPJUxOOEfVnsDAgbTltBuUPaVuvyd7LZjhZs 5lpOxQ9yYur30uew76Q33afpsmTZXaZyuX4= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2ff1y3ra62-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Jan 2018 11:56:42 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 12 Jan 2018 11:56:40 -0800 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=YmiUahvd0oh0gctEdqz/FvrCsM5Phwyg9B7dCrHmjx0=; b=cKFFKoeAJZxtdyK5kAAE29Ntukp6opgar9EGfTk2FPi9Jh/iys9oza7ZBXLH7P5XXlYVgznHE+Bzc5UQhm9qNhPYFBrLsJFqokKr7ayxZPl82TefCbCJmh1ERY5AWhZPQGo03Z2zcunoRjDla7FILqf5nzKHMMkBbjeJwIzbPmo= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2189.namprd15.prod.outlook.com (52.132.120.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Fri, 12 Jan 2018 19:56:38 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Fri, 12 Jan 2018 19:56:39 +0000 From: Roberto Peon To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lubashev, Igor" , Ian Swett CC: "quic@ietf.org" , "huitema@huitema.net" Subject: Re: Increasing QUIC connection ID size Thread-Topic: Increasing QUIC connection ID size Thread-Index: AQHTizJFGh6gA6yAxkSP/nHmnMJHJaNvWU8AgAAH/ICAACejgIAAu4AAgAAEU4CAAAXZAIAAFUUAgAASmoD//6vqgA== Date: Fri, 12 Jan 2018 19:56:39 +0000 Message-ID: References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <69f4ff2b505d4574b369ed872df9b1be@usma1ex-dag1mb5.msg.corp.akamai.com> <808c94738a52489d913279b1e6db100f@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:7098] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2189; 7:m2BVT9x/F26CYMlIETsZNaatcGFMAhFoTnMZNJILbDw3R10MBB1MYt514PyehjNE6RnXVCy0PqwnR8RuutwHUn5O+39r7LX8YN+L9gYmy39NqHV3AcGDoJFCUhhOQnnVjPiKbMb0VME++cISfzOy0GYILHMkGOuZbq8+jvuOnAoLthyJVZc9IsJESZhL1lZPWA+lLmQ7Bs+98hRqaC7bULYWomBmyuENUkiNyqEnkQbpGp78S0fgT9xznWAZQj6b; 20:QbzZ/mZKWpVA9RB08zCjBbTwitnKTYHFlWmR28XFkmC+yXrxyKjxRMQoTXPJ1OcWY2lzmo9yg22MHieBf+RFHXcCfG6+/jbLA+AnRsc4Y/7o37AXhtLvlI0cXHhHvU0ltTDVpVKT5B7OjSf4/yT+TvcKFOIzXr7x75S+bxNfcBo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3e7141d1-4322-4648-b07f-08d559f69831 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020086)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2189; x-ms-traffictypediagnostic: SN6PR1501MB2189: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(85827821059158)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(944501147)(10201501046)(3002001)(6041268)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR1501MB2189; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2189; x-forefront-prvs: 0550778858 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(346002)(396003)(39380400002)(376002)(189003)(53754006)(24454002)(199004)(13464003)(97736004)(229853002)(6306002)(81166006)(54896002)(236005)(3660700001)(83716003)(5660300001)(68736007)(2950100002)(2906002)(6486002)(8676002)(82746002)(6246003)(6436002)(7736002)(6512007)(81156014)(3280700002)(4326008)(53946003)(86362001)(110136005)(59450400001)(5250100002)(316002)(99286004)(54906003)(53546011)(36756003)(478600001)(6116002)(2900100001)(106356001)(39060400002)(33656002)(6506007)(561944003)(76176011)(102836004)(25786009)(8936002)(53936002)(14454004)(105586002)(93886005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2189; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: T8gtyb3EeK2f3VUsvbDWufbhdJuYA+5qxvjIEgXWHRefnMMnhywnBYXMp3xRZ65LEVkJpy3lNEQksq4+jBpgiw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C24046D4C6E242179CF529970086E39Cfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3e7141d1-4322-4648-b07f-08d559f69831 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2018 19:56:39.2075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2189 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-12_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 19:56:56 -0000 --_000_C24046D4C6E242179CF529970086E39Cfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gbG9uZyBhczoNCg0KICAqICAgVGhlIHNlcnZlciBkZXRlcm1pbmVzIENJRHMNCiAgKiAgIEFs bCBwYXJ0aWVzIGFncmVlIG9uIENJRCBsZW5ndGgNCnRoZW4gdmFyaW91cyBMNDwtPkw3IHN0cmF0 ZWdpZXMgY2FuIGJlIHNhZmVseSBhdHRlbXB0ZWQsIHdoZXRoZXIgdGhlIHN0cmF0ZWd5IGlzOg0K DQogIDEuICBFbmNyeXB0aW5nIEw3IGFkZHJlc3Mrc2FsdCBhcyBDSUQNCiAgMi4gIEVuY29kaW5n IG9mIEw3IElQIGFkZHJlc3MgKyBITUFDIGludG8gQ0lEDQogIDMuICBFbmNvZGluZyBvZiBMNyBN QUMNCk9yIHNvbWV0aGluZyBlbHNlLg0KDQpJZiB3ZSBhZ3JlZSBvbiB0aGF0LCB0aGVuIHdlIG5l ZWQgYSBzdHJhdGVneSB0byBkZXRlcm1pbmUgQ0lEIGxlbmd0aC4NCg0KSeKAmWQgc3VnZ2VzdCwg Zm9yIHNpbXBsaWNpdHkgaW4gVjEsIGp1c3QgbWFraW5nIGl0IDEyOCBiaXRzLiBXZSBjYW4gZ2V0 IGZhbmN5IGxhdGVyIGFuZCBoYXZlIG11bHRpcGxlIHNpemVzLCBuZWdvdGlhdGVkIHBlciBjb25u ZWN0aW9uLCBvciBmcmFtZSwgYXMgZGVzaXJlZC4NClllcywgaXQgd2lsbCBiZSBtb3JlIG92ZXJo ZWFkIGluIHRoZSBwcm90b2NvbCwgYnV0IGl0IHdpbGwgdW5sb2NrIGZvbGtzIGFiaWxpdHkgdG8g ZXhwZXJpbWVudCB3aXRoIEw3PC0+TDQgYmFsYW5jaW5nIGluIHJlYXNvbmFibGUgd2F5cy4NCi09 Ug0KDQoNCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KRGF0ZTogRnJp ZGF5LCBKYW51YXJ5IDEyLCAyMDE4IGF0IDg6NTggQU0NClRvOiAiTHViYXNoZXYsIElnb3IiIDxp bHViYXNoZUBha2FtYWkuY29tPiwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPg0KQ2M6 ICJxdWljQGlldGYub3JnIiA8cXVpY0BpZXRmLm9yZz4sICJodWl0ZW1hQGh1aXRlbWEubmV0IiA8 aHVpdGVtYUBodWl0ZW1hLm5ldD4NClN1YmplY3Q6IFJFOiBJbmNyZWFzaW5nIFFVSUMgY29ubmVj dGlvbiBJRCBzaXplDQoNCkl0IGNvdWxkIGFsc28gYmUgZml4ZWQgNjIgYml0IGNvbm5lY3Rpb24g aWRlbnRpZmllciBhbmQgMiBtc2cgb2YgdGhlIGZpcnN0IENJRCBieXRlIHN0b3JlcyB0aGUgYWRk aXRpb25hbCBsZW5ndGguIFRoZSByZXF1aXJlbWVudCBpcyB0aGVuIHRoYXQgdGhlIGZpcnN0IDYy IGJpdHMgbXVzdCBoYXZlIOKAnGVub3VnaCBlbnRyb3B54oCdIGFuZCB0aGUgcmVtYWluaW5nIGJp dHMgYXJlIGFwcGxpY2F0aW9uIG9yIGRlcGxveW1lbnQgc3BlY2lmaWMuIFRoaXMgd2lsbCBmb3Jj ZSByb3V0ZXJzIHRvIHN1cHBvcnQgMTI4LWJpdHMsIGJ1dCBpdCB3aWxsIGFsbG93IHRoZW0gdG8g cmVxdWlyZSBpdCBpZiBzbyBkZXNpcmVkLg0KDQpBIHJvdXRlciBuZWVkIG5vdCBiZSBjb25jZXJu ZWQgd2l0aCB0aGUgdmFyaWFibGUgbGVuZ3RoIGFzcGVjdCBpZiB0aGUgUVVJQyBpbnZhcmlhbnQg ZW5zdXJlcyB0aGF0IGEgcGFja2V0IGxlbmd0aCBpcyBhdCBsZWFzdCBsb25nIGVub3VnaCB0byBy ZWFkIDEyOCBiaXRzIGZyb20gQ0lEIHN0YXJ0LiBJdCBjYW4ganVzdCBhc3N1bWUgdGhlIGxlbmd0 aCBpdCBleHBlY3RzIGFuZCB0aGVuIHZhbGlkYXRlIGFzIG5lZWRlZCB3aXRoIGF1dGggdGFnIG9y IGxlbmd0aCwgb3IganVzdCBhc3N1bWUgaXQgaXMgc2FmZSB1bmRlciB0aGUgY29uZGl0aW9ucy4N Cg0KSW4gYWxsIGNhc2VzIHRoZSBRVUlDIGVuZHBvaW50IE1VU1QgaW5jbHVkZSB0aGUgQ0lEIGlu IHRoZSBhZGRpdGlvbmFsIGRhdGEgYXV0aGVudGljYXRpb24gdG8gZW5zdXJlIHJvdXRpbmcgZGF0 YSBoYXMgbm90IGJlZW4gdGFtcGVyZWQuDQoNCk9uZSBjb3VsZCBhbHNvIHRha2UgdGhpcyBhIHN0 ZXAgZnVydGhlciBhbmQgc2hvcnRlbiB0aGUgZmlyc3QgNjQgYml0cywgYnV0IHRoYXQgaXMgcHJv YmFibHkgYSByYXRzIG5lc3Q6IDE2LCAzMiwgNjQsIDEyOCBiaXRzLg0KDQoNCg0KS2luZCBSZWdh cmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDEyIEphbnVhcnkgMjAxOCBh dCAxNi41MS4xOSwgTHViYXNoZXYsIElnb3IgKGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20+KSB3cm90ZToNClRoZSBwb2ludCBoZXJlIGlzIHRoYXQgaWYgMTI4 LWJpdCBpcyBhbiBvcHRpb24gZnJvbSBWMSwgdGhlbiBhbGwgY2xpZW50cyB3aWxsIHN1cHBvcnQg aXQsIGFuZCB0aGUgc2VydmVyIGNhbiBjaG9vc2UgdG8gYWx3YXlzIHVzZSAxMjgtYml0IGNvbm5l Y3Rpb24gSURzLiAgVGhlIGxvYWQgYmFsYW5jZXIgdGhlbiBjYW4gYmUgc3VyZSB0aGF0IHZhbGlk IGNvbm5lY3Rpb24gSURzIChpbiBwYWNrZXRzIGZlYXR1cmluZyBzZXJ2ZXIgY29ubmVjdGlvbiBJ RCkgY2FuIG9ubHkgYmUgMTI4LWJpdC4gIElmIFYxIGRvZXMgbm90IGhhdmUgMTI4LWJpdCBzdXBw b3J0LCB0aGVuIHRoZSBzZXJ2ZXIgbXVzdCBkZXZlbG9wIGEgbGVzcyBzZWN1cmUgdmVyc2lvbiBv ZiB0aGUgY29ubmVjdGlvbiBJRCB0byBmaXQgaW50byA2NCBiaXRzLCBhbmQgdGhlIGxvYWQgYmFs YW5jZXIgbXVzdCB0cmVhdCA2NC1iaXQgY29ubmVjdGlvbiBJRHMgYXMgYWNjZXB0YWJsZS4gIFRo ZW4sIHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJldmVudCBhbiBhdHRhY2tlciBmcm9tIHVzaW5nIDY0 LWJpdCBjb25uZWN0aW9uIElEcywgaWYgdGhhdOKAmXMgbW9yZSBjb252ZW5pZW50IGZvciB0aGVt Lg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tPl0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxMiwgMjAxOCA5OjM1 IEFNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20+Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+ OyBodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVj dDogUmU6IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemUNCg0KSSB0aGluayB3ZSds bCB3YW50IHN1cHBvcnQgZm9yIGJvdGggbm8gbWF0dGVyIGhvdyB3ZSBkbyB0aGlzLg0KDQpPbiBG cmksIEphbiAxMiwgMjAxOCBhdCA5OjEzIEFNLCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWth bWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+IHdyb3RlOg0KSWYgdGhlIDEyOC1i aXQgb3B0aW9uIGlzIG5vdCBpbiBWMSwgdGhlbiBpdCB3aWxsIGJlIHJlcXVpcmVkIGZvciB0aGUg MTI4LWJpdCBvcHRpb24gdG8gYmUgc2lnbmFsZWQgaW4gdGhlIHBhY2tldCdzIGludmFyaWFudCBz ZWN0aW9uIChsaWtlIGEgYml0IGluIHRoZSAxc3QgYnl0ZSkuIE90aGVyd2lzZSwgdGhlIHZlcnkg bG9hZCBiYWxhbmNlcnMgdGhpcyBpcyBkZXNpZ25lZCBmb3Igd2lsbCBub3Qga25vdyB3aGV0aGVy IHRoZSBjb25uZWN0aW9uIElEIGhhcyA2NC0gb3IgMTI4LWJpdCBmb3JtYXQuIChJdCB3b3VsZCBu ZWVkIHRvIHN1cHBvcnQgYm90aCwgc2luY2UgdGhlcmUgd291bGQgYmUgY2xpZW50cyBzdHVjayBh dCBWMS4pDQoNCkluIGZhY3QsIHRoZSBzZWN1cml0eSBwcm9taXNlcyBvZiBoYXZpbmcgYSAxMjgt Yml0IGNvbm5lY3Rpb24gSUQgb3B0aW9uIChhbGxvd3MgZm9yIG1ha2luZyByb3V0aW5nIGluZm8g aGFyZGVyIHRvIGZvcmdlKSBhcmUgZ3JlYXRseSBkaW1pbmlzaGVkLCB3aGVuIGEgbG9hZCBiYWxh bmNlciBoYXMgdG8gc3VwcG9ydCA2NC1iaXQgY29ubmVjdGlvbiBJRHMgImZvcmV2ZXIiLg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJYW4gU3dldHQgW2lhbnN3ZXR0QGdv b2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+XQ0KUmVjZWl2ZWQ6IEZyaWRheSwg MTIgSmFuIDIwMTgsIDg6NTlBTQ0KVG86IENocmlzdGlhbiBIdWl0ZW1hIFtodWl0ZW1hQGh1aXRl bWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pl0NCkNDOiBJRVRGIFFVSUMgV0cgW3F1 aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+XQ0KU3ViamVjdDogUmU6IEluY3JlYXNp bmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemUNCkkgd291bGQgbGlrZSB0byBsZWF2ZSBRVUlDIG9w ZW4gZm9yIGxvbmdlciBjb25uZWN0aW9uIElEcyBpbiBmdXR1cmUgdmVyc2lvbnMsIHNvIEknZCBs aWtlIHRvIHNwZWNpZnkgdGhlIGludmFyaWFudHMgaW4gc3VjaCBhIHdheSB0aGF0IGxvbmdlciBj b25uZWN0aW9uIElkcyB3b3VsZG4ndCB2aW9sYXRlIHRoZW0oaWU6IFZpY3RvcidzIHN1Z2dlc3Rp b24gb2Yg4oCcbWlkZGxlYm94ZXMgYWx3YXlzIGdldCBmaXJzdCA2NCBiaXRzIGFuZCB0aGV5IGhh dmUgdXNlZnVsIGVudHJvcHkgdG8gZGlzdGluZ3Vpc2ggY29ubmVjdGlvbnPigJ0uKSBidXQgSSdt IHJlbHVjdGFudCB0byBpbmNsdWRlIDEyOCBiaXQgY29ubmVjdGlvbiBJRHMgaW4gdjEgYXQgdGhp cyBwb2ludC4NCg0KSSB3b3VsZCBhbHNvIGVjaG8gQ2hyaXN0aWFuJ3Mgc2VudGltZW50IHRoYXQg dGhlIGluY3JlbWVudGFsIG92ZXJoZWFkIHN0YXJ0cyBiZWNvbWluZyBmYWlybHkgbGFyZ2UuDQoN Ck9uIFRodSwgSmFuIDExLCAyMDE4IGF0IDk6NDcgUE0sIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0 ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQpXZSBo YXZlIGEgcHJvdG90eXBlIGltcGxlbWVudGF0aW9uIGluIFBpY29xdWljIGluIHdoaWNoIHRoZSBj b25uZWN0aW9uIElEIGNhbiBiZSBzcGxpdCBzbyBzb21lIGJpdHMgYXJlIHJhbmRvbSBhbmQgc29t ZSBiaXRzIGFyZSB1c2VkIGZvciByb3V0aW5nIHRvIGEgc3BlY2lmaWMgc2VydmVyIC0tIHRoYW5r cyBJZ29yIGZvciB0aGF0LiBJdCBtYWtlcyBmb3IgbmljZSBleHBlcmltZW50cywgYnV0IGl0IGlz IGEgZGVuaWFsIG9mIHNlcnZpY2Ugd2FpdGluZyB0byBoYXBwZW4uIEZvciBleGFtcGxlLCBhdHRh Y2tlcnMgY291bGQgc2V0IHRoZSBiaXRzIGluIHN1Y2ggYSB3YXkgYXMgdG8gdGFyZ2V0IGEgc3Bl Y2lmaWMgc2VydmVyIGluIGEgcG9vbCwgb3IgdGhleSBjb3VsZCBsZWFybiB3aGljaCBjb25uZWN0 aW9ucyBhcmUgb24gdGhlIHNhbWUgc2VydmVyIGFuZCB1c2UgdGhhdCBsYXRlciBmb3Igc29tZSBr aW5kIG9mIHNhbWUgc2VydmVyIGF0dGFjay4gSXQgd291bGQgYmUgYmV0dGVyIGlmIHRoYXQgaW5m b3JtYXRpb24gd2FzIG5vdCBpbiBjbGVhciB0ZXh0LiBJbiBmYWN0LCB0aGUgcGljb3F1aWMgaW1w bGVtZW50YXRpb24gdXNlIGEgY2FsbGJhY2sgdG8gYXNrIGZvciB0aGUgbmV3IHZhbHVlIC0tIHBy ZXN1bWFibHkgZnJvbSB0aGUgcm91dGVyLiBUaGF0IGNhbGxiYWNrIGNvdWxkIHJldHVybiBhbnl0 aGluZywgaW5jbHVkaW5nIGFuIGVuY3J5cHRlZCB2YWx1ZS4NCg0KT24gdGhlIG90aGVyIGhhbmQs IGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgZnVsbCBlbmNyeXB0aW9uLiBGb3Ig ZXhhbXBsZSwgYXNzdW1lIHRoYXQgdGhlIHNlcnZlciB0aGF0IG5lZWRzIGEgY29ubmVjdGlvbiBJ RCBjYW4gYXNrIGl0IGZyb20gdGhlIHJvdXRlci4gVGhlIHJvdXRlciBjb3VsZCBwaWNrIG9uZSBh dCByYW5kb20sIG1ha2Ugc3VyZSB0aGF0IGl0IGlzIHByb3Blcmx5IGRvY3VtZW50ZWQgaW4gdGhl IHJvdXRpbmcgdGFibGVzIGFuZCB0aGF0IHRoZXJlIGlzIG5vIGNvbGxpc2lvbiwgYW5kIHRoZW4g cGFzcyBpdCBiYWNrIHRvIHRoZSBzZXJ2ZXIuIE5vIGVuY3J5cHRpb24gbmVlZGVkLCBidXQgb2Yg Y291cnNlIGxvdHMgb2Ygc3RhdGUuDQoNCklmIHRoZSByb3V0ZXIgZG9lcyBub3Qgd2FudCB0byBr ZWVwIHRoZSBzdGF0ZSwgaXQgY2FuIGluZGVlZCBjcmVhdGUgYSBjb25uZWN0aW9uIElEIGJ5IGVu Y3J5cHRpbmcgYSA8bm9uY2UsIHNlcnZlci1JRD4gdHVwbGUuIEJ1dCBpdCBkb2VzIG5vdCBmb2xs b3cgdGhhdCB0aGUgZW5jcnlwdGlvbiBuZWVkcyB0byBiZSAxMjggYml0cy4gRm9yIGV4YW1wbGUs IGl0IGNvdWxkIHVzZSBhIDY0IGJpdCBhbGdvcml0aG0gbGlrZSBCbG93ZmlzaC4NCg0KU28gSSBh bSBub3Qgc3VyZSB0aGF0IHdlIGFjdHVhbGx5IG5lZWQgdG8gY2hhbmdlIHRoZSBsZW5ndGguIEFu ZCBJIGFtIGEgYml0IGNvbmNlcm5lZCBieSB0aGUgaW5jcmVtZW50YWwgb3ZlcmhlYWQgaWYgdGhl IGNvbm5lY3Rpb24gSUQgc3VkZGVubHkgYmVjb21lcyB2ZXJ5IGxhcmdlLg0KDQpPbiAxLzExLzIw MTggMjoyNSBQTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiB3cm90ZToNCkFjdHVhbGx5LCBv biBlbmNyeXB0aW9uIG9mIGNvbm5lY3Rpb24gSUQsIHRoaXMgaXMgbm90IHNvIHNpbXBsZS4NCg0K V2UgbXVzdCBhc3N1bWUgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBrZXkgZm9yIG1hbnkgY29ubmVj dGlvbnMgYmVjYXVzZSB0aGUgcm91dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5IGV4Y2hhbmdlLiBU aGlzIHVuaXF1ZSB2YWx1ZSBvciBjb3VudGVyIHVzZWQgZm9yIGVuY3J5cHRpbmcgYSBzaW5nbGUg YmxvY2sgY2Fubm90IGJlIHRoZSBzYW1lIGZvciB0d28gZGlmZmVyZW50IGNvbm5lY3Rpb25zIElE 4oCZcywgYnV0IGl0IGNhbiBiZSBwdWJsaWMuIFRoaXMgbWVhbnMgdGhhdCBpdCBtdXN0IGJlIHN0 b3JlZCBpbiB0aGUgcGFja2V0IGhlYWRlci4gQW5kLCBhcyBpdCB0dXJucyBvdXQsIHJhbmRvbSBj b25uZWN0aW9uIElEIGNob3NlbiBieSBhIHRydXN0ZWQgc291cmNlLCBjYW4gYmUgdXNlZCBmb3Ig c3VjaCBhIHVuaXF1ZSB2YWx1ZS4gQnV0IHRoZW4gaXQgbXVzdCBiZSB1c2VkIHRvIGVuY3J5cHQg YW5kL29yIGF1dGhlbnRpY2F0ZSBzb21ldGhpbmcgZWxzZSBjYXJyeWluZyB0aGUgYWN0dWFsIHJv dXRpbmcgaW5mb3JtYXRpb24uIFNvIG5vdyB5b3Ugc3RhcnQgdG8gcmVhbGx5IG5lZWQgc29tZSBl eHRyYSBwYXlsb2FkLg0KDQpBbHRlcm5hdGl2ZWx5IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGlz IGVudGlyZWx5IHJhbmRvbSBzdWNoIGFzIGNvbnRlbnQgaGFzaGVkIHJvdXRpbmcuIFRoZW4geW91 IG9ubHkgbmVlZCB0byBhdXRoZW50aWNhdGUgdGhlIHJvdXRpbmcgZGF0YS4gWW91IGNhbiBkbyB0 aGF0IHdpdGggYSBITUFDLCBhbmQgQ01BQyBjb3VsZCBwcm9iYWJseSBhbHNvIHdvcmsuIFRoZSBh ZGRpdGlvbmFsIGJlbmVmaXQgaXMgdGhhdCB5b3UgY2FuIHByb2JhYmx5IGdldCBhd2F5IHdpdGgg NjQtYml0cyBmb3IgYWxsIHJvdXRpbmcgaW5mb3JtYXRpb24gcG9zc2libHkgaW5jbHVkaW5nIHRo ZSBhdXRoIHRhZy4gU2F5IDQ4IGJpdHMgb2Ygcm91dGluZyBkYXRhIGFuZCAxNiBiaXRzIG9mIGF1 dGggdGFnLg0KDQpLaW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0K T24gMTIgSmFudWFyeSAyMDE4IGF0IDAwLjU3LjIxLCBMdWJhc2hldiwgSWdvciAoaWx1YmFzaGVA YWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4pIHdyb3RlOg0KSSBhbSBpbnRl cmVzdGVkIGluIGV4cGxvcmluZyB0aGlzIHByb3Bvc2FsLCBzaW5jZSBpdCBhbGxvd3MgZm9yIG1v cmUgZmxleGlibGUgc2NoZW1lcyBvZiBlbmNvZGluZyByb3V0aW5nIG1ldGFkYXRhIGFuZCBhIGNo ZWNrc3VtLiAgSSB3b3VsZCBhbHNvIGxpa2UgdG8gYmUgZXhwbGljaXQgYWJvdXQgdGhlIGNvbm5l Y3Rpb24gSUQgc2l6ZSBpbiBhIHBhY2tldCBoZWFkZXIsIHRob3VnaCwgc2luY2UgaXQgZ3JlYXRs eSBzaW1wbGlmaWVzIHRoZSBpbXBsZW1lbnRhdGlvbi4NCg0KDQogICogICBJZ29yDQpGcm9tOiBW aWN0b3IgVmFzaWxpZXYgW21haWx0bzp2YXNpbHZ2QGdvb2dsZS5jb208bWFpbHRvOnZhc2lsdnZA Z29vZ2xlLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMSwgMjAxOCA2OjE2IFBNDQpU bzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1 YmplY3Q6IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemUNCg0KSGkgZXZlcnlvbmUs DQoNCkluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgUVVJQywgdGhlIGNvbm5lY3Rpb24gSUQgc2l6 ZSBpcyBmaXhlZCB0byBiZSBhIDY0LWJpdCBvcGFxdWUgYmxvYiwgYW5kIHRoYXQgaXMgc2V0IGFz IGFuIGludmFyaWFudCBpbiB0aGUgcHJvdG9jb2wuDQoNCknigJl2ZSBsb29rZWQgaW50byBwb3Nz aWJpbGl0eSBvZiB1c2luZyBhIGNvbm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRoZSBzcGVjaWZpYyBz ZXJ2ZXIgZGV0YWlscyBpbnRvIGl0ICh0byBwcm92aWRlIHN0YWJpbGl0eSBvZiB0aGUgY29ubmVj dGlvbiBpbiBjYXNlIG9mIGxvYWQgYmFsYW5jaW5nIGNoYW5nZXMsIGVzcGVjaWFsbHkgQkdQIGZs YXBzIGZvciBhbnljYXN0IElQcyksIGFuZCBoYXZlIGNoYXR0ZWQgYWJvdXQgdGhpcyB3aXRoIG90 aGVyIHBlb3BsZSBJIGtuZXcgd2VyZSBpbnRlcmVzdGVkIGluIHRoaXMuICBJdCBzZWVtcyBsaWtl IDY0IGJpdHMgbWlnaHQgYmUgdG9vIHNtYWxsIGZvciB0aGlzIHB1cnBvc2UsIGFuZCB3ZSBtaWdo dCB3YW50IHRvIGxlYXZlIGFuIG9wcG9ydHVuaXR5IHRvIGV4dGVuZCB0aGUgY29ubmVjdGlvbiBJ RCBzaXplLg0KDQpUaGUgYmFzaWMgaWRlYSBpcyB0aGF0IHlvdSB3YW50IHRvIGJlIGFibGUgdG86 DQoNCiAgMS4gIFN0b3JlIHNvbWUgcm91dGluZyBtZXRhZGF0YSBpbiB0aGUgY29ubmVjdGlvbiBJ RC4NCiAgMi4gIEhhdmUgc29tZSBlbnRyb3B5IHRoYXQgYWxsb3dzIGRpc3Rpbmd1aXNoIHVzZXJz IHdpdGggaWRlbnRpY2FsIHJvdXRpbmcgbWV0YWRhdGEuDQogIDMuICBIYXZlIGEgY2hlY2tzdW0g dG8gZW5zdXJlIHRoZSB2YWxpZGl0eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uDQogIDQuICBFbmNy eXB0IHRoZSBpbmZvcm1hdGlvbiBhYm92ZSB0byBwcmV2ZW50IGRpc2Nsb3NpbmcgdGhlIHJvdXRl IGluZm9ybWF0aW9uIGFuZCBhbGxvdyBnZW5lcmF0aW5nIHVuY29ycmVsYXRhYmxlIGNvbm5lY3Rp b24gSURzLg0KVGhlcmUgYXJlIHR3byB1bmRlcmx5aW5nIGlzc3VlcyBoZXJlLiAgVGhlIGZpcnN0 IHByb2JsZW0gaXMgdGhhdCBhbGwgb2YgdGhpcyBkb2VzIG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJp dHMsIGFuZCB5b3UgaGF2ZSB0byBzZXJpb3VzbHkgY29tcHJvbWlzZSBvbiB0aGUgc3RyZW5ndGgg b2YgdGhlIGNoZWNrc3VtICh3aGljaCBpcyBiYWQgZXNwZWNpYWxseSBpZiB5b3Ugd2FudCBpdCB0 byBiZSBhIE1BQyByYXRoZXIgdGhhbiBhIGNoZWNrc3VtKS4gIFRoZSBzZWNvbmQgcHJvYmxlbSBp cyB0aGF0IGVuY3J5cHRpbmcgNjQtYml0IHZhbHVlcyBmYXN0IGlzIGFjdHVhbGx5IGZhaXJseSBo YXJkIHNpbmNlIHRoZSBibG9jayBjaXBoZXJzIGVhc2lseSBhdmFpbGFibGUgaW4gaGFyZHdhcmUg aGF2ZSAxMjgtYml0IGJsb2NrIHNpemUsIGFuZCB0aGUgcGVyZm9ybWFuY2UgcmVxdWlyZW1lbnRz IG9uIGxvYWQgYmFsYW5jZXJzIGFyZSB0aWdodGVyIHRoYW4gb24gc2VydmVycy4NCg0KSW4gb3Ro ZXIgd29yZHMsIGhhdmluZyBhIDEyOC1iaXQgY29ubmVjdGlvbiBJRCBwcm92aWRlcyBmb3IgYW4g ZWFzeSBzZWN1cmUgd2F5IHRvIGdlbmVyYXRlIHVubGlua2FibGUgY29ubmVjdGlvbiBJRHMgb24g bWlncmF0aW9uLg0KDQpTbywgdGhlIHByb2JsZW0gd2XigJlyZSB0cnlpbmcgdG8gc29sdmUgaXMg dGhhdCB0aGUgY29ubmVjdGlvbiBJRCBpcyB0b28gc21hbGwuICBUaGVyZSBhcmUgdHdvIHF1ZXN0 aW9ucyBJIGJlbGlldmUgdGhlIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIGFuc3dlciBhdCB0aGlzIHBv aW50Og0KDQogIDEuICBEbyB3ZSB3YW50IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtIGF0IHRoaXMg cG9pbnQgaW4gc3RhbmRhcmRpemF0aW9uIHByb2Nlc3M/DQogIDIuICBJZiB3ZSBkb27igJl0IGFk ZHJlc3MgdGhpcyBwcm9ibGVtIHJpZ2h0IG5vdywgaG93IGRvIHdlIHN0cnVjdHVyZSB0aGUgc3Rh bmRhcmQgaW4gYSB3YXkgdGhhdCB3ZSBjYW4gZXh0ZW5kIHRoZSBjb25uZWN0aW9uIElEIGluIHRo ZSBmdXR1cmU/DQpUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB0byBzb2x2ZSB0aGUgcHJvYmxlbSBv ZiBtYWtpbmcgY29ubmVjdGlvbiBJRCBsYXJnZXIuICBPbmUgaXMgdG8ganVzdCBhZGQgZXh0cmEg Yml0IHRvIHRoZSDigJxvbWl0IGNvbm5lY3Rpb24gSUTigJ0gZmllbGQgdG8gYWxsb3cgMTI4LWJp dCBjb25uZWN0aW9uIElEcy4gIEFub3RoZXIgYXBwcm9hY2ggaXMgdG8gYWxsb3cgY29ubmVjdGlv biBJRCBzaXplIHRvIGJlIGV4cGxpY2l0bHkgc3BlY2lmaWVkIGJ5IHRoZSBzZXJ2ZXIsIGFuZCB0 aGVuIGFzc3VtZSB0aGF0IHRoZSBsb2FkIGJhbGFuY2VyIGtub3dzIHRoYXQgc2l6ZSBhbmQgbm8g b25lIGVsc2Ugb24gdGhlIHBhdGggbmVlZHMgdG8gcmVhZCBpdC4NCg0KVGhlcmXigJlzIGFsc28g YSBxdWVzdGlvbiBvZiBob3cgbXVjaCBvZiBjb25uZWN0aW9uIElEcyBkbyBtaWRkbGVib3hlcyAo ZXhjbHVkaW5nIGxvYWQgYmFsYW5jZXJzIGFuZCBvdGhlciBib3hlcyBvd25lZCBieSB0aGUgc2Ft ZSBlbnRpdHkgYXMgZWl0aGVyIGNsaWVudCBvciBzZXJ2ZXIpIG5lZWQgdG8ga25vdy4gIFdlIGNv dWxkIGdvIGZvciBib3RoIOKAnG1pZGRsZWJveGVzIHNob3VsZCBiZSBhbHdheXMgYWJsZSB0byBy ZWFkIHRoZSBlbnRpcmUgSUTigJ0gYW5kIOKAnG1pZGRsZWJveGVzIHNob3VsZCBub3QgcmVhZCBj b25uZWN0aW9uIElEcyBhdCBhbGwgb3B0aW9uc+KAnSwgYnV0IEkgdGhpbmsgdGhlcmXigJlzIGFs c28gYSByb29tIGZvciBtb3JlIGZsZXhpYmxlIGZvcm11bGF0aW9ucyBsaWtlIOKAnG1pZGRsZWJv eGVzIGFsd2F5cyBnZXQgZmlyc3QgNjQgYml0cyBhbmQgdGhleSBoYXZlIHVzZWZ1bCBlbnRyb3B5 IHRvIGRpc3Rpbmd1aXNoIGNvbm5lY3Rpb25z4oCdLg0KDQogIC0tIFZpY3Rvci4NCg0KDQoNCg== --_000_C24046D4C6E242179CF529970086E39Cfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1u YW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm0yMzE5NTgwMDk4NTY2OTg0NTQ0bTQ0NTIyMTQ2MDE1Njc1MTEyMjRhaXJtYWlsb24sIGxpLm0y MzE5NTgwMDk4NTY2OTg0NTQ0bTQ0NTIyMTQ2MDE1Njc1MTEyMjRhaXJtYWlsb24sIGRpdi5tMjMx OTU4MDA5ODU2Njk4NDU0NG00NDUyMjE0NjAxNTY3NTExMjI0YWlybWFpbG9uDQoJe21zby1zdHls ZS1uYW1lOm0yMzE5NTgwMDk4NTY2OTg0NTQ0bTQ0NTIyMTQ2MDE1Njc1MTEyMjRhaXJtYWlsb247 DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3MDIwOTY1Nzk7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xNzg3MjMwMjY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDo4MDMxNTg2MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0yNjUyODg2ODggNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDINCgl7bXNvLWxpc3QtaWQ6MTM4OTQ1NDYzMzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTM0NDE1MTYzODt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxOTUwNzc0NjI3Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MzMxMTM0NDYgNjc2OTg3 MDUgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIl MVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0 LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjIwNjc3NTU3ODI7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0yNDE2OTMyNjA7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9Indo aXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gbG9uZyBhczo8bzpwPjwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omwx IGxldmVsMSBsZm81Ij5UaGUgc2VydmVyIGRldGVybWluZXMgQ0lEczxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzUiPkFsbCBwYXJ0aWVzIGFncmVlIG9uIENJRCBsZW5ndGg8bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW4gdmFyaW91cyBMNCZsdDst Jmd0O0w3IHN0cmF0ZWdpZXMgY2FuIGJlIHNhZmVseSBhdHRlbXB0ZWQsIHdoZXRoZXIgdGhlIHN0 cmF0ZWd5IGlzOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij5FbmNyeXB0aW5nIEw3IGFkZHJl c3MmIzQzO3NhbHQgYXMgQ0lEPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvNCI+RW5j b2Rpbmcgb2YgTDcgSVAgYWRkcmVzcyAmIzQzOyBITUFDIGludG8gQ0lEPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMyBsZXZlbDEgbGZvNCI+RW5jb2Rpbmcgb2YgTDcgTUFDPG86cD48L286cD48L2xpPjwv b2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PciBzb21ldGhpbmcgZWxzZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SWYgd2UgYWdyZWUgb24gdGhhdCwgdGhlbiB3ZSBuZWVkIGEgc3RyYXRlZ3kg dG8gZGV0ZXJtaW5lIENJRCBsZW5ndGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpJ4oCZZCBzdWdnZXN0LCBmb3Igc2ltcGxpY2l0eSBpbiBWMSwganVzdCBtYWtp bmcgaXQgMTI4IGJpdHMuIFdlIGNhbiBnZXQgZmFuY3kgbGF0ZXIgYW5kIGhhdmUgbXVsdGlwbGUg c2l6ZXMsIG5lZ290aWF0ZWQgcGVyIGNvbm5lY3Rpb24sIG9yIGZyYW1lLCBhcyBkZXNpcmVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBpdCB3aWxsIGJlIG1vcmUg b3ZlcmhlYWQgaW4gdGhlIHByb3RvY29sLCBidXQgaXQgd2lsbCB1bmxvY2sgZm9sa3MgYWJpbGl0 eSB0byBleHBlcmltZW50IHdpdGggTDcmbHQ7LSZndDtMNCBiYWxhbmNpbmcgaW4gcmVhc29uYWJs ZSB3YXlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LT1SPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IG9uIGJlaGFsZiBvZiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxm akBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSmFudWFyeSAxMiwgMjAx OCBhdCA4OjU4IEFNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAm bHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDssIElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xl LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3F1aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O3F1 aWNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtodWl0ZW1hQGh1aXRlbWEubmV0JnF1b3Q7ICZsdDtodWl0 ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogSW5jcmVhc2luZyBR VUlDIGNvbm5lY3Rpb24gSUQgc2l6ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5JdCBjb3VsZCBhbHNvIGJlIGZpeGVkIDYyIGJpdCBjb25uZWN0aW9uIGlkZW50 aWZpZXIgYW5kIDIgbXNnIG9mIHRoZSBmaXJzdCBDSUQgYnl0ZSBzdG9yZXMgdGhlIGFkZGl0aW9u YWwgbGVuZ3RoLiBUaGUgcmVxdWlyZW1lbnQgaXMgdGhlbiB0aGF0IHRoZSBmaXJzdCA2MiBiaXRz IG11c3QgaGF2ZQ0KIOKAnGVub3VnaCBlbnRyb3B54oCdIGFuZCB0aGUgcmVtYWluaW5nIGJpdHMg YXJlIGFwcGxpY2F0aW9uIG9yIGRlcGxveW1lbnQgc3BlY2lmaWMuIFRoaXMgd2lsbCBmb3JjZSBy b3V0ZXJzIHRvIHN1cHBvcnQgMTI4LWJpdHMsIGJ1dCBpdCB3aWxsIGFsbG93IHRoZW0gdG8gcmVx dWlyZSBpdCBpZiBzbyBkZXNpcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5BIHJvdXRlciBuZWVkIG5vdCBiZSBjb25jZXJuZWQgd2l0aCB0aGUgdmFyaWFibGUgbGVuZ3Ro IGFzcGVjdCBpZiB0aGUgUVVJQyBpbnZhcmlhbnQgZW5zdXJlcyB0aGF0IGEgcGFja2V0IGxlbmd0 aCBpcyBhdCBsZWFzdCBsb25nIGVub3VnaCB0byByZWFkIDEyOCBiaXRzIGZyb20gQ0lEIHN0YXJ0 Lg0KIEl0IGNhbiBqdXN0IGFzc3VtZSB0aGUgbGVuZ3RoIGl0IGV4cGVjdHMgYW5kIHRoZW4gdmFs aWRhdGUgYXMgbmVlZGVkIHdpdGggYXV0aCB0YWcgb3IgbGVuZ3RoLCBvciBqdXN0IGFzc3VtZSBp dCBpcyBzYWZlIHVuZGVyIHRoZSBjb25kaXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5JbiBhbGwgY2FzZXMgdGhlIFFVSUMgZW5kcG9pbnQgTVVTVCBpbmNsdWRlIHRo ZSBDSUQgaW4gdGhlIGFkZGl0aW9uYWwgZGF0YSBhdXRoZW50aWNhdGlvbiB0byBlbnN1cmUgcm91 dGluZyBkYXRhIGhhcyBub3QgYmVlbiB0YW1wZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+T25lIGNvdWxkIGFsc28gdGFrZSB0aGlzIGEgc3RlcCBmdXJ0aGVyIGFuZCBz aG9ydGVuIHRoZSBmaXJzdCA2NCBiaXRzLCBidXQgdGhhdCBpcyBwcm9iYWJseSBhIHJhdHMgbmVz dDogMTYsIDMyLCA2NCwgMTI4IGJpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1MTU3NzU3 MzU3MjE3MTAwODAiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPk9uIDEyIEphbnVhcnkgMjAxOCBhdCAxNi41MS4x OSwgTHViYXNoZXYsIElnb3IgKDxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5p bHViYXNoZUBha2FtYWkuY29tPC9hPikgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIHBvaW50IGhlcmUgaXMgdGhh dCBpZiAxMjgtYml0IGlzIGFuIG9wdGlvbiBmcm9tIFYxLCB0aGVuIGFsbCBjbGllbnRzIHdpbGwg c3VwcG9ydCBpdCwgYW5kIHRoZSBzZXJ2ZXIgY2FuIGNob29zZSB0byBhbHdheXMgdXNlIDEyOC1i aXQgY29ubmVjdGlvbiBJRHMuJm5ic3A7IFRoZSBsb2FkIGJhbGFuY2VyIHRoZW4NCiBjYW4gYmUg c3VyZSB0aGF0IHZhbGlkIGNvbm5lY3Rpb24gSURzIChpbiBwYWNrZXRzIGZlYXR1cmluZyBzZXJ2 ZXIgY29ubmVjdGlvbiBJRCkgY2FuIG9ubHkgYmUgMTI4LWJpdC4mbmJzcDsgSWYgVjEgZG9lcyBu b3QgaGF2ZSAxMjgtYml0IHN1cHBvcnQsIHRoZW4gdGhlIHNlcnZlciBtdXN0IGRldmVsb3AgYSBs ZXNzIHNlY3VyZSB2ZXJzaW9uIG9mIHRoZSBjb25uZWN0aW9uIElEIHRvIGZpdCBpbnRvIDY0IGJp dHMsIGFuZCB0aGUgbG9hZCBiYWxhbmNlcg0KIG11c3QgdHJlYXQgNjQtYml0IGNvbm5lY3Rpb24g SURzIGFzIGFjY2VwdGFibGUuJm5ic3A7IFRoZW4sIHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJldmVu dCBhbiBhdHRhY2tlciBmcm9tIHVzaW5nIDY0LWJpdCBjb25uZWN0aW9uIElEcywgaWYgdGhhdOKA mXMgbW9yZSBjb252ZW5pZW50IGZvciB0aGVtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBn b29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBG cmlkYXksIEphbnVhcnkgMTIsIDIwMTggOTozNSBBTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYs IElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBh a2FtYWkuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpxdWljQGll dGYub3JnIj5xdWljQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVt YS5uZXQiPg0KaHVpdGVtYUBodWl0ZW1hLm5ldDwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IEluY3JlYXNpbmcgUVVJQyBjb25uZWN0aW9uIElEIHNpemU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JIHRoaW5rIHdlJ2xsIHdhbnQgc3VwcG9ydCBmb3IgYm90aCBubyBtYXR0 ZXIgaG93IHdlIGRvIHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gRnJpLCBKYW4gMTIsIDIwMTggYXQgOToxMyBBTSwgTHViYXNoZXYsIEln b3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHRoZSAxMjgt Yml0IG9wdGlvbiBpcyBub3QgaW4gVjEsIHRoZW4gaXQgd2lsbCBiZSByZXF1aXJlZCBmb3IgdGhl IDEyOC1iaXQgb3B0aW9uIHRvIGJlIHNpZ25hbGVkIGluIHRoZSBwYWNrZXQncyBpbnZhcmlhbnQg c2VjdGlvbiAobGlrZSBhIGJpdCBpbiB0aGUNCiAxc3QgYnl0ZSkuIE90aGVyd2lzZSwgdGhlIHZl cnkgbG9hZCBiYWxhbmNlcnMgdGhpcyBpcyBkZXNpZ25lZCBmb3Igd2lsbCBub3Qga25vdyB3aGV0 aGVyIHRoZSBjb25uZWN0aW9uIElEIGhhcyA2NC0gb3IgMTI4LWJpdCBmb3JtYXQuIChJdCB3b3Vs ZCBuZWVkIHRvIHN1cHBvcnQgYm90aCwgc2luY2UgdGhlcmUgd291bGQgYmUgY2xpZW50cyBzdHVj ayBhdCBWMS4pPGJyPg0KPGJyPg0KSW4gZmFjdCwgdGhlIHNlY3VyaXR5IHByb21pc2VzIG9mIGhh dmluZyBhIDEyOC1iaXQgY29ubmVjdGlvbiBJRCBvcHRpb24gKGFsbG93cyBmb3IgbWFraW5nIHJv dXRpbmcgaW5mbyBoYXJkZXIgdG8gZm9yZ2UpIGFyZSBncmVhdGx5IGRpbWluaXNoZWQsIHdoZW4g YSBsb2FkIGJhbGFuY2VyIGhhcyB0byBzdXBwb3J0IDY0LWJpdCBjb25uZWN0aW9uIElEcyAmcXVv dDtmb3JldmVyJnF1b3Q7Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCjxicj4NCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCjxiPkZyb206PC9iPiBJYW4gU3dldHQgWzxhIGhy ZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRA Z29vZ2xlLmNvbTwvYT5dPGJyPg0KPGI+UmVjZWl2ZWQ6PC9iPiBGcmlkYXksIDEyIEphbiAyMDE4 LCA4OjU5QU08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGlhbiBIdWl0ZW1hIFs8YSBocmVmPSJtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVpdGVtYS5u ZXQ8L2E+XTxicj4NCjxiPkNDOjwvYj4gSUVURiBRVUlDIFdHIFs8YSBocmVmPSJtYWlsdG86cXVp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+XTxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogSW5jcmVhc2luZyBRVUlDIGNvbm5lY3Rpb24gSUQgc2l6ZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIGxpa2UgdG8gbGVhdmUgUVVJQyBvcGVu IGZvciBsb25nZXIgY29ubmVjdGlvbiBJRHMgaW4gZnV0dXJlIHZlcnNpb25zLCBzbyBJJ2QgbGlr ZSB0byBzcGVjaWZ5IHRoZSBpbnZhcmlhbnRzIGluIHN1Y2ggYSB3YXkgdGhhdCBsb25nZXIgY29u bmVjdGlvbiBJZHMgd291bGRuJ3QgdmlvbGF0ZSB0aGVtKGllOg0KIFZpY3RvcidzIHN1Z2dlc3Rp b24gb2YmbmJzcDvigJxtaWRkbGVib3hlcyBhbHdheXMgZ2V0IGZpcnN0IDY0IGJpdHMgYW5kIHRo ZXkgaGF2ZSB1c2VmdWwgZW50cm9weSB0byBkaXN0aW5ndWlzaCBjb25uZWN0aW9uc+KAnS4pIGJ1 dCBJJ20gcmVsdWN0YW50IHRvIGluY2x1ZGUgMTI4IGJpdCBjb25uZWN0aW9uIElEcyBpbiB2MSBh dCB0aGlzIHBvaW50Lg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48YnI+DQpJIHdvdWxkIGFsc28gZWNobyBDaHJpc3RpYW4ncyBzZW50aW1lbnQgdGhhdCB0 aGUgaW5jcmVtZW50YWwgb3ZlcmhlYWQgc3RhcnRzIGJlY29taW5nIGZhaXJseSBsYXJnZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFRodSwgSmFuIDExLCAyMDE4IGF0IDk6NDcgUE0sIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBo cmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFA aHVpdGVtYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+V2UgaGF2ZSBhIHByb3RvdHlwZSBpbXBsZW1lbnRhdGlvbiBpbiBQaWNvcXVpYyBp biB3aGljaCB0aGUgY29ubmVjdGlvbiBJRCBjYW4gYmUgc3BsaXQgc28gc29tZSBiaXRzIGFyZSBy YW5kb20gYW5kIHNvbWUgYml0cyBhcmUgdXNlZCBmb3Igcm91dGluZyB0byBhIHNwZWNpZmljIHNl cnZlciAtLSB0aGFua3MNCiBJZ29yIGZvciB0aGF0LiBJdCBtYWtlcyBmb3IgbmljZSBleHBlcmlt ZW50cywgYnV0IGl0IGlzIGEgZGVuaWFsIG9mIHNlcnZpY2Ugd2FpdGluZyB0byBoYXBwZW4uIEZv ciBleGFtcGxlLCBhdHRhY2tlcnMgY291bGQgc2V0IHRoZSBiaXRzIGluIHN1Y2ggYSB3YXkgYXMg dG8gdGFyZ2V0IGEgc3BlY2lmaWMgc2VydmVyIGluIGEgcG9vbCwgb3IgdGhleSBjb3VsZCBsZWFy biB3aGljaCBjb25uZWN0aW9ucyBhcmUgb24gdGhlIHNhbWUgc2VydmVyIGFuZA0KIHVzZSB0aGF0 IGxhdGVyIGZvciBzb21lIGtpbmQgb2Ygc2FtZSBzZXJ2ZXIgYXR0YWNrLiBJdCB3b3VsZCBiZSBi ZXR0ZXIgaWYgdGhhdCBpbmZvcm1hdGlvbiB3YXMgbm90IGluIGNsZWFyIHRleHQuIEluIGZhY3Qs IHRoZSBwaWNvcXVpYyBpbXBsZW1lbnRhdGlvbiB1c2UgYSBjYWxsYmFjayB0byBhc2sgZm9yIHRo ZSBuZXcgdmFsdWUgLS0gcHJlc3VtYWJseSBmcm9tIHRoZSByb3V0ZXIuIFRoYXQgY2FsbGJhY2sg Y291bGQgcmV0dXJuIGFueXRoaW5nLA0KIGluY2x1ZGluZyBhbiBlbmNyeXB0ZWQgdmFsdWUuPGJy Pg0KPGJyPg0KT24gdGhlIG90aGVyIGhhbmQsIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHdl IG5lZWQgZnVsbCBlbmNyeXB0aW9uLiBGb3IgZXhhbXBsZSwgYXNzdW1lIHRoYXQgdGhlIHNlcnZl ciB0aGF0IG5lZWRzIGEgY29ubmVjdGlvbiBJRCBjYW4gYXNrIGl0IGZyb20gdGhlIHJvdXRlci4g VGhlIHJvdXRlciBjb3VsZCBwaWNrIG9uZSBhdCByYW5kb20sIG1ha2Ugc3VyZSB0aGF0IGl0IGlz IHByb3Blcmx5IGRvY3VtZW50ZWQgaW4gdGhlIHJvdXRpbmcgdGFibGVzDQogYW5kIHRoYXQgdGhl cmUgaXMgbm8gY29sbGlzaW9uLCBhbmQgdGhlbiBwYXNzIGl0IGJhY2sgdG8gdGhlIHNlcnZlci4g Tm8gZW5jcnlwdGlvbiBuZWVkZWQsIGJ1dCBvZiBjb3Vyc2UgbG90cyBvZiBzdGF0ZS48YnI+DQo8 YnI+DQpJZiB0aGUgcm91dGVyIGRvZXMgbm90IHdhbnQgdG8ga2VlcCB0aGUgc3RhdGUsIGl0IGNh biBpbmRlZWQgY3JlYXRlIGEgY29ubmVjdGlvbiBJRCBieSBlbmNyeXB0aW5nIGEgJmx0O25vbmNl LCBzZXJ2ZXItSUQmZ3Q7IHR1cGxlLiBCdXQgaXQgZG9lcyBub3QgZm9sbG93IHRoYXQgdGhlIGVu Y3J5cHRpb24gbmVlZHMgdG8gYmUgMTI4IGJpdHMuIEZvciBleGFtcGxlLCBpdCBjb3VsZCB1c2Ug YSA2NCBiaXQgYWxnb3JpdGhtIGxpa2UgQmxvd2Zpc2guDQo8YnI+DQo8YnI+DQpTbyBJIGFtIG5v dCBzdXJlIHRoYXQgd2UgYWN0dWFsbHkgbmVlZCB0byBjaGFuZ2UgdGhlIGxlbmd0aC4gQW5kIEkg YW0gYSBiaXQgY29uY2VybmVkIGJ5IHRoZSBpbmNyZW1lbnRhbCBvdmVyaGVhZCBpZiB0aGUgY29u bmVjdGlvbiBJRCBzdWRkZW5seSBiZWNvbWVzIHZlcnkgbGFyZ2UuDQo8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIDEvMTEvMjAxOCAyOjI1IFBNLCBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXYg aWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUxMTIyNGJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QWN0dWFs bHksIG9uIGVuY3J5cHRpb24gb2YgY29ubmVjdGlvbiBJRCwgdGhpcyBpcyBub3Qgc28gc2ltcGxl Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8yMzE5NTgwMDk4NTY2 OTg0NTQ0bV80NDUyMjE0NjAxNTY3NTExMjI0Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2 NzUxMTIyNGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+V2UgbXVzdCBhc3N1bWUgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBrZXkgZm9y IG1hbnkgY29ubmVjdGlvbnMgYmVjYXVzZSB0aGUgcm91dGVyIGlzIG5vdCBwYXJ0IG9mIGEga2V5 IGV4Y2hhbmdlLg0KIFRoaXMgdW5pcXVlIHZhbHVlIG9yIGNvdW50ZXIgdXNlZCBmb3IgZW5jcnlw dGluZyBhIHNpbmdsZSBibG9jayBjYW5ub3QgYmUgdGhlIHNhbWUgZm9yIHR3byBkaWZmZXJlbnQg Y29ubmVjdGlvbnMgSUTigJlzLCBidXQgaXQgY2FuIGJlIHB1YmxpYy4gVGhpcyBtZWFucyB0aGF0 IGl0IG11c3QgYmUgc3RvcmVkIGluIHRoZSBwYWNrZXQgaGVhZGVyLiBBbmQsIGFzIGl0IHR1cm5z IG91dCwgcmFuZG9tIGNvbm5lY3Rpb24gSUQgY2hvc2VuIGJ5IGEgdHJ1c3RlZA0KIHNvdXJjZSwg Y2FuIGJlIHVzZWQgZm9yIHN1Y2ggYSB1bmlxdWUgdmFsdWUuIEJ1dCB0aGVuIGl0IG11c3QgYmUg dXNlZCB0byBlbmNyeXB0IGFuZC9vciBhdXRoZW50aWNhdGUgc29tZXRoaW5nIGVsc2UgY2Fycnlp bmcgdGhlIGFjdHVhbCByb3V0aW5nIGluZm9ybWF0aW9uLiBTbyBub3cgeW91IHN0YXJ0IHRvIHJl YWxseSBuZWVkIHNvbWUgZXh0cmEgcGF5bG9hZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUxMTIyNGJs b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzIzMTk1 ODAwOTg1NjY5ODQ1NDRtXzQ0NTIyMTQ2MDE1Njc1MTEyMjRibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdGVybmF0aXZlbHkgdGhl IHJvdXRpbmcgaW5mb3JtYXRpb24gaXMgZW50aXJlbHkgcmFuZG9tIHN1Y2ggYXMgY29udGVudCBo YXNoZWQgcm91dGluZy4gVGhlbiB5b3Ugb25seSBuZWVkIHRvDQogYXV0aGVudGljYXRlIHRoZSBy b3V0aW5nIGRhdGEuIFlvdSBjYW4gZG8gdGhhdCB3aXRoIGEgSE1BQywgYW5kIENNQUMgY291bGQg cHJvYmFibHkgYWxzbyB3b3JrLiBUaGUgYWRkaXRpb25hbCBiZW5lZml0IGlzIHRoYXQgeW91IGNh biBwcm9iYWJseSBnZXQgYXdheSB3aXRoIDY0LWJpdHMgZm9yIGFsbCByb3V0aW5nIGluZm9ybWF0 aW9uIHBvc3NpYmx5IGluY2x1ZGluZyB0aGUgYXV0aCB0YWcuIFNheSA0OCBiaXRzIG9mIHJvdXRp bmcgZGF0YSBhbmQNCiAxNiBiaXRzIG9mIGF1dGggdGFnLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXYgaWQ9Im1fMjMxOTU4MDA5ODU2Njk4NDU0NG1fNDQ1MjIxNDYwMTU2NzUxMTIyNGJsb29wX3Np Z25fMTUxNTcxNjEzNzIwMzMzMzg4OCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBG YWhuw7hlIErDuHJnZW5zZW48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt MjMxOTU4MDA5ODU2Njk4NDU0NG00NDUyMjE0NjAxNTY3NTExMjI0YWlybWFpbG9uIj5PbiAxMiBK YW51YXJ5IDIwMTggYXQgMDAuNTcuMjEsIEx1YmFzaGV2LCBJZ29yICg8YSBocmVmPSJtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208 L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5JIGFtIGludGVyZXN0ZWQgaW4gZXhwbG9yaW5nIHRoaXMgcHJvcG9z YWwsIHNpbmNlIGl0IGFsbG93cyBmb3IgbW9yZSBmbGV4aWJsZSBzY2hlbWVzIG9mIGVuY29kaW5n IHJvdXRpbmcgbWV0YWRhdGEgYW5kIGEgY2hlY2tzdW0uJm5ic3A7IEkgd291bGQgYWxzbyBsaWtl IHRvIGJlIGV4cGxpY2l0IGFib3V0IHRoZSBjb25uZWN0aW9uDQogSUQgc2l6ZSBpbiBhIHBhY2tl dCBoZWFkZXIsIHRob3VnaCwgc2luY2UgaXQgZ3JlYXRseSBzaW1wbGlmaWVzIHRoZSBpbXBsZW1l bnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJZ29yIDxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gVmljdG9yIFZh c2lsaWV2IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZhc2lsdnZAZ29vZ2xlLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnZhc2lsdnZAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEphbnVhcnkgMTEsIDIwMTggNjoxNiBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlD IFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1 aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBJbmNyZWFzaW5nIFFVSUMg Y29ubmVjdGlvbiBJRCBzaXplPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkhpIGV2ZXJ5b25lLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiBRVUlDLCB0aGUgY29u bmVjdGlvbiBJRCBzaXplIGlzIGZpeGVkIHRvIGJlIGEgNjQtYml0IG9wYXF1ZSBibG9iLCBhbmQg dGhhdCBpcyBzZXQgYXMgYW4gaW52YXJpYW50IGluIHRoZSBwcm90b2NvbC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPknigJl2ZSBsb29r ZWQgaW50byBwb3NzaWJpbGl0eSBvZiB1c2luZyBhIGNvbm5lY3Rpb24gSUQgdG8gZW5jb2RlIHRo ZSBzcGVjaWZpYyBzZXJ2ZXIgZGV0YWlscyBpbnRvIGl0ICh0byBwcm92aWRlIHN0YWJpbGl0eSBv ZiB0aGUgY29ubmVjdGlvbiBpbiBjYXNlIG9mIGxvYWQgYmFsYW5jaW5nIGNoYW5nZXMsIGVzcGVj aWFsbHkNCiBCR1AgZmxhcHMgZm9yIGFueWNhc3QgSVBzKSwgYW5kIGhhdmUgY2hhdHRlZCBhYm91 dCB0aGlzIHdpdGggb3RoZXIgcGVvcGxlIEkga25ldyB3ZXJlIGludGVyZXN0ZWQgaW4gdGhpcy4m bmJzcDsgSXQgc2VlbXMgbGlrZSA2NCBiaXRzIG1pZ2h0IGJlIHRvbyBzbWFsbCBmb3IgdGhpcyBw dXJwb3NlLCBhbmQgd2UgbWlnaHQgd2FudCB0byBsZWF2ZSBhbiBvcHBvcnR1bml0eSB0byBleHRl bmQgdGhlIGNvbm5lY3Rpb24gSUQgc2l6ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBiYXNpYyBpZGVhIGlzIHRoYXQgeW91IHdh bnQgdG8gYmUgYWJsZSB0bzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFy dD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsNCBsZXZlbDEgbGZvMiI+DQpTdG9yZSBzb21lIHJvdXRpbmcgbWV0YWRhdGEgaW4g dGhlIGNvbm5lY3Rpb24gSUQuIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMiI+DQpIYXZlIHNvbWUgZW50 cm9weSB0aGF0IGFsbG93cyBkaXN0aW5ndWlzaCB1c2VycyB3aXRoIGlkZW50aWNhbCByb3V0aW5n IG1ldGFkYXRhLiA8bzpwPg0KPC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMiI+DQpIYXZlIGEgY2hlY2tzdW0gdG8g ZW5zdXJlIHRoZSB2YWxpZGl0eSBvZiByb3V0aW5nIGluZm9ybWF0aW9uIDxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZl bDEgbGZvMiI+DQpFbmNyeXB0IHRoZSBpbmZvcm1hdGlvbiBhYm92ZSB0byBwcmV2ZW50IGRpc2Ns b3NpbmcgdGhlIHJvdXRlIGluZm9ybWF0aW9uIGFuZCBhbGxvdyBnZW5lcmF0aW5nIHVuY29ycmVs YXRhYmxlIGNvbm5lY3Rpb24gSURzLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlIGFyZSB0d28gdW5kZXJseWluZyBpc3N1 ZXMgaGVyZS4mbmJzcDsgVGhlIGZpcnN0IHByb2JsZW0gaXMgdGhhdCBhbGwgb2YgdGhpcyBkb2Vz IG5vdCBmaXQgd2VsbCBpbnRvIDY0IGJpdHMsIGFuZCB5b3UgaGF2ZSB0byBzZXJpb3VzbHkgY29t cHJvbWlzZSBvbiB0aGUgc3RyZW5ndGggb2YgdGhlIGNoZWNrc3VtDQogKHdoaWNoIGlzIGJhZCBl c3BlY2lhbGx5IGlmIHlvdSB3YW50IGl0IHRvIGJlIGEgTUFDIHJhdGhlciB0aGFuIGEgY2hlY2tz dW0pLiZuYnNwOyBUaGUgc2Vjb25kIHByb2JsZW0gaXMgdGhhdCBlbmNyeXB0aW5nIDY0LWJpdCB2 YWx1ZXMgZmFzdCBpcyBhY3R1YWxseSBmYWlybHkgaGFyZCBzaW5jZSB0aGUgYmxvY2sgY2lwaGVy cyBlYXNpbHkgYXZhaWxhYmxlIGluIGhhcmR3YXJlIGhhdmUgMTI4LWJpdCBibG9jayBzaXplLCBh bmQgdGhlIHBlcmZvcm1hbmNlDQogcmVxdWlyZW1lbnRzIG9uIGxvYWQgYmFsYW5jZXJzIGFyZSB0 aWdodGVyIHRoYW4gb24gc2VydmVycy4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG90aGVyIHdvcmRzLCBoYXZp bmcgYSAxMjgtYml0IGNvbm5lY3Rpb24gSUQgcHJvdmlkZXMgZm9yIGFuIGVhc3kgc2VjdXJlIHdh eSB0byBnZW5lcmF0ZSB1bmxpbmthYmxlIGNvbm5lY3Rpb24gSURzIG9uIG1pZ3JhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNv LCB0aGUgcHJvYmxlbSB3ZeKAmXJlIHRyeWluZyB0byBzb2x2ZSBpcyB0aGF0IHRoZSBjb25uZWN0 aW9uIElEIGlzIHRvbyBzbWFsbC4mbmJzcDsgVGhlcmUgYXJlIHR3byBxdWVzdGlvbnMgSSBiZWxp ZXZlIHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBhbnN3ZXIgYXQgdGhpcyBwb2ludDo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+ DQpEbyB3ZSB3YW50IHRvIGFkZHJlc3MgdGhpcyBwcm9ibGVtIGF0IHRoaXMgcG9pbnQgaW4gc3Rh bmRhcmRpemF0aW9uIHByb2Nlc3M/IDxvOnA+DQo8L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj4NCklmIHdlIGRv buKAmXQgYWRkcmVzcyB0aGlzIHByb2JsZW0gcmlnaHQgbm93LCBob3cgZG8gd2Ugc3RydWN0dXJl IHRoZSBzdGFuZGFyZCBpbiBhIHdheSB0aGF0IHdlIGNhbiBleHRlbmQgdGhlIGNvbm5lY3Rpb24g SUQgaW4gdGhlIGZ1dHVyZT8NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyB0byBzb2x2ZSB0 aGUgcHJvYmxlbSBvZiBtYWtpbmcgY29ubmVjdGlvbiBJRCBsYXJnZXIuJm5ic3A7IE9uZSBpcyB0 byBqdXN0IGFkZCBleHRyYSBiaXQgdG8gdGhlIOKAnG9taXQgY29ubmVjdGlvbiBJROKAnSBmaWVs ZCB0byBhbGxvdyAxMjgtYml0IGNvbm5lY3Rpb24gSURzLiZuYnNwOyBBbm90aGVyDQogYXBwcm9h Y2ggaXMgdG8gYWxsb3cgY29ubmVjdGlvbiBJRCBzaXplIHRvIGJlIGV4cGxpY2l0bHkgc3BlY2lm aWVkIGJ5IHRoZSBzZXJ2ZXIsIGFuZCB0aGVuIGFzc3VtZSB0aGF0IHRoZSBsb2FkIGJhbGFuY2Vy IGtub3dzIHRoYXQgc2l6ZSBhbmQgbm8gb25lIGVsc2Ugb24gdGhlIHBhdGggbmVlZHMgdG8gcmVh ZCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlRoZXJl4oCZcyBhbHNvIGEgcXVlc3Rpb24gb2YgaG93IG11Y2ggb2YgY29ubmVjdGlv biBJRHMgZG8gbWlkZGxlYm94ZXMgKGV4Y2x1ZGluZyBsb2FkIGJhbGFuY2VycyBhbmQgb3RoZXIg Ym94ZXMgb3duZWQgYnkgdGhlIHNhbWUgZW50aXR5IGFzIGVpdGhlciBjbGllbnQgb3Igc2VydmVy KSBuZWVkIHRvIGtub3cuJm5ic3A7DQogV2UgY291bGQgZ28gZm9yIGJvdGgg4oCcbWlkZGxlYm94 ZXMgc2hvdWxkIGJlIGFsd2F5cyBhYmxlIHRvIHJlYWQgdGhlIGVudGlyZSBJROKAnSBhbmQg4oCc bWlkZGxlYm94ZXMgc2hvdWxkIG5vdCByZWFkIGNvbm5lY3Rpb24gSURzIGF0IGFsbCBvcHRpb25z 4oCdLCBidXQgSSB0aGluayB0aGVyZeKAmXMgYWxzbyBhIHJvb20gZm9yIG1vcmUgZmxleGlibGUg Zm9ybXVsYXRpb25zIGxpa2Ug4oCcbWlkZGxlYm94ZXMgYWx3YXlzIGdldCBmaXJzdCA2NCBiaXRz IGFuZCB0aGV5DQogaGF2ZSB1c2VmdWwgZW50cm9weSB0byBkaXN0aW5ndWlzaCBjb25uZWN0aW9u c+KAnS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAtLSBWaWN0b3IuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C24046D4C6E242179CF529970086E39Cfbcom_-- From nobody Fri Jan 12 12:26:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06761241F8 for ; Fri, 12 Jan 2018 12:26:02 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 w5UH_hE_B_y1 for ; Fri, 12 Jan 2018 12:26:00 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44E941200FC for ; Fri, 12 Jan 2018 12:26:00 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id u42so7524787qte.7 for ; Fri, 12 Jan 2018 12:26:00 -0800 (PST) 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=KgBClCMxzOoFvMDyZ4Gg+9LkAufVnW2Ifecq5W5Q6Rs=; b=mMKdo0RJwtoczqseg5PM5im0+g46lOKcbUNn/ZM/Z6/VMRLkwwgYzrcBoYnTJoiP5z pQT+q2d3NcqX+U7PpfXyQ55w3VpedUN3cB8+oEHJAd9IFIRDsw37LVRLQjRbbTReHYeQ ikn8PgaK6/jt/zhVLqKnicEcxe5eL2KkCFP7jg3VLbEF9mVjlmdl2FXwoczJfBygWxz+ keG/i2rq17Os1zOa6JBDuMALE4gApjqGYTR46UU2IPgo48bQISyGQbqNhyVSoUkBxn5x T3WE67+aJemGxTccqTHRN3vwJuItB6k4pkhOG0FICLgWDgLr6whI8/9sOkFSOdbSSJjq yghw== 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=KgBClCMxzOoFvMDyZ4Gg+9LkAufVnW2Ifecq5W5Q6Rs=; b=OInvPOfzxp2+t6PqJYFYEh2VjMJEYifa6EkFU/9+qnKTelXPRlBTBJJvBtrXerShYu dTs6mYSVlZbnYXtUCrnP+ATt2AAY6MmFdkqV0bY2D8zf9QKaxilb7NDzZd4beQc3IECz VN08CaJYGjSpdw70MHBRl7wXGO7r61h3yiK4HWMeBFXntvxQIKMZZvwg3yRdxbuOjoaS p1fnoOUlGIps48uBKB254iieQnJR2ccnWKnT1SjXkjN2qGY9TqDDO/xh35/DHJ0zBavf me8+O4cBbtFVR0f68UnzMkJGDEBi4za6VIzCG/gxmia1SA3IW6kJ9TzabK30s/OI/9PI MVlQ== X-Gm-Message-State: AKwxytdG6Z3ceAX7IqfyOhqQX7aEMz5BMGrP1b0ZE6Ag6HTGilIbbNbw 7Kgh+ULIzJ+LIT+cnXXudxD98LwtPSgpBktjq8FmUI1BmQU= X-Google-Smtp-Source: ACJfBotUmx5tRB48kIJq8bXD0TUXhmb4upfime/1jZsIsJnqcfb3KKXMgpjU0Um78J+AfvVemvA81tP5W+4jwHO32wg= X-Received: by 10.200.49.231 with SMTP id i36mr3451213qte.116.1515788759142; Fri, 12 Jan 2018 12:25:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.156.209 with HTTP; Fri, 12 Jan 2018 12:25:58 -0800 (PST) In-Reply-To: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> From: Victor Vasiliev Date: Fri, 12 Jan 2018 15:25:58 -0500 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114774208bcadb05629a12d1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 12 Jan 2018 20:26:03 -0000 --001a114774208bcadb05629a12d1 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema wrote: > We have a prototype implementation in Picoquic in which the connection ID > can be split so some bits are random and some bits are used for routing to > a specific server -- thanks Igor for that. It makes for nice experiments, > but it is a denial of service waiting to happen. For example, attackers > could set the bits in such a way as to target a specific server in a pool, > or they could learn which connections are on the same server and use that > later for some kind of same server attack. It would be better if that > information was not in clear text. In fact, the picoquic implementation use > a callback to ask for the new value -- presumably from the router. That > callback could return anything, including an encrypted value. > Indeed. Besides DOS concerns, there's also desire to preserve privacy across connection migration. > On the other hand, it is not clear to me that we need full encryption. For > example, assume that the server that needs a connection ID can ask it from > the router. The router could pick one at random, make sure that it is > properly documented in the routing tables and that there is no collision, > and then pass it back to the server. No encryption needed, but of course > lots of state. > This is in fact fairly painful from operational standpoint. > If the router does not want to keep the state, it can indeed create a > connection ID by encrypting a tuple. But it does not > follow that the encryption needs to be 128 bits. For example, it could use > a 64 bit algorithm like Blowfish. > > So I am not sure that we actually need to change the length. And I am a > bit concerned by the incremental overhead if the connection ID suddenly > becomes very large. > Well, the general idea I was considering goes like this: assume F(x) is a block cipher, and H(x) is a hash function the load balances uses to route packets. Then the LB computes F(CID), and checks if it's formatted as . If it is well-formed, route based on server-ID or H(server-ID), otherwise route based on H(CID). This way, the server-specified CIDs are tamper-proof in a sense that based on the usual assumptions about block ciphers, you can't do better than rolling a random CID and bypassing the check with probability 2^-N. This of course, requires large N, and if you're running a lot of servers, have a lot of clients, it's very hard to fit everything into 64 bits. Another idea is that you just always compute = F(CID), and just do H(server entropy). This is also secure and allows the server to create unlinkable "come back to me" connection IDs while only sharing the key between the LB and the server, but assumes you don't want to be clever with your server IDs and just hash on them. Both of them suffer from the problem that F(x) has to be 64-bit, which leads into an uncomfortably exciting territory of non-standard crypto constructions (since all block ciphers made and standardized by IETF in this century have 128-bit blocks as far as I know), where you end up either using older stuff like Blowfish or using FPE techniques -- both of which are going to be slower than hardware AES. I do very much agree with the overhead concern, though, this is a tough question. --001a114774208bcadb05629a12d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On T= hu, Jan 11, 2018 at 9:47 PM, Christian Huitema <huitema@huitema.net&= gt; wrote:
    =20 =20 =20
    We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value.
    <= /div>

    Indeed.=C2=A0 Besides DOS concerns, t= here's also desire to preserve privacy across connection migration.
    =C2=A0
    On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state.

    This is in fact fairly painful from operational s= tandpoint.
    =C2=A0
    If the router does not want to keep the state, it can indeed create a connection ID by encrypting a <nonce, server-ID> tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large.

    Well= , the general idea I was considering goes like this: assume F(x) is a block= cipher, and H(x) is a hash function the load balances uses to route packet= s.=C2=A0 Then the LB computes F(CID), and checks if it's formatted as &= lt;server-ID, client nonce, N zeroes>.=C2=A0 If it is well-formed, route= based on server-ID or H(server-ID), otherwise route based on H(CID).=C2=A0= This way, the server-specified CIDs are tamper-proof in a sense that based= on the usual assumptions about block ciphers, you can't do better than= rolling a random CID and bypassing the check with probability 2^-N.=C2=A0 = This of course, requires large N, and if you're running a lot of server= s, have a lot of clients, it's very hard to fit everything into 64 bits= .

    Another idea is that you just always compute <= ;server entropy, client entropy> =3D F(CID), and just do H(server entrop= y).=C2=A0 This is also secure and allows the server to create unlinkable &q= uot;come back to me" connection IDs while only sharing the key between= the LB and the server, but assumes you don't want to be clever with yo= ur server IDs and just hash on them.

    Both of them = suffer from the problem that F(x) has to be 64-bit, which leads into an unc= omfortably exciting territory of non-standard crypto constructions (since a= ll block ciphers made and standardized by IETF in this century have 128-bit= blocks as far as I know), where you end up eithe= r=C2=A0using older stuff like Blowfish or using FPE tec= hniques -- both of which are going to be slower than hardware AES.

    I do very much agree with the overhead concern, though, th= is is a tough question.
    --001a114774208bcadb05629a12d1-- From nobody Fri Jan 12 17:06:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BA4126B6E for ; Fri, 12 Jan 2018 17:06:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 r_kAe1CHlhe4 for ; Fri, 12 Jan 2018 17:06:50 -0800 (PST) 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 593D81250B8 for ; Fri, 12 Jan 2018 17:06:50 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id m19so3248174ywh.12 for ; Fri, 12 Jan 2018 17:06:50 -0800 (PST) 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=jf1wF2kuR+QWY9wu+uyrLCUHHXSf6DqiedT2cac3E/8=; b=PJeFwDtJtx1iyYBZ3J+ds/wN3bJj1I/dlaPyiWMsRsOy6z/hOHZYTdLUnOlbS8IZDp 3PqlsYtJQnYv2kxn6GFHXg8ndJw9BHabYDyufcnc0MINDpUQHMCBy/CGseVA4xbGZQSR VumEYzz64YMnS971z4hxTyxQzMB5verqh7/is3F9+E4W7RVAEMkQU6mY9tKWWxgx/3SR +Vfc+8DfENhrDg6G5LYX626U2qObZFFeHOJPPM2Avj6nS5LkcTT4LMVX3EapLs7vAWYT vKIrcoKw3y5s39HrP6bcEgK21nTCSz4gFduCP+sGbywhQgAhCYG4ejl3S3B9i4GPxhKp HKNA== 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=jf1wF2kuR+QWY9wu+uyrLCUHHXSf6DqiedT2cac3E/8=; b=DgTakB0oCjqR/blzd9PyJ7Yy+4453fpURNOj6FY7eY4fl5rAUZWDA11ACAutHot8+h J66GG5UbC+K9/B9sP2E8e4emQqzTRr6W53n2yFHc1K7jRNIxOA3mVvuTiZSJE+mXQAOb MlDVYHfyXO1uB7aCxMI6Y8WOv4SDVmuoyrw3eSo2RbnazSqvBMIEIzndNHWltimgpvQF vMHzzjD3BnXuhMmrjMdcNdlOCe5afPTMQ2sQYhrlSktfHiv4s0Lm4LhNeABRjAnP0hct 9Adxiiq61P9WRZCjm+8yxVeIxlSHuSaH3o4sNAwym3O4Fcwz8HIPioBr4Lh1H3VFkat0 kbXw== X-Gm-Message-State: AKwxytdRXfE3lwI3fTIx+dPSRIRRiz0b2c1aWpW7PhDAN/mbD+wUkQCO j5UpbeKEhRaDsmYOOssRk9O92kvj+G6DIueLIfxwEntW X-Google-Smtp-Source: ACJfBotSG2OLP7KCB25OY94m71U33roM2OqgwHlkbJx646t2NVbvyRPoD5PJHve8afg63d6bRIMAeK0uglAflElbrE0= X-Received: by 10.129.87.130 with SMTP id l124mr9940642ywb.139.1515805609166; Fri, 12 Jan 2018 17:06:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.58.1 with HTTP; Fri, 12 Jan 2018 17:06:48 -0800 (PST) In-Reply-To: References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> From: Jana Iyengar Date: Fri, 12 Jan 2018 17:06:48 -0800 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Victor Vasiliev Cc: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113aa1ece2c18605629dfedd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Jan 2018 01:06:53 -0000 --001a113aa1ece2c18605629dfedd Content-Type: text/plain; charset="UTF-8" I'm not entirely convinced of the overhead concern. In the common HTTP case, we expect server->client to not carry CIDs, so this is a NOP in the commonly bandwidth-limited case. I do think that this makes CID generation at servers substantially simpler -- you can simply add 1 to the current CID to generate a new one, and encryption makes it unlinkable to the previous one. This is a substantial benefit. On Fri, Jan 12, 2018 at 12:25 PM, Victor Vasiliev wrote: > On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema > wrote: > >> We have a prototype implementation in Picoquic in which the connection ID >> can be split so some bits are random and some bits are used for routing to >> a specific server -- thanks Igor for that. It makes for nice experiments, >> but it is a denial of service waiting to happen. For example, attackers >> could set the bits in such a way as to target a specific server in a pool, >> or they could learn which connections are on the same server and use that >> later for some kind of same server attack. It would be better if that >> information was not in clear text. In fact, the picoquic implementation use >> a callback to ask for the new value -- presumably from the router. That >> callback could return anything, including an encrypted value. >> > > Indeed. Besides DOS concerns, there's also desire to preserve privacy > across connection migration. > > >> On the other hand, it is not clear to me that we need full encryption. >> For example, assume that the server that needs a connection ID can ask it >> from the router. The router could pick one at random, make sure that it is >> properly documented in the routing tables and that there is no collision, >> and then pass it back to the server. No encryption needed, but of course >> lots of state. >> > > This is in fact fairly painful from operational standpoint. > > >> If the router does not want to keep the state, it can indeed create a >> connection ID by encrypting a tuple. But it does not >> follow that the encryption needs to be 128 bits. For example, it could use >> a 64 bit algorithm like Blowfish. >> >> So I am not sure that we actually need to change the length. And I am a >> bit concerned by the incremental overhead if the connection ID suddenly >> becomes very large. >> > > Well, the general idea I was considering goes like this: assume F(x) is a > block cipher, and H(x) is a hash function the load balances uses to route > packets. Then the LB computes F(CID), and checks if it's formatted as > . If it is well-formed, route based on > server-ID or H(server-ID), otherwise route based on H(CID). This way, the > server-specified CIDs are tamper-proof in a sense that based on the usual > assumptions about block ciphers, you can't do better than rolling a random > CID and bypassing the check with probability 2^-N. This of course, > requires large N, and if you're running a lot of servers, have a lot of > clients, it's very hard to fit everything into 64 bits. > > Another idea is that you just always compute entropy> = F(CID), and just do H(server entropy). This is also secure and > allows the server to create unlinkable "come back to me" connection IDs > while only sharing the key between the LB and the server, but assumes you > don't want to be clever with your server IDs and just hash on them. > > Both of them suffer from the problem that F(x) has to be 64-bit, which > leads into an uncomfortably exciting territory of non-standard crypto > constructions (since all block ciphers made and standardized by IETF in > this century have 128-bit blocks as far as I know), where you end up > either using older stuff like Blowfish or using FPE techniques -- both of > which are going to be slower than hardware AES. > > I do very much agree with the overhead concern, though, this is a tough > question. > --001a113aa1ece2c18605629dfedd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I'm not entirely convinced of the overhead concern. In= the common HTTP case, we expect server->client to not carry CIDs, so th= is is a NOP in the commonly bandwidth-limited case.
    I do think that thi= s makes CID generation at servers substantially simpler -- you can simply a= dd 1 to the current CID to generate a new one, and encryption makes it unli= nkable to the previous one. This is a substantial benefit.


    On Fri, Jan 12, 2018 at 12:25 PM, Victor Vasiliev <vasilvv@go= ogle.com> wrote:
    On Thu, Jan 11, 2018 at 9:47 PM, Christian Huitema = <huitema@huitem= a.net> wrote:
    =20 =20 =20
    We have a prototype implementation in Picoquic in which the connection ID can be split so some bits are random and some bits are used for routing to a specific server -- thanks Igor for that. It makes for nice experiments, but it is a denial of service waiting to happen. For example, attackers could set the bits in such a way as to target a specific server in a pool, or they could learn which connections are on the same server and use that later for some kind of same server attack. It would be better if that information was not in clear text. In fact, the picoquic implementation use a callback to ask for the new value -- presumably from the router. That callback could return anything, including an encrypted value.
    <= /div>

    Indeed.=C2=A0 Besides DOS conc= erns, there's also desire to preserve privacy across connection migrati= on.
    =C2=A0
    <= div bgcolor=3D"#FFFFFF" text=3D"#000000"> On the other hand, it is not clear to me that we need full encryption. For example, assume that the server that needs a connection ID can ask it from the router. The router could pick one at random, make sure that it is properly documented in the routing tables and that there is no collision, and then pass it back to the server. No encryption needed, but of course lots of state.

    This is in fact fairly painful from operat= ional standpoint.
    =C2=A0
    If the router does not want to keep the state, it can indeed create a connection ID by encrypting a <nonce, server-ID> tuple. But it does not follow that the encryption needs to be 128 bits. For example, it could use a 64 bit algorithm like Blowfish.

    So I am not sure that we actually need to change the length. And I am a bit concerned by the incremental overhead if the connection ID suddenly becomes very large.

    Well, the general idea I was considering goes like this: assume F(x) is = a block cipher, and H(x) is a hash function the load balances uses to route= packets.=C2=A0 Then the LB computes F(CID), and checks if it's formatt= ed as <server-ID, client nonce, N zeroes>.=C2=A0 If it is well-formed= , route based on server-ID or H(server-ID), otherwise route based on H(CID)= .=C2=A0 This way, the server-specified CIDs are tamper-proof in a sense tha= t based on the usual assumptions about block ciphers, you can't do bett= er than rolling a random CID and bypassing the check with probability 2^-N.= =C2=A0 This of course, requires large N, and if you're running a lot of= servers, have a lot of clients, it's very hard to fit everything into = 64 bits.

    Another idea is that you just always comp= ute <server entropy, client entropy> =3D F(CID), and just do H(server= entropy).=C2=A0 This is also secure and allows the server to create unlink= able "come back to me" connection IDs while only sharing the key = between the LB and the server, but assumes you don't want to be clever = with your server IDs and just hash on them.

    Both o= f them suffer from the problem that F(x) has to be 64-bit, which leads into= an uncomfortably exciting territory of non-standard crypto constructions (= since all block ciphers made and standardized by IETF in this century have = 128-bit blocks as far as I know), where you end up X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 13 Jan 2018 04:53:39 -0000 --089e08288ceceaa2ee0562a1292b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m corcerned about the overhead. In the p2p use case, there=E2=80= =99s no need for encoding any routing information into the connection ID, and since every node just handles a small number of connections, even 4 bytes would be more than enough to distinguish between connections. I can see the use case for 128 bit connection IDs, but in order to reduce the overhead for other applications, we should either do some kind of negotiation or a varlen encoding. On Sat 13. Jan 2018 at 09:12, Christian Huitema wrote= : > On 1/12/2018 3:06 PM, Jana Iyengar wrote: > > I'm not entirely convinced of the overhead concern. In the common HTTP > > case, we expect server->client to not carry CIDs, so this is a NOP in > > the commonly bandwidth-limited case. > > Not just the transmission overhead. You are also increasing the memory > footprint of the connection context, which stores at least 2 CNX-ID, and > maybe more if we want to support migration. > > But I agree that this is not the end of the world. > > Also, following Victor's message, I was doing the maths on the size of > the ID. 64 bits allows for 24 bits of server ID, 32 bits of client > nonce, and 8 bits of zero -- for checking. 8 bits check will still let > 0.4% of forged packets through, which is probably OK since the server > acts as a backstop. 24 bits would work for 16M servers, which should be > OK, but assumes that servers have a unique serial ID, which is not > necessarily OK. Then 32 bits look like they allow 4G connections per > server, but we start seeing collisions after 65K connections per server, > which seems not good. So, yes, 64 bits probably will be very tight if we > want the router to be stateless. > > > I do think that this makes CID generation at servers substantially > > simpler -- you can simply add 1 to the current CID to generate a new > > one, and encryption makes it unlinkable to the previous one. This is a > > substantial benefit. > > Yes, you can do that without relying on a secure random generator, and > thus without exposing more of the state of the crypto PRNG. Which is > nice. Another advantage, if the router can reliably map connection-ID to > servers, then we don't need to have the same reset secret for every serve= r. > > Just one request. If we do make a change, please go for a fixed size. > > -- Christian Huitema > > > > > > --089e08288ceceaa2ee0562a1292b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I=E2=80=99m corcerned about the overhead. In the p2p= use case, there=E2=80=99s no need for encoding any routing information int= o the connection ID, and since every node just handles a small number of co= nnections, even 4 bytes would be more than enough to distinguish between co= nnections.
    I can see the use case for 128 bit connec= tion IDs, but in order to reduce the overhead for other applications, we sh= ould either do some kind of negotiation or a varlen encoding.

    On Sat 13. Jan 2018 at 09:12, Christian Huitema= <huitema@huitema.net> wro= te:
    On 1/12/2018 3:06 PM, Jana Iyen= gar wrote:
    > I'm not entirely convinced of the overhead concern. In the common = HTTP
    > case, we expect server->client to not carry CIDs, so this is a NOP = in
    > the commonly bandwidth-limited case.

    Not just the transmission overhead. You are also increasing the memory
    footprint of the connection context, which stores at least 2 CNX-ID, and maybe more if we want to support migration.

    But I agree that this is not the end of the world.

    Also, following Victor's message, I was doing the maths on the size of<= br> the ID. 64 bits allows for 24 bits of server ID, 32 bits of client
    nonce, and 8 bits of zero -- for checking. 8 bits check will still let
    0.4% of forged packets through, which is probably OK since the server
    acts as a backstop. 24 bits would work for 16M servers, which should be
    OK, but assumes that servers have a unique serial ID, which is not
    necessarily OK. Then 32 bits look like they allow 4G connections per
    server, but we start seeing collisions after 65K connections per server, which seems not good. So, yes, 64 bits probably will be very tight if we want the router to be stateless.

    > I do think that this makes CID generation at servers substantially
    > simpler -- you can simply add 1 to the current CID to generate a new > one, and encryption makes it unlinkable to the previous one. This is a=
    > substantial benefit.

    Yes, you can do that without relying on a secure random generator, and
    thus without exposing more of the state of the crypto PRNG. Which is
    nice. Another advantage, if the router can reliably map connection-ID to servers, then we don't need to have the same reset secret for every ser= ver.

    Just one request. If we do make a change, please go for a fixed size.

    -- Christian Huitema





    --089e08288ceceaa2ee0562a1292b-- From nobody Sun Jan 14 14:41:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565F012D882 for ; Sun, 14 Jan 2018 14:41:05 -0800 (PST) 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 8yyk4Sh3Ni-b for ; Sun, 14 Jan 2018 14:41:03 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 01EAD12D88D for ; Sun, 14 Jan 2018 14:41:03 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id o64so7166587oia.9 for ; Sun, 14 Jan 2018 14:41:02 -0800 (PST) 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=aa13f3FqjCc6sva80BwWZaINciktH+rL2htuAyTazeo=; b=qO22XG7Y7oqR8xxVtkRaRx64PcRbr/FI7ooKFXpMp8YpH43wBxZlwN1OkERVZ2jr0Q UPFbFKKsAeeSCZLiPASEfiDhxHn1xj4OojqC905tJQlZONDTh5EnDRwA+HooZ/rQNPBJ YEnxawNPF1BTpmBS85raNVCEvxuGlSQNGhOINNiV1SZy4WmHR7eMl3w9vVOtH9NSLj8A CiNipUF+YkNQVqsAIrxiYCPXaxw8Igt298Yo9HYLbXoxvIFkXTyXaPuEfvk+6Vjq52bT 87THh5IJvU96CnGV6dFiMtk/Vb06Zd6vYxjhrqUEm5mnCUAs7sVEUtlymQ1GGRrZ2AkM xBkQ== 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=aa13f3FqjCc6sva80BwWZaINciktH+rL2htuAyTazeo=; b=saXIHTvtXeHogUmAm+H+s3GRE1NNe6sDmOQtL9+i3NM135nd9z7UhQaxPEakGSeB7u erQKMmKE2QEuS3mi//qxzwbg7PCUEgdF7esBFlzhTcTcY7R6pUPze8EzeO9PWi/DuseA S/7oz8fZkhqCAJ+xrQNRLcJQyn3D30tGYCZwWpSUIXpK2SBCnw3aesGTOiX/nJ60xLYR GsLqQ9bYBWcJhUN4d9PnOXcSJvIc9almd0Ak215wwlqzcOzIGAyPExJHc4c/0N+7+cxv PybmuCLWnwPiElEXdNObWo2tGTvFUZ+yAVHS29p+FVZP0UVAXV/EgO+IcOuPHfLZETwV W0HA== X-Gm-Message-State: AKwxyteeTmISNxZSw/YDwNrKQkF17ZoNme65vCOqwJQU/Knvi1AyAoBQ dnaCs6ZjEh9Wd/lO9dayvY9HZn9D+tZ2mdq8s3g= X-Google-Smtp-Source: ACJfBoshPQJWfHsatAdbeIPvhqSK8+UmmEKZo0h6E8y+QfJhYTdUl1+WJbUHkGO705C50ZzcFQjEL8BtnHUcFV3V048= X-Received: by 10.202.56.139 with SMTP id f133mr4184292oia.28.1515969662172; Sun, 14 Jan 2018 14:41:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Sun, 14 Jan 2018 14:41:01 -0800 (PST) In-Reply-To: <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> From: Martin Thomson Date: Mon, 15 Jan 2018 09:41:01 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Roberto Peon Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jan 2018 22:41:05 -0000 I am reminded again that intermediation is why we can't have nice things. Yes, you are right, an intermediary cannot perfectly propagate flow control state. That means that even if either endpoint does what it can to avoid a deadlock, the intermediary might end up creating that deadlock anyway. In that case, the most expedient solution is to terminate the dependent stream and start over. In part, it's the ignorance of the intermediary that causes this particular problem. If the intermediary was aware of the protocol details then it might be able to recognize and avoid these situations, but that seems a little too much to expect of intermediaries. Ruling out the entire class of intermediary that operates purely at the transport layer is extremely harsh. What is more likely here is that we describe this situation, explain that it is impossible to prevent in the presence of intermediation, and explain how to kill the right streams in order to ensure forward progress doesn't stall indefinitely. I'd caution against an over-reliance on BLOCKED-style messages because they will mark the blocked stream as a problem, where the best way to proceed is to kill dependent streams. That is, the blocked stream is the one most likely to hold critical state; killing that might not unbind the blockage. But again, identifying the right stream to kill requires a degree of additional sophistication, effectively tracking the dependency graph. What seems most likely - at least in the hq case - is that requests will have the timers and those are what will get killed. That works better if compression updates are on separate streams from requests, but the other mechanisms work reasonably well too. On Sat, Jan 13, 2018 at 5:01 AM, Roberto Peon wrote: > The transport *CANNOT* provide ordering guarantees w.r.t. prioritization = because flows are end-to-end, whereas connections are point to point. > Flow-control, being a property of flows, ends up being asserted end-to-en= d though the mechanism at each hop is point-to-point. > > Consider the =E2=80=98standard=E2=80=99 client->proxy->server topology. > If the server asserts flow control, the proxy must respect it. > As the client<->proxy hop is asynchronous from the proxy<->server hop in = most circumstances with a loadbalancing (i.e. shared flow) proxy, the proxy= cannot guarantee flow-control window will be available for sending to the = server even when flow control window is available from the client<->proxy. > > Preemption/cancellation/retry, the addition of more resources, or finer m= anagement of resources can be used to resolve the (transitive) deadlock. > > > The sub-case of compression may be solvable without solving the general c= ase as compression is point-to-point. > -=3DR > > > On 1/12/18, 8:04 AM, "QUIC on behalf of Mirja K=C3=BChlewind" wrote: > > I disagree. I think it can be good to provide the transport hints abo= ut dependencies in application data which then could be used by the transpo= rt to optimize the sent-out scheduling, but I don=E2=80=99t think the trans= port should provide guarantees for ordered processing between streams. For = me the whole point of having streams in the transport is to resolve depende= ncies between independent data. > > Therefore, I think it would probably be good to mention this deadlock= problem in the main draft but I don=E2=80=99t think we should add strict p= riorities as a transport feature to QUIC. There are several ways how an app= lication can avoid (don=E2=80=99t have dependencies by using the same strea= m for dependent data or wait until data has be sent before sending dependen= t data) or resolve (read all streams and implement an additional applicatio= n layer buffer) such a deadlock and these should be explained in the applic= ability document respectively. > > My 2c, > Mirja > > > > Am 10.01.2018 um 23:42 schrieb Martin Thomson : > > > > On Thu, Jan 11, 2018 at 9:39 AM, Jana Iyengar wrot= e: > >> Yes, I think there's easy misinterpretation here -- something I re= alized > >> today as I've had conversations about this. What I meant was speci= fically at > >> the API between the app and the transport, at the sender. This is = basically > >> saying that to avoid deadlock due to dependencies across streams, = the > >> transport write API must allow the app to express strict prioritie= s. > > > > Ahh, excellent, then I think at least we two are in agreement. It > > seems like there is an emerging acceptance of the problem and propo= sed > > approach, I guess we might start considering how to address it. > > > > I think that this needs to be in the main spec. Failing to documen= t > > this sort of pitfall could be fatal. Does anyone disagree? > > > > > From nobody Mon Jan 15 01:41:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346E012D942 for ; Mon, 15 Jan 2018 01:41:49 -0800 (PST) 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 nSBYgW-jINHQ for ; Mon, 15 Jan 2018 01:41:47 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 7C4B712D885 for ; Mon, 15 Jan 2018 01:41:47 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id t20so801885ote.11 for ; Mon, 15 Jan 2018 01:41:47 -0800 (PST) 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=h2mak2NOwgIEhPwAvVgXc5pvv1hGIPis74SSm7Dg1Lg=; b=Cy9BsiOTmnZAcoguopnvRmMC4jJeD71g4htBdqtU+Hv+gJIrg9qFlXxUp9iUFYEAK2 ZImwi0Ykoe+KBzLbEOcCJAGs4Cx/2Z2JZgqth2quboy1btY6b1/thJ+9s1tBFRyVgmH0 8pR400jIyFWwFAxus+etc986ckiiyqXaqCxhw5sSLtM9kuQu9iVpKkpWLXu/WLBHcqA3 R1kr1v6AKrvk4IkiB/H0ZQ3LXxZCgMDiFLEy0BV6duTlb+Pcky2B2zHE9Va6TpUmUE0z VdBP1CKVR/J5Ila3DsNB0AiDA/fZY03SJVfDhXulYPC3Ejl5ZVx8h1UmaQvGTFtirfRc d0mw== 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=h2mak2NOwgIEhPwAvVgXc5pvv1hGIPis74SSm7Dg1Lg=; b=iDE5rnbupqW1hjj6a07hoCKQj5x/fzX/ZrpQdsPr7IhlMOcGf2qiUxTfvC/VJ1LiqG jPYJXx4BisLmbrJu+ACVdaWa0mBzq5KeTJx4rBSqcRmdMNbyY0/VinIhk4SOKZUnWRwj Ce6UJs39esvu8QzFL6OEV0J3RmnMFPR/0WWdcy0wCMq4K7ueXeQ/C5jAoWa2oCbfXQkZ bDuhLXQ+9uCBjgL5EQuYcwFBdq6aHiACW/IsIHTgwXAL+u1/oZ1KPQlzSjQWVyGp6eAo 3hrzDa80A5XewmOgT5KhY7kS++EXhSvK2daLv1Y+zlQWjXXfUwyGiiO/NyI8nEOSQZlg u/lw== X-Gm-Message-State: AKwxytc6tZcc9fw9R5WUNX6ATgecxtOGkxvcPdmKbutvn6KeGiFaRdmu i/TCbS9SQoQUcS5B6eo41lxqlTPeV7cmCv2oqLY= X-Google-Smtp-Source: ACJfBov3TIc/N0AQxOjngh5Q3OzGkawrYyufAoPmSVjNbcmr/HUGb7NUI70BCzwo7LQ3GQVgLxnPJB8to136kENkbSg= X-Received: by 10.157.85.233 with SMTP id z38mr21046893oti.16.1516009306698; Mon, 15 Jan 2018 01:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Mon, 15 Jan 2018 01:41:45 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 15 Jan 2018 20:41:45 +1100 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Victor Vasiliev Cc: 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: Mon, 15 Jan 2018 09:41:49 -0000 Hi Victor, I've opened an issue for this here: https://github.com/quicwg/base-drafts/issues/1052 On Fri, Jan 12, 2018 at 10:16 AM, Victor Vasiliev wrot= e: > Hi everyone, > > In the current version of QUIC, the connection ID size is fixed to be a > 64-bit opaque blob, and that is set as an invariant in the protocol. > > I=E2=80=99ve looked into possibility of using a connection ID to encode t= he specific > server details into it (to provide stability of the connection in case of > load balancing changes, especially BGP flaps for anycast IPs), and have > chatted about this with other people I knew were interested in this. It > seems like 64 bits might be too small for this purpose, and we might want= to > leave an opportunity to extend the connection ID size. > > The basic idea is that you want to be able to: > > Store some routing metadata in the connection ID. > Have some entropy that allows distinguish users with identical routing > metadata. > Have a checksum to ensure the validity of routing information > Encrypt the information above to prevent disclosing the route information > and allow generating uncorrelatable connection IDs. > > There are two underlying issues here. The first problem is that all of t= his > does not fit well into 64 bits, and you have to seriously compromise on t= he > strength of the checksum (which is bad especially if you want it to be a = MAC > rather than a checksum). The second problem is that encrypting 64-bit > values fast is actually fairly hard since the block ciphers easily availa= ble > in hardware have 128-bit block size, and the performance requirements on > load balancers are tighter than on servers. > > In other words, having a 128-bit connection ID provides for an easy secur= e > way to generate unlinkable connection IDs on migration. > > So, the problem we=E2=80=99re trying to solve is that the connection ID i= s too > small. There are two questions I believe the working group should answer= at > this point: > > Do we want to address this problem at this point in standardization proce= ss? > If we don=E2=80=99t address this problem right now, how do we structure t= he standard > in a way that we can extend the connection ID in the future? > > There are multiple ways to solve the problem of making connection ID larg= er. > One is to just add extra bit to the =E2=80=9Comit connection ID=E2=80=9D = field to allow > 128-bit connection IDs. Another approach is to allow connection ID size = to > be explicitly specified by the server, and then assume that the load > balancer knows that size and no one else on the path needs to read it. > > There=E2=80=99s also a question of how much of connection IDs do middlebo= xes > (excluding load balancers and other boxes owned by the same entity as eit= her > client or server) need to know. We could go for both =E2=80=9Cmiddleboxe= s should be > always able to read the entire ID=E2=80=9D and =E2=80=9Cmiddleboxes shoul= d not read > connection IDs at all options=E2=80=9D, but I think there=E2=80=99s also = a room for more > flexible formulations like =E2=80=9Cmiddleboxes always get first 64 bits = and they > have useful entropy to distinguish connections=E2=80=9D. > > -- Victor. From nobody Mon Jan 15 02:24:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7284F12DA0A for ; Mon, 15 Jan 2018 02:24:07 -0800 (PST) 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 xElNuVmEEccE for ; Mon, 15 Jan 2018 02:24:05 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0833E12DA2B for ; Mon, 15 Jan 2018 02:24:02 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id f6so12548708ioh.8 for ; Mon, 15 Jan 2018 02:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YBsBv7mOR8/tpm5Y7MhTbhlYwPOLWxudu1QKlBbQVEI=; b=kGCcsxF1JuIfBEeeHOnOgHPNozSTNe0HUXZRto1BpuWQJM//ejpKc+QqSXJ4xwk87H OorwvJnjZvq8Q/LV0KuGE72B7FAryunbe2PxIueJURAj0hQMos1w4+0sUS/VXlCZk4EK 2sOp+6w4RRuN34FZslIwG1FE4Egqq+fJJaSNywe5OaM8ysZ9wK/2X1/Xt3+IPcwEjrC6 fqpyJ6tvBRFbPOS3EXs0glYj8qeDL32TnTpQhYFzz9sKt3sxBSxSAPC/6Srhf0h3NJBf mMdqDNQi7u9zxB3Asw4tBSJhJRzVjEOAqD0x8GvhkxCSuqA3FD7KYplu8FQhiHUuuFov u+Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YBsBv7mOR8/tpm5Y7MhTbhlYwPOLWxudu1QKlBbQVEI=; b=f21ISoVTBRinaOLU0mW93DSfR7zfFAiY3nddWBMaWNUuQgDZOHqr5g6h4hj6ZwmHlp z4B1jfZDKBjR5MB4QEZJwx+IOZWx5hon5Gwgk951p/hhWjumpZTNcspmDNKXNK9+IQW6 FNe3DcPr+V9CtZ/VJ5b9jtpAdNdmmd20sNldNMvcIXP3SmYyDUqY9WNzSFH7Tf79sMdT 6zZ3yH4gPMp//wZpO+CKJwMJaWrZiAHRdEKe0LeWZMg/E3/OGMh011dXk0hy+73R3WK1 W/Z0FFVgcqYMJrpA2JxfzZxdyibREFYE9WP0WfsIlFMw/EwbUdpg3krQygDJPG4vAW3W AJiw== X-Gm-Message-State: AKwxyteiBPYonNxwDy5+t7tJSmxGEzrDDOXBxRkxFrojnOadSZOFsyDu naCFIqaMCwiNYBm0/C8P1pQZULtREWtIkthhawAvWQ== X-Google-Smtp-Source: ACJfBou6LjDGlyghsyorrped+ZC4s1OtGeYI4rTTeAwT58vXnTmVHm85z9WBGmg2Ffx/xRGDEpmUuwYjVYlDgCGHeo0= X-Received: by 10.107.168.25 with SMTP id r25mr13209016ioe.16.1516011841325; Mon, 15 Jan 2018 02:24:01 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 15 Jan 2018 05:24:00 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 15 Jan 2018 05:24:00 -0500 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Martin Thomson , Victor Vasiliev Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11427bca470f9c0562ce038e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Jan 2018 10:24:07 -0000 --001a11427bca470f9c0562ce038e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m corcerned about the overhead. In the p2p use case, there=E2=80= =99s no need for encoding any routing information into the connection ID, and since every node just handles a small number of connections, even 4 bytes would be more than enough to distinguish between connections. This is true. In some cases you might want a long routing ID in p2p, but messages are routed inside established connections where each node has only a few =E2=80=9Cphysical=E2=80=9D connections and each message has a large n= umber of possible targets. Having both a connection ID and a long internal routing ID, and the auth tag would be a lot to carry for short status messages. I earlier suggested a possible varlen extension to 64 bits. An alternative is to have the client always connect with 128-bits and have the server respond with a connection id of chosen size. Having a 128-bit client ID that only exists during handshake ought to be always enough. It could also be used for fast rejection of invalid connection attempts by placing some hashed knowledge in the ID, which is deployment specific. Or it could provide priority access during a DoS scenario. The server can choose an established connection ID length that is agreeable with the infrastructure, which could be down to a single byte - which still allows for single port client usage with little overhead. This is especially useful on micro-controller deployments where a UDP header might be skipped. Routers can assume a fixed size connection ID because the servers will use something the routers can understand. I am a bit concerned about connection migration because a new path might need a different kind of connection ID both in size and in encoding. Simply using the next NEW_CONNECTION_ID might not be optimal because the routers on the new path might be different. --001a11427bca470f9c0562ce038e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    I=E2=80=99m corcerned about the overhead. In the p2p use = case, there=E2=80=99s no need for encoding any routing information into the= connection ID, and since every node just handles a small number of connect= ions, even 4 bytes would be more than enough to distinguish between connect= ions.

    This is true. In some cases = you might want a long routing ID in p2p, but messages are routed inside est= ablished connections where each node has only a few =E2=80=9Cphysical=E2=80= =9D connections and each message has a large number of possible targets. Ha= ving both a connection ID and a long internal routing ID, and the auth tag = would be a lot to carry for short status messages.

    I earlier suggeste= d a possible varlen extension to 64 bits. An alternative is to have the cli= ent always connect with 128-bits and have the server respond with a connect= ion id of chosen size.

    Having a 128-bit client ID that only exists du= ring handshake ought to be always enough. It could also be used for fast re= jection of invalid connection attempts by placing some hashed knowledge in = the ID, which is deployment specific. Or it could provide priority access d= uring a DoS scenario.

    The server can choose an established connection= ID length that is agreeable with the infrastructure, which could be down t= o a single byte - which still allows for single port client usage with litt= le overhead. This is especially useful on micro-controller deployments wher= e a UDP header might be skipped. Routers can assume a fixed size connection= ID because the servers will use something the routers can understand.

    <= p>I am a bit concerned about connection migration because a new path might = need a different kind of connection ID both in size and in encoding. Simply= using the next NEW_CONNECTION_ID might not be optimal because the routers = on the new path might be different.

    --001a11427bca470f9c0562ce038e-- From nobody Mon Jan 15 22:02:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE5D126C2F for ; Mon, 15 Jan 2018 22:02:42 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 G3rt-kfEDQ1s for ; Mon, 15 Jan 2018 22:02:41 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C2B124D68 for ; Mon, 15 Jan 2018 22:02:40 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id i1so97709qtj.8 for ; Mon, 15 Jan 2018 22:02:40 -0800 (PST) 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=8idVlZ4PMuizF34le8ExvD02PyogG0RzqDCxc5JyTRI=; b=p5cNm/mDW1NgwXcDXH/cPdMI0KZnKztZk32i6Px4nzwvtsMiexH4pmhSzTPJmbmYiF ybk/miSZRjxyAtStIKybPwEE9o3zetEOYT1ptenvdrASxAQbMVzBeC7wqNsJkwG4NthS V+ENM353L00Ic8LfG4z/2MxLn9WVGlUVuw4/VBOvOFhH0iifFn72ru5G4pqpJlB2Qh9T w+yG5FoksFJDYXqD6ONGFQ7ijZR1m5QiKmAplB0X1PdRO728DOBgH8SrpIn0prCuQbqe 8D89C5MFbqpXCMDoFEr986spHSMl5A2FGFl1kEGUhYXpms6XYkO+vIJSW9xHeBgNKZ9v VDqg== 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=8idVlZ4PMuizF34le8ExvD02PyogG0RzqDCxc5JyTRI=; b=qCjKydWj31nN39tnyTDKcsvMr8Gy2HVhAcnE7eKaeSBEHz18BWRzQJj3vWbR/w3wMG sDFbAj+5+PfWmPkgA5fI1X0CCUWcuJJZpY7FTGRgCQm3Cy/Fn2+M8ltvcwLiE0u+8NaG 2GM2AmLVSHhJ7BHYBML6PX5h2mmxhL9dHDIxscE0iZG9kew275L1K0GzrL4YnwCkLU2h YEvLRTyEbJmaqWA8B8M1wVfcfbJ9Fa4GWq17GCjevDB+blBSdAeyTWl8fSCSLnvZwClr WEwOTU8L2Uh5wpPsNOlV9s8GMe69jvgGf8jnBWUr3Vi1kcJGr9WrjKXWjqk77wC5p8kM VKUg== X-Gm-Message-State: AKwxytcidCCtQPieXIdtRbanWGfalAFk2Xh0GzckSA38cYNWz/jdFtaK pC5XqgPnswiFMzsn4mhpQmRJMIiG1eU5a9KuR+TFbV2N X-Google-Smtp-Source: ACJfBos5uxm8NNanobKFSd5G880pnEoVDFlSRl+E4SmXhyej0aikIZk5982lliVDiuvG7GC7U7hPhJDuLSwB1J4Y3OE= X-Received: by 10.200.18.136 with SMTP id y8mr21372345qti.175.1516082559549; Mon, 15 Jan 2018 22:02:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.156.209 with HTTP; Mon, 15 Jan 2018 22:02:38 -0800 (PST) In-Reply-To: References: <1142e1ee-ae7b-b0be-625a-4136c6085c08@huitema.net> <38830ad8-b6d7-1539-56d2-ccf8be3483bf@huitema.net> From: Victor Vasiliev Date: Tue, 16 Jan 2018 01:02:38 -0500 Message-ID: Subject: Re: Increasing QUIC connection ID size To: Marten Seemann Cc: Christian Huitema , IETF QUIC WG , Jana Iyengar Content-Type: multipart/alternative; boundary="089e08289ffc6a31a40562de7a52" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Jan 2018 06:02:42 -0000 --089e08289ffc6a31a40562de7a52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 12, 2018 at 11:53 PM, Marten Seemann wrote: > I=E2=80=99m corcerned about the overhead. In the p2p use case, there=E2= =80=99s no need for > encoding any routing information into the connection ID, and since every > node just handles a small number of connections, even 4 bytes would be mo= re > than enough to distinguish between connections. > I can see the use case for 128 bit connection IDs, but in order to reduce > the overhead for other applications, we should either do some kind of > negotiation or a varlen encoding. > We already vary the CID length in header (0 bits vs 64 bits), so if we decide to make a 64/128 switch, I would consider that to be more of just adding another length option. --089e08289ffc6a31a40562de7a52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On F= ri, Jan 12, 2018 at 11:53 PM, Marten Seemann <martenseemann@gmail.c= om> wrote:
    I=E2=80=99m corcerned about the overhead. In the p2p use case, there= =E2=80=99s no need for encoding any routing information into the connection= ID, and since every node just handles a small number of connections, even = 4 bytes would be more than enough to distinguish between connections.
    =
    I can see the use case for 128 bit connection IDs, but in= order to reduce the overhead for other applications, we should either do s= ome kind of negotiation or a varlen encoding.

    We already vary the= CID length in header (0 bits vs 64 bits), so if we decide to make a 64/128= switch, I would consider that to be more of just adding another length opt= ion.
    --089e08289ffc6a31a40562de7a52-- From nobody Tue Jan 16 16:35:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776EC12EB60 for ; Tue, 16 Jan 2018 16:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDxPGiYEUlq0 for ; Tue, 16 Jan 2018 16:35:55 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0106.outbound.protection.outlook.com [104.47.41.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 5EB161270A3 for ; Tue, 16 Jan 2018 16:35:55 -0800 (PST) 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=jLv8HdmqawXxBr2UviLR9rTSqSuJ/gBt3D5NXJA5tX0=; b=Uv5kup5qaevoFLbGYjqvk+kCNiRwqvIN0ht/C89ZPT6YYw///oNFf4/bJOKP6RKXtk/uU0ct5almBUle3DnAxC17BenwQCY37pyROLJXsBelIlsDjn1DPIsUeZn5E/VFIjYeg62iEKMluXsznBkU+HTsqjzs80Mh+NbZKtJPD5A= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0146.namprd21.prod.outlook.com (10.173.199.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.428.4; Wed, 17 Jan 2018 00:35:53 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0428.002; Wed, 17 Jan 2018 00:35:53 +0000 From: Nick Banks To: IETF QUIC WG Subject: Definition of Recovery Period End Thread-Topic: Definition of Recovery Period End Thread-Index: AdOPKyC5dkpgelaZSFyTiB2jNW8J3g== Date: Wed, 17 Jan 2018 00:35:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-01-17T00:35:52.0403266Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:2::2ba] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0146; 7:KjtWvlaQ8MNCfTS7PSYcBwo8Y9TTBHY6Rq2mYDFb1ua6GsCfDnBUeQXjima11pwe9WM2g02SJBRVdR0miG8HMRTYbmF1qSa8HFbCYW3wG74gfdLqrn+cdGQIvYTwWsMmS1rhfayej+n9rod8G9GPHoqYn07WIn5qvURrmIVVltSz5+kWQygU98aeC4KOWP27cePhNUAx5o4SQYwBtybL5nqgO2kulTMlfKQujLNi895ABvgM67LBu109RecH1kqP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 125630a8-e55b-437e-d463-08d55d42443c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:BN6PR21MB0146; x-ms-traffictypediagnostic: BN6PR21MB0146: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231040)(2400039)(944501161)(6055026)(61426038)(61427038)(6041268)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR21MB0146; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:BN6PR21MB0146; x-forefront-prvs: 0555EC8317 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(366004)(396003)(39860400002)(189003)(199004)(55016002)(10090500001)(6306002)(9686003)(54896002)(6506007)(68736007)(53936002)(74316002)(6436002)(22452003)(7736002)(33656002)(2906002)(7696005)(5660300001)(316002)(3280700002)(3660700001)(97736004)(8676002)(14454004)(6116002)(790700001)(6916009)(81156014)(10290500003)(8936002)(81166006)(8990500004)(106356001)(105586002)(2900100001)(25786009)(86612001)(102836004)(77096006)(99286004)(86362001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0146; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: iwUHX1OjXlBHhWT190vQBm2ed6NfOIxF/6quKGRjHuop6J92nOa6A+QFzBwFuBYJ9ogIg+lu+1/1rSN05doYaw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178ECF15AA5E99508B897F3B3E90BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 125630a8-e55b-437e-d463-08d55d42443c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 00:35:53.5292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0146 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Jan 2018 00:35:57 -0000 --_000_BN6PR21MB0178ECF15AA5E99508B897F3B3E90BN6PR21MB0178namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Asking this on here per recommendation on GitHub: According to the spec, recovery starts with detection of a lost packet and = ends with the acknowledgement of a single, newly sent packet. Why isn't rec= overy ending only after all the information in the frames that were lost pr= ior to the recovery period have been acknowledged? This way would seem more= inline to what TCP does today. For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame were= lost, why shouldn't recovery last until all that data had been resent and = acknowledged? Thanks, - Nick Banks --_000_BN6PR21MB0178ECF15AA5E99508B897F3B3E90BN6PR21MB0178namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Asking this on here per recommendation on GitHub:

     

    According to the spec, recovery starts with detectio= n of a lost packet and ends with the acknowledgement of a single, newly sen= t packet. Why isn’t recovery ending only after all the information in= the frames that were lost prior to the recovery period have been acknowledged? This way would seem more inline to= what TCP does today.

     

    For instance, if 4 packets worth of STREAM frames an= d a MAX_DATA frame were lost, why shouldn’t recovery last until all t= hat data had been resent and acknowledged?

     

    Thanks,

    - Nick Banks

    --_000_BN6PR21MB0178ECF15AA5E99508B897F3B3E90BN6PR21MB0178namp_-- From nobody Tue Jan 16 17:10:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B5C12D88F for ; Tue, 16 Jan 2018 17:10:15 -0800 (PST) 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=Emmh5TRH; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=LneA97mV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-M1R5Dv5mWb for ; Tue, 16 Jan 2018 17:10:14 -0800 (PST) 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 AFE2812EBE9 for ; Tue, 16 Jan 2018 17:10:13 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0H14tE8002418; Tue, 16 Jan 2018 17:10:13 -0800 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=vs8EjlvN02mVGaXAnS0iNggtEvP0CRA/WUWpefVgLak=; b=Emmh5TRH97OWgG9cSwVrNN66/ANEYWU7tOcG8R3oWw/bABVSPl7sB2MQXhYdLgNXo5FC R3WksbrqQrZ+T3yvDYZbczeUgTcngV4q1bSwhtGKfKEDUKuJDv8zblJEjL2xyr8kca1U 6qQpMK1SxNXv4SLLyA5j+Dve87aVoi6Yg/I= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fhtg58krp-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Jan 2018 17:10:13 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.30) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 16 Jan 2018 20:10:11 -0500 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=vs8EjlvN02mVGaXAnS0iNggtEvP0CRA/WUWpefVgLak=; b=LneA97mVrafMIwuu7VuEmRbF8wdKko9x+KeEcIhb3AWXmNcpqwIPmAHJO8jXO84AyPGsd1Sv6zKL/Ssymj4ARQWesVnrIJHSryrfG5w6DqSQRcCe9RQQsAjQZwF2tIBx5bf0MB0J9s+1hN52Fq1+RSoweFd3ShvnlEjkgl5H+bI= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Wed, 17 Jan 2018 01:10:10 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0407.012; Wed, 17 Jan 2018 01:10:10 +0000 From: Subodh Iyengar To: Nick Banks , IETF QUIC WG Subject: Re: Definition of Recovery Period End Thread-Topic: Definition of Recovery Period End Thread-Index: AdOPKyC5dkpgelaZSFyTiB2jNW8J3gABBbbU Date: Wed, 17 Jan 2018 01:10:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:bb73] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:x/oosyNZ+uUBBlnYqM5EvclDxiVI6bBp+is4FrB56owzkTDClYKe56uec3upGh/5NC2CM7dpStH3dPGai52a990VDtF9JfyYAXTEKEqQxa5IGRcT5HKPrTC5HilLREbwIryjtRkeGCCbOUp9ZqR+3W6gYdfvuOf8y37xwTZDP4J4r8H9hhHQeWRELu0ix7PfPA9EfZsewQCs9ngBGurM0kBbbd8zB4K92XsOsoGjS1bhdTBKlxDqZfMNEmI1oD4j; 20:58vi1lH6CQH84wDkmjDigMSIT3XIGGE44pKaqugttCfSQZ25cCMLzxVIV9wC/v13SPRZNSj5lB9MG2fcaWXo73HDJr1hra5M+P9OPvMhFFPO0t9eIsPKf3JXF8WGGgDsyRaN36JtE0NmGmE1FY8LLbqobZFgi+NCl+dqg+RstcY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a83841a3-1eb2-4329-2a68-08d55d470e06 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040470)(2401047)(5005006)(8121501046)(3231023)(11241501184)(2400039)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041268)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR15MB1455; x-forefront-prvs: 0555EC8317 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(396003)(346002)(376002)(189003)(199004)(97736004)(19627405001)(54896002)(2900100001)(9686003)(6436002)(33656002)(25786009)(3280700002)(478600001)(86362001)(55016002)(106356001)(6246003)(2906002)(45080400002)(14454004)(316002)(99286004)(3660700001)(110136005)(2950100002)(76176011)(6606003)(1511001)(5660300001)(8936002)(53936002)(81156014)(81166006)(68736007)(74316002)(7736002)(8676002)(77096006)(7696005)(105586002)(229853002)(102836004)(8666007)(53546011)(6506007)(59450400001)(6116002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: BFO+uNyT4JdyOBvruUVFqqOCtofYCb/Gw1SM6HSGo/WCdNo+6hKxz95W9EwqLjekaigXuDTGoJNe7qxEecDclw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14559D2E94DED8AB176EC15AB6E90MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a83841a3-1eb2-4329-2a68-08d55d470e06 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2018 01:10:10.1201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-16_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Jan 2018 01:10:16 -0000 --_000_MWHPR15MB14559D2E94DED8AB176EC15AB6E90MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All of the loss recovery modes that QUIC has have the following property if packet n is lost, then packet n - 1 must also be lost. This is true both in the threshold and time reordering based recovery. A newly sent packet in loss is triggered by either sending a TLP or RTO. If you get an ack for a new packet without getting the acks for all the oth= er sent packets, QUICs threshold loss recovery will kick in and confirm tha= t the packets that were sent before were lost. So I believe you don't need to wait for all the information to be ACKed onc= e you get an ack for the latest packet. An argument could be made that the = ack for the new packet might not trigger loss of all the packets, however it will definitely trigger QUIC's early retrans= mit timer, which will trigger the future loss. Subodh ________________________________ From: QUIC on behalf of Nick Banks Sent: Tuesday, January 16, 2018 4:35:53 PM To: IETF QUIC WG Subject: Definition of Recovery Period End Asking this on here per recommendation on GitHub: According to the spec, recovery starts with detection of a lost packet and = ends with the acknowledgement of a single, newly sent packet. Why isn=92t r= ecovery ending only after all the information in the frames that were lost = prior to the recovery period have been acknowledged? This way would seem mo= re inline to what TCP does today. For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame were= lost, why shouldn=92t recovery last until all that data had been resent an= d acknowledged? Thanks, - Nick Banks --_000_MWHPR15MB14559D2E94DED8AB176EC15AB6E90MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    All of the loss recovery modes th= at QUIC has have the following property


    if packet n is lost, then packet = n - 1 must also be lost.


    This is true both in the threshol= d and time reordering based recovery.

    A newly sent packet in loss is triggered by either sending a TLP or RTO.

    If you get an ack for a new packe= t without getting the acks for all the other sent packets, QUICs threshold = loss recovery will kick in and confirm that the packets that were sent befo= re were lost.


    So I believe you don't need to wa= it for all the information to be ACKed once you get an ack for the latest p= acket. An argument could be made that the ack for the new packet might not = trigger loss

    of all the packets, however it wi= ll definitely trigger QUIC's early retransmit timer, which will trigger the= future loss.


    Subodh




    From: QUIC <quic-bounces= @ietf.org> on behalf of Nick Banks <nibanks@microsoft.com>
    Sent: Tuesday, January 16, 2018 4:35:53 PM
    To: IETF QUIC WG
    Subject: Definition of Recovery Period End
     

    Asking this on here per recommendation on GitHub:<= /p>

     

    According to the spec, recovery starts with detect= ion of a lost packet and ends with the acknowledgement of a single, newly s= ent packet. Why isn=92t recovery ending only after all the information in t= he frames that were lost prior to the recovery period have been acknowledged? This way would seem more inline to= what TCP does today.

     

    For instance, if 4 packets worth of STREAM frames = and a MAX_DATA frame were lost, why shouldn=92t recovery last until all tha= t data had been resent and acknowledged?

     

    Thanks,

    - Nick Banks

    --_000_MWHPR15MB14559D2E94DED8AB176EC15AB6E90MWHPR15MB1455namp_-- From nobody Tue Jan 16 17:57:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC1712EC22 for ; Tue, 16 Jan 2018 17:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LP-by-OoHvTS for ; Tue, 16 Jan 2018 17:57:14 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 CFFA512EC0D for ; Tue, 16 Jan 2018 17:56:58 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id c102so13253987itd.0 for ; Tue, 16 Jan 2018 17:56:58 -0800 (PST) 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=6tHpGvH8IAaBckOZ6eWwNSCWMjeH1JbtYYBBsU3V4Xg=; b=QIglgs3CFm3w2lAeztioISGQDmN0mMXDpB1dUreicUL7gb6UE2mKDhhgD0DyTwgsIG K8Fo79iIxctMKWZiidMEwpt3VPSBus+vVn5qH1IcC8d1liD9DPzhSArwoViJTNyfXQCZ rH2igOwrDYXLqZ9IMgy+rluZmdXxpTRM+TdHPCwk/mr2nzrGaNKywpRy5oi9Lv+ObDkw OVuZcbeeGxsASqFJYBZ/8fB+yhoEj0hPNVDAR+R1goM4/wUJCSKc9Rtybj49PvqTxo2b e5rEaOt7ZwsjpWcrP2Z4KUSM9UsSfbLLfOOntKbJ4duV7QoOUfKphZhzEEf74nDmRABV kLuw== 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=6tHpGvH8IAaBckOZ6eWwNSCWMjeH1JbtYYBBsU3V4Xg=; b=mMbw1hgGCxKORyr2VrXUFFpRC1hPF8IEMOLwOS0FP9Kj8qCGPOXuppdbdP15crLfqT y/qFPLpYRP1LSdw3mEQD8bsWhjdQxKx5/Q2hjsfTqOuWKFrHp0OGAESH7pOo2hgaydxD RGShMPDL/YgYnqdifD/AnzUhyxIvedpvdukeQdqB8K0NHM+MBLs4ebAWTafg8dGA1A6U EoMbm/8LYy53GM3JwSbA8rPBWit0rXoORG91JyrB73GUbvKDfUMTm82cnuu98YonhsB4 n/S4f68hw/XjoXc7q26V963TAFe0q1Jdwhs9vtoeQ7Xtboh7yE3j1vPvt9N+EsQOgdV3 RBnA== X-Gm-Message-State: AKwxyte3OVciuYlXbmtJZdZPbEpgor9w59AavaSWrAwxPxHk/+fiXlZ1 z9ZeifXMOhlVyPHhDj6gdqESBFqP91g6pNH1MuQkoQ== X-Google-Smtp-Source: ACJfBovNAK/sQVSLMZWnvYuPiBD9SUZ6T+jRGtzwJFjfe2l4McnUZoyHjej3OAl3HZeDsVQNt+HGSLIXEdxrQYqCkac= X-Received: by 10.36.73.102 with SMTP id z99mr22496840ita.72.1516154217908; Tue, 16 Jan 2018 17:56:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 16 Jan 2018 17:56:37 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 16 Jan 2018 20:56:37 -0500 Message-ID: Subject: Re: Definition of Recovery Period End To: Subodh Iyengar , Jana Iyengar Cc: Nick Banks , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c14e5e95c1780562ef297d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Jan 2018 01:57:18 -0000 --001a11c14e5e95c1780562ef297d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nick, this is a very good question. Initially, this was chosen because it was the most straightforward mapping of TCP's behavior. This has some pros and cons. The major con is that it makes direct comparison to TCP more difficult, particularly when loss rates are high. A positive is that QUIC can reduce it's CWND(and sending rate) more rapidly in the face of high loss and may provide more consistent performance in cases when the CWND is large, so observing a loss within an epoch is common= . The intent is that the QUIC approach to recovery is an ideal embodiment of the spirit of the original TCP algorithms for recovery. If we have any data that indicates they don't work well in practice, I'd be happy to consider changes to the recovery draft. On Tue, Jan 16, 2018 at 8:10 PM, Subodh Iyengar wrote: > All of the loss recovery modes that QUIC has have the following property > > > if packet n is lost, then packet n - 1 must also be lost. > > > This is true both in the threshold and time reordering based recovery. > > A newly sent packet in loss is triggered by either sending a TLP or RTO. > > If you get an ack for a new packet without getting the acks for all the > other sent packets, QUICs threshold loss recovery will kick in and confir= m > that the packets that were sent before were lost. > > > So I believe you don't need to wait for all the information to be ACKed > once you get an ack for the latest packet. An argument could be made that > the ack for the new packet might not trigger loss > > of all the packets, however it will definitely trigger QUIC's early > retransmit timer, which will trigger the future loss. > > > Subodh > > > > > ------------------------------ > *From:* QUIC on behalf of Nick Banks < > nibanks@microsoft.com> > *Sent:* Tuesday, January 16, 2018 4:35:53 PM > *To:* IETF QUIC WG > *Subject:* Definition of Recovery Period End > > > Asking this on here per recommendation on GitHub: > > > > According to the spec, recovery starts with detection of a lost packet an= d > ends with the acknowledgement of a single, newly sent packet. Why isn=E2= =80=99t > recovery ending only after all the information in the frames that were lo= st > prior to the recovery period have been acknowledged? This way would seem > more inline to what TCP does today. > > > > For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame > were lost, why shouldn=E2=80=99t recovery last until all that data had be= en resent > and acknowledged? > > > > Thanks, > > - Nick Banks > --001a11c14e5e95c1780562ef297d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nick, this is a very good question.

    Ini= tially, this was chosen because it was the most straightforward mapping of = TCP's behavior.

    This has some pros and cons.= =C2=A0 The major con is that it makes direct comparison to TCP more difficu= lt, particularly when loss rates are high.=C2=A0 A positive is that QUIC ca= n reduce it's CWND(and sending rate) more rapidly in the face of high l= oss and may provide more consistent performance in cases when the CWND is l= arge, so observing a loss within an epoch is common.

    The intent is that the QUIC approach to recovery is an ideal embodiment = of the spirit of the original TCP algorithms for recovery.=C2=A0 If we have= any data that indicates they don't work well in practice, I'd be h= appy to consider changes to the recovery draft.

    On Tue, Jan 16, 2018 at 8:10 PM, = Subodh Iyengar <subodh@fb.com> wrote:

    All of the loss recovery modes th= at QUIC has have the following property


    if packet n is lost, then packet = n - 1 must also be lost.


    This is true both in the threshol= d and time reordering based recovery.

    A newly sent packet in loss is triggered by either sending a TLP or RTO.

    If you get an ack for a new packe= t without getting the acks for all the other sent packets, QUICs threshold = loss recovery will kick in and confirm that the packets that were sent befo= re were lost.


    So I believe you don't need t= o wait for all the information to be ACKed once you get an ack for the late= st packet. An argument could be made that the ack for the new packet might = not trigger loss

    of all the packets, however it wi= ll definitely trigger QUIC's early retransmit timer, which will trigger= the future loss.


    Subodh




    From:= QUIC <quic-b= ounces@ietf.org> on behalf of Nick Banks <nibanks@microsoft.com>
    Sent: Tuesday, January 16, 2018 4:35:53 PM
    To: IETF QUIC WG
    Subject: Definition of Recovery Period End
    =C2=A0

    Asking this on here per reco= mmendation on GitHub:

    =C2=A0

    According to the spec, recov= ery starts with detection of a lost packet and ends with the acknowledgemen= t of a single, newly sent packet. Why isn=E2=80=99t recovery ending only af= ter all the information in the frames that were lost prior to the recovery period have been acknowledged? This way would seem more inline to= what TCP does today.

    =C2=A0

    For instance, if 4 packets w= orth of STREAM frames and a MAX_DATA frame were lost, why shouldn=E2=80=99t= recovery last until all that data had been resent and acknowledged?

    =C2=A0

    Thanks,

    - Nick Banks


    --001a11c14e5e95c1780562ef297d-- From nobody Wed Jan 17 13:44:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105C12D77B for ; Wed, 17 Jan 2018 13:44:00 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 6rLNITm0EmhI for ; Wed, 17 Jan 2018 13:43:59 -0800 (PST) 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 1672512D778 for ; Wed, 17 Jan 2018 13:43:59 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u21so9552636ywc.2 for ; Wed, 17 Jan 2018 13:43:59 -0800 (PST) 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=AW+u+ujdgKCYix0gUdQLGU9T435L78gAwtKu/m+T0oM=; b=UbahTxqQKYggLv3LWzP7XX8sqR50eRHqyx/bA0uGAOgxEyMLFAZ19JXwCdXIS23XXE hnK64V5bxgiJ0cc5cKGtqv3+U+ypY1RhA3JNy0rVBuKpgEetKhlWP+EPiu6SkCp7jhNT egnJ70cw+6Ht/AUAxGhF3Emb9RBvi/Wk1yQ6Sq6kjItBDT+lXehmamafDxkaF3VxDEOe QMv6p3HELonZ0HWbVYfzcYkBa8pA1bv0nYkkJ3z9rg1T5emBa0zRyosLJhwDjdtyOkYk b281cE9Sh8owraELcNzj4mHJcr7FAb6e9jDzQzrZ1khv+YJ9Cwz1DBLPuE1OEsx7G2Fk duXg== 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=AW+u+ujdgKCYix0gUdQLGU9T435L78gAwtKu/m+T0oM=; b=IRv97jukh+jZ6FsxMC7QJrUxD2p1waXHfifdOFAJCi04NZl2obPYTQ0L/7LiIY/Gw0 eRJY34nrU9hb6WsFz2mMdCRkS5hHVGRIKfpDImOtbsttYc2psiI+4XAWuciQTjvsXC8z oO0z+FF1/epV1uNckPdj1z+AyQnFsgXDAZoVBIWzSbFbA/M5KqV1LqmnOsjDSYhUe5qS +Y7UCIHNhEfyPZp/cOsazaKFjMvp4tUiIqspQFi73WUfH7DW/4Zp3tAhdKGTG0HlUIfd XPG4q9eYqhqQ5c1Zl3/JNSkqyDFFdZZ7aJf8Q07xW6IVudEjake7Zgr9gRDO+hjTxzQB 2ntw== X-Gm-Message-State: AKwxytdIyou3baA31Lv0Pnm76qAPU4IaCk1zQjWnfSLoReBXsbuiakvj 2u6aaLxCsJrmq2h3EDI+fDrlJPzIqrEe6BbpJNjoFw== X-Google-Smtp-Source: ACJfBosm688Sbo1hmf+xWWnLGT1n9BWAwaf7I+9yy34aYMdjz+LM4Ath9LZk9Fq5yrWNZj7j6FScyEsBpbaB4QGCZxw= X-Received: by 10.129.60.9 with SMTP id j9mr3900391ywa.315.1516225437787; Wed, 17 Jan 2018 13:43:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.58.1 with HTTP; Wed, 17 Jan 2018 13:43:57 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> From: Jana Iyengar Date: Wed, 17 Jan 2018 13:43:57 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: Martin Thomson Cc: Roberto Peon , QUIC WG Content-Type: multipart/alternative; boundary="001a1142e95c9f41ea0562ffbef9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Jan 2018 21:44:01 -0000 --001a1142e95c9f41ea0562ffbef9 Content-Type: text/plain; charset="UTF-8" We will discuss this at the interim, but one comment, inline. > In part, it's the ignorance of the intermediary that causes this > particular problem. If the intermediary was aware of the protocol > details then it might be able to recognize and avoid these situations, > but that seems a little too much to expect of intermediaries. Ruling > out the entire class of intermediary that operates purely at the > transport layer is extremely harsh. > > What is more likely here is that we describe this situation, explain > that it is impossible to prevent in the presence of intermediation, > and explain how to kill the right streams in order to ensure forward > progress doesn't stall indefinitely. > Exactly because intermediaries make things difficult, it's important to be certain that the intermediary behavior we are discussing is one that there's a strong argument for supporting. We have spent countless cycles on designing around uncertain and unknown intermediary behaviors in various parts of the IETF, and I don't want us to recreate these boogeymen. I think it's reasonable to rule out classes of middleboxes if we don't have strong arguments for supporting them. --001a1142e95c9f41ea0562ffbef9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    We will discuss this at the interim, = but one comment, inline.
    =C2=A0
    In part, it's = the ignorance of the intermediary that causes this
    particular problem.=C2=A0 If the intermediary was aware of the protocol
    details then it might be able to recognize and avoid these situations,
    but that seems a little too much to expect of intermediaries. Ruling
    out the entire class of intermediary that operates purely at the
    transport layer is extremely harsh.

    What is more likely here is that we describe this situation, explain
    that it is impossible to prevent in the presence of intermediation,
    and explain how to kill the right streams in order to ensure forward
    progress doesn't stall indefinitely.

    Exactly because intermediaries make things diff= icult,=C2=A0it's important to be certain that the intermediary behavior= we are discussing is one that there's a strong argument for supporting= . We have spent countless cycles on designing around uncertain and unknown = intermediary behaviors in various parts of the IETF, and I don't want u= s to recreate these boogeymen. I think it's reasonable to rule out clas= ses of middleboxes if we don't have strong arguments for supporting the= m.
    =C2=A0
    --001a1142e95c9f41ea0562ffbef9-- From nobody Wed Jan 17 14:37:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E888A12E3AE for ; Wed, 17 Jan 2018 14:37:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 aroW4ZTebNHf for ; Wed, 17 Jan 2018 14:37:07 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A12F12D875 for ; Wed, 17 Jan 2018 14:37:07 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id n7so6202693iob.0 for ; Wed, 17 Jan 2018 14:37:07 -0800 (PST) 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=NY5eI8Rq/NORM+duiXC6JXx2y1UqwytdLVNGXly2gm0=; b=kSoj85c2qoQKvxpGYQK6FD4t9pCpckKhvudURgJoeEPm3T10NuvCbMCxGEFtPg7Zso ZL9Maxssa+1GZnUBM2ObTwkkBZUbgJQUbEebkS0wZzw69Ntkd1GnGJVf6ziN4+32+XT3 8vhGcr12BFRDGUn5ydaK7RBOXGrBcriAtxXmGqPpKfNoKFp4mWAbVSa+W1ocR0B21KEZ b+PBrRC+M7YNW+vTIxkryp1vgjf/idrX66a/NRay61tju3+xjjQUx+SvSBo9cRhMrhaG 0zAo/q3QDc4IdEKLiXuFNzeN7FJU59Ed5ZX9ISyBbODqla5GaNXN4wZJqsQ89uRmZIYj pp+Q== 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=NY5eI8Rq/NORM+duiXC6JXx2y1UqwytdLVNGXly2gm0=; b=FX0DPsnLcIae8VwGGSLquf/3xB3mKxTtGKNlR6oiyYDMCpWXxu7pEEbGRn2HyOx00o JI4eszNtIidMidiluEEMOH11Whvnkv6tsGfJ4QZSWT+uaLckutoury0NCiddmKPPmJ6L O4FxjHEwhD1NcHxC/JTp/1ej0JVVH/WVp6Bn5wQYklXP5qlWi7bXNwXtNs6QuxcUmEmr rLmXhKarfuvLZ18WhpqAZ5RcTnD9w3RbSMKNZdxFr2CuUIUA1DhjsM50ziOZXazzEWgj i/97JApP1GO0nDewPxcrtNaHRSfAZcERhJYR0D3vZZ9SbBUzkrEI8/iQR4tlcjKgyFEQ x5cA== X-Gm-Message-State: AKwxytccyOn025JNLjQ/2SR4fqMNug3jmnjtON8BmrT1fnGhMciBYW22 Zc9lrsNGsCO3VTpbhM4ptNHCr5CbuTvO56lqIHHHJQ== X-Google-Smtp-Source: ACJfBovMnqzIiGYP0H9G+gyaz/i9PaASGDLn6kaYzuB9m9VxN/yOLcahNeZZXHeT1eg5viMIaczYYxDjMO1SYbR8DqY= X-Received: by 10.107.53.213 with SMTP id k82mr12430735ioo.170.1516228626380; Wed, 17 Jan 2018 14:37:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Wed, 17 Jan 2018 14:36:45 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> From: Ian Swett Date: Wed, 17 Jan 2018 17:36:45 -0500 Message-ID: Subject: Re: Deadlocking in the transport To: Jana Iyengar Cc: Martin Thomson , QUIC WG , Roberto Peon Content-Type: multipart/alternative; boundary="001a1144a1a6acf5a20563007ca9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Jan 2018 22:37:09 -0000 --001a1144a1a6acf5a20563007ca9 Content-Type: text/plain; charset="UTF-8" +1 million On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar wrote: > We will discuss this at the interim, but one comment, inline. > > >> In part, it's the ignorance of the intermediary that causes this >> particular problem. If the intermediary was aware of the protocol >> details then it might be able to recognize and avoid these situations, >> but that seems a little too much to expect of intermediaries. Ruling >> out the entire class of intermediary that operates purely at the >> transport layer is extremely harsh. >> >> What is more likely here is that we describe this situation, explain >> that it is impossible to prevent in the presence of intermediation, >> and explain how to kill the right streams in order to ensure forward >> progress doesn't stall indefinitely. >> > > Exactly because intermediaries make things difficult, it's important to be > certain that the intermediary behavior we are discussing is one that > there's a strong argument for supporting. We have spent countless cycles on > designing around uncertain and unknown intermediary behaviors in various > parts of the IETF, and I don't want us to recreate these boogeymen. I think > it's reasonable to rule out classes of middleboxes if we don't have strong > arguments for supporting them. > > --001a1144a1a6acf5a20563007ca9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    +1 million

    On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <jri@google.co= m> wrote:
    =
    We will discuss this at the interim, but one comment, = inline.
    =C2=A0
    In part, it's = the ignorance of the intermediary that causes this
    particular problem.=C2=A0 If the intermediary was aware of the protocol
    details then it might be able to recognize and avoid these situations,
    but that seems a little too much to expect of intermediaries. Ruling
    out the entire class of intermediary that operates purely at the
    transport layer is extremely harsh.

    What is more likely here is that we describe this situation, explain
    that it is impossible to prevent in the presence of intermediation,
    and explain how to kill the right streams in order to ensure forward
    progress doesn't stall indefinitely.

    Exactly because intermediaries make thin= gs difficult,=C2=A0it's important to be certain that the intermediary b= ehavior we are discussing is one that there's a strong argument for sup= porting. We have spent countless cycles on designing around uncertain and u= nknown intermediary behaviors in various parts of the IETF, and I don't= want us to recreate these boogeymen. I think it's reasonable to rule o= ut classes of middleboxes if we don't have strong arguments for support= ing them.
    =C2=A0

    --001a1144a1a6acf5a20563007ca9-- From nobody Wed Jan 17 23:21:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B204A12AF6E for ; Wed, 17 Jan 2018 23:21:38 -0800 (PST) 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 B67EOuIvDeST for ; Wed, 17 Jan 2018 23:21:37 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 534DE126D0C for ; Wed, 17 Jan 2018 23:21:37 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id a70so15027247oib.1 for ; Wed, 17 Jan 2018 23:21:37 -0800 (PST) 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=lTL3i5z7K8ZgAx2y1LCgmmap2DbY62EywSrRZVAUKjM=; b=Cse74eDNSm1Nr9ZGERD4dVJf7IqpZypl806wJW8Oc813Ty1zRyS14HAJDbrT5AkOeH C7b9V55MuKfSHAomg79HfxmDdU8a88Axx0EerdgbDvCi58fwxE8KajtIU9DKSpG1/44U mWUhvv8e2rBH0n1VaGVu2Mp8hvzeJaiCmQHTqCnbwkzPxg43SLnripia7t3CfMptktuS gRbq7pktNf9gWZRWnS+FMkjX2obSZ7sz5dem0cT63UmXJEMGOyM5pwa0VG/cJxJqvAnv YE7cp3XxAf5Cue/ZPD0FYmrReenD1dSvWMWKmNfRPgTThEXQ5xookj+HWl1CJaB0Vf0n VSoA== 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=lTL3i5z7K8ZgAx2y1LCgmmap2DbY62EywSrRZVAUKjM=; b=Kx8gzTSVAFu3s+hN10sHsDpNwzDGZya7oK2DKSrPAQEQVpT8zm226F/g3PqCn+TR9+ X5bGua199LXuqHEYGaTCs+J6mHXADphDMnSi+ji9oHktZjc9MInX1IR/JuJ3uAVz1/Kn ZWY4Z8/vwGu/gA3vGl2fuODeXVIBNl2ZdMQD8CUtbP9Vu4hXEmPuCmJICZgTxssCzmBm iD3aP+MiIEHiUNOawp1E5qUblIMbGQQzDBbdF/jV+nbOJnCVu8Z3n8tTJEP88WOlzH65 NZ7Cej/Tv8341jod6f1bNUHEOUWkiPRHRQV1DZaJ6HoAJucyMvb1BIzvSQ4n8VDQ9orz iVEg== X-Gm-Message-State: AKwxytfLT+iq880UCIyXi9L3gsryZnuAZilXKsnGVQN6QICbETvzdMmo 9IEr1CxkMDtI7xnMLI5K08KrOpyRLKigxOKS5ko= X-Google-Smtp-Source: ACJfBoshtHB9JyJ8mgLRbQERzcaBoX5ayy5nczXm8c6xPzazaKZAqZhjOBdSaG8UcAlLl6OdimynRx9GHVcMODkxg1w= X-Received: by 10.202.243.131 with SMTP id r125mr2492569oih.50.1516260096572; Wed, 17 Jan 2018 23:21:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Wed, 17 Jan 2018 23:21:35 -0800 (PST) In-Reply-To: References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> From: Martin Thomson Date: Thu, 18 Jan 2018 18:21:35 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: Ian Swett Cc: Jana Iyengar , QUIC WG , Roberto Peon 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, 18 Jan 2018 07:21:39 -0000 Yes, what Ian said (and more to what Jana said). I think that we've some proportion of the working group who are operating on one set of assumptions and another on a different set of assumptions on this subject. Until now, that didn't bother me much. After all, that's normal for a whole range of issues. Now there's a concrete problem, so let's dig into this properly. FWIW, I don't think that we'll resolve this particular issue in Melbourne, but I hope that we can at least start that process. This promises to be interesting. On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett wrote: > +1 million > > On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar wrote: >> >> We will discuss this at the interim, but one comment, inline. >> >>> >>> In part, it's the ignorance of the intermediary that causes this >>> particular problem. If the intermediary was aware of the protocol >>> details then it might be able to recognize and avoid these situations, >>> but that seems a little too much to expect of intermediaries. Ruling >>> out the entire class of intermediary that operates purely at the >>> transport layer is extremely harsh. >>> >>> What is more likely here is that we describe this situation, explain >>> that it is impossible to prevent in the presence of intermediation, >>> and explain how to kill the right streams in order to ensure forward >>> progress doesn't stall indefinitely. >> >> >> Exactly because intermediaries make things difficult, it's important to be >> certain that the intermediary behavior we are discussing is one that there's >> a strong argument for supporting. We have spent countless cycles on >> designing around uncertain and unknown intermediary behaviors in various >> parts of the IETF, and I don't want us to recreate these boogeymen. I think >> it's reasonable to rule out classes of middleboxes if we don't have strong >> arguments for supporting them. >> > > From nobody Thu Jan 18 01:29:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1FFB12EB21 for ; Thu, 18 Jan 2018 01:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 rGGKvA9FDM7d for ; Thu, 18 Jan 2018 01:29:18 -0800 (PST) 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 B81DE12EB19 for ; Thu, 18 Jan 2018 01:29:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zMdvJ0KkgzMnwY; Thu, 18 Jan 2018 10:29:16 +0100 (CET) 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 Ir6TjVZi3-Ql; Thu, 18 Jan 2018 10:29:15 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 18 Jan 2018 10:29:14 +0100 (CET) Subject: Re: Deadlocking in the transport To: Martin Thomson , Ian Swett Cc: Jana Iyengar , QUIC WG , Roberto Peon References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch> Date: Thu, 18 Jan 2018 10:29:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------9698D8E6ECEB2E76900D3EB9" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Jan 2018 09:29:20 -0000 This is a multi-part message in MIME format. --------------9698D8E6ECEB2E76900D3EB9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi all, while I agree that we need to decide which middlebox behavior we want to support, I don't really think this is a middlebox issue. If the transport you are using is offering you an interface where you can send data over independent streams (which was the goal to avoid HOL blocking) but the application sends not-independent data over the streams, it is an application-layer issue to handle that. Regarding middlebox behavior, I think we should support transport level proxies because especially in mobile networks where the link characteristics are quite different from the rest of the network this seems still to be the appropriate solution. However, I would wish that we could separate transport state from end-to-end payload encryption and would not need to terminate both... Mirja On 18.01.2018 08:21, Martin Thomson wrote: > Yes, what Ian said (and more to what Jana said). I think that we've > some proportion of the working group who are operating on one set of > assumptions and another on a different set of assumptions on this > subject. Until now, that didn't bother me much. After all, that's > normal for a whole range of issues. > > Now there's a concrete problem, so let's dig into this properly. > > FWIW, I don't think that we'll resolve this particular issue in > Melbourne, but I hope that we can at least start that process. This > promises to be interesting. > > On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett wrote: >> +1 million >> >> On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar wrote: >>> >>> We will discuss this at the interim, but one comment, inline. >>> >>>> >>>> In part, it's the ignorance of the intermediary that causes this >>>> particular problem. If the intermediary was aware of the protocol >>>> details then it might be able to recognize and avoid these situations, >>>> but that seems a little too much to expect of intermediaries. Ruling >>>> out the entire class of intermediary that operates purely at the >>>> transport layer is extremely harsh. >>>> >>>> What is more likely here is that we describe this situation, explain >>>> that it is impossible to prevent in the presence of intermediation, >>>> and explain how to kill the right streams in order to ensure forward >>>> progress doesn't stall indefinitely. >>> >>> >>> Exactly because intermediaries make things difficult, it's important to be >>> certain that the intermediary behavior we are discussing is one that there's >>> a strong argument for supporting. We have spent countless cycles on >>> designing around uncertain and unknown intermediary behaviors in various >>> parts of the IETF, and I don't want us to recreate these boogeymen. I think >>> it's reasonable to rule out classes of middleboxes if we don't have strong >>> arguments for supporting them. >>> >> >> > --------------9698D8E6ECEB2E76900D3EB9 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------9698D8E6ECEB2E76900D3EB9-- From nobody Thu Jan 18 11:28:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6912D80E for ; Thu, 18 Jan 2018 11:28:34 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 kCUf3otXkxKN for ; Thu, 18 Jan 2018 11:28:32 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512BD12D7FB for ; Thu, 18 Jan 2018 11:28:30 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id d11so26068272iog.5 for ; Thu, 18 Jan 2018 11:28:30 -0800 (PST) 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=v/kqoQ6UBUloXH8k3trXWoRxm1nZKOFaRyGnGnpcGB4=; b=ZD60/d5yS5NKaj6+g4DaqCH6NRrrPHoztgFkFDtcpuLeGcaQ+qjB/ZvrpSiZo8YpNE IJQCsdGRPvVuDLnZ/l74l2wMGhcj9D8PgrafgNAF88sTx6bhXiMIu0vOb/uRSF3pOQmZ Isa6xXhl2SpjYAm/ntH4rznOLgXKWTjzKj74ZjkNZnr2jx+NFbaGV3QSKMnbWOpbTyiP slYYPZinZ5M/ddbM+buKIAyR+ikfHzu5yezLe18htN1KX9WXqmgboocYCigeUoNdeTla 7ivCUTiInoIEXnQq2Q1tYEfOdpExaJ7YrjmzIkTdBTo+GYJRFaM7gfwH5FoGoElZTYVH uSnQ== 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=v/kqoQ6UBUloXH8k3trXWoRxm1nZKOFaRyGnGnpcGB4=; b=OLC0hLsq81RN9w3WNVmzb/V5Xvxpzc2LT2he+AeCQ4WXbQyacYsuQHcPVzD0dTrasW LTVI0fTwxr8BWWoMaDTuzE3f33WykKgRCDBl+fBmL7pKPnYcY+w39PbKEYPg+l0120Uq +EL0ufif/YeU7T2tU+ft7w/FTXFT2Q9iy1BYmG/llJs3ndIDsAPEof6TUK4c5EXfLzcx C8jiMHViBJScHcBMHgrCCjQgzY1ui9tixOz+yN+iGb6FptIyHPq44szlCKdIYF4kJW6o x0I6xOEE+tnAMmcxxIYYsDGtbFx6uMHHEUUJEHY2L7NpO5Ne5JlqGSYBzxoxoxTPtWP2 hL6Q== X-Gm-Message-State: AKwxytdW1h46W0hcknV0cyrFZxm08qtp5NfQ9QnwYD+9iUmJhYCdwvrD K3ZcKaq65dqeoiw9fsBUjGEb3n1461ShVml2FpoF X-Google-Smtp-Source: ACJfBosJLQ8+O9Th4yWZ/3rW+7Te6Ad22vBA/i5KvkuIMRmFuuMpcXoI9dP/2RPQSeVD68OCJpaQOWJ3gJ9yoq/pxn4= X-Received: by 10.107.161.147 with SMTP id k141mr46636798ioe.39.1516303709033; Thu, 18 Jan 2018 11:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.156.203 with HTTP; Thu, 18 Jan 2018 11:28:08 -0800 (PST) In-Reply-To: <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch> From: "Charles 'Buck' Krasic" Date: Thu, 18 Jan 2018 11:28:08 -0800 Message-ID: Subject: Re: Deadlocking in the transport To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Martin Thomson , Ian Swett , Jana Iyengar , QUIC WG , Roberto Peon Content-Type: multipart/alternative; boundary="001a1140fedaf3ba41056311f7a6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Jan 2018 19:28:35 -0000 --001a1140fedaf3ba41056311f7a6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [ speaking for myself only ] On Thu, Jan 18, 2018 at 1:29 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi all, > > while I agree that we need to decide which middlebox behavior we want to > support, I don't really think this is a middlebox issue. If the transport > you are using is offering you an interface where you can send data over > independent streams (which was the goal to avoid HOL blocking) but the > application sends not-independent data over the streams, it is an > application-layer issue to handle that. > > Depending on ones perspective, the congestion level flow control in QUIC could be seen as imposing cross-stream dependency. It is conflict between those transport dependencies and the application's inter-stream dependencies that leads to trouble. Perhaps it is a bit overly restrictive to define a stream interface that only supports truly independent application streams (?). > Regarding middlebox behavior, I think we should support transport level > proxies because especially in mobile networks where the link > characteristics are quite different from the rest of the network this see= ms > still to be the appropriate solution. However, I would wish that we could > separate transport state from end-to-end payload encryption and would not > need to terminate both... > > Sorry, but this particular example smells of a bogeyman to me (?). Isn't partitioning of the transport encryption scheme is pretty unlikely at this point? If so, doesn't it follow that using 'transport only proxies' to adapt to wireless link characteristics pretty infeasible, because in practice such network devices would not have access to transport level crypto keys? [ Unlike CDN operated proxies, which have the certs for their customer origins ]. > Mirja > > > > > On 18.01.2018 08:21, Martin Thomson wrote: > >> Yes, what Ian said (and more to what Jana said). I think that we've >> some proportion of the working group who are operating on one set of >> assumptions and another on a different set of assumptions on this >> subject. Until now, that didn't bother me much. After all, that's >> normal for a whole range of issues. >> >> Now there's a concrete problem, so let's dig into this properly. >> >> FWIW, I don't think that we'll resolve this particular issue in >> Melbourne, but I hope that we can at least start that process. This >> promises to be interesting. >> >> On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett wrote: >> >>> +1 million >>> >>> On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar wrote: >>> >>>> >>>> We will discuss this at the interim, but one comment, inline. >>>> >>>> >>>>> In part, it's the ignorance of the intermediary that causes this >>>>> particular problem. If the intermediary was aware of the protocol >>>>> details then it might be able to recognize and avoid these situations= , >>>>> but that seems a little too much to expect of intermediaries. Ruling >>>>> out the entire class of intermediary that operates purely at the >>>>> transport layer is extremely harsh. >>>>> >>>>> What is more likely here is that we describe this situation, explain >>>>> that it is impossible to prevent in the presence of intermediation, >>>>> and explain how to kill the right streams in order to ensure forward >>>>> progress doesn't stall indefinitely. >>>>> >>>> >>>> >>>> Exactly because intermediaries make things difficult, it's important t= o >>>> be >>>> certain that the intermediary behavior we are discussing is one that >>>> there's >>>> a strong argument for supporting. We have spent countless cycles on >>>> designing around uncertain and unknown intermediary behaviors in vario= us >>>> parts of the IETF, and I don't want us to recreate these boogeymen. I >>>> think >>>> it's reasonable to rule out classes of middleboxes if we don't have >>>> strong >>>> arguments for supporting them. >>>> >>>> >>> >>> >> --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1140fedaf3ba41056311f7a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    [ speaking for myself only ]

    On Thu, Jan 18, 2018 at 1:29 AM, Mirja K=C3= =BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> w= rote:
    Hi all,

    while I agree that we need to decide which middlebox behavior we want to su= pport, I don't really think this is a middlebox issue. If the transport= you are using is offering you an interface where you can send data over in= dependent streams (which was the goal to avoid HOL blocking) but the applic= ation sends not-independent data over the streams, it is an application-lay= er issue to handle that.


    Depending on ones perspective, the con= gestion level flow control in QUIC=C2=A0 could be seen as imposing cross-st= ream dependency.=C2=A0 =C2=A0It is conflict between those transport depende= ncies and the application's inter-stream dependencies that leads to tro= uble.=C2=A0 =C2=A0 Perhaps it is a bit overly restrictive to define a strea= m interface that only supports truly independent application streams (?).= =C2=A0 =C2=A0

    =C2=A0
    Regarding middlebox behavior, I think we should support transport level pro= xies because especially in mobile networks where the link characteristics a= re quite different from the rest of the network this seems still to be the = appropriate solution. However, I would wish that we could separate transpor= t state from end-to-end payload encryption and would not need to terminate = both...


    Sorry, but this particul= ar example smells of a bogeyman to me (?).=C2=A0 =C2=A0Isn't partitioni= ng of the transport encryption scheme is pretty unlikely at this point?=C2= =A0 =C2=A0If so, doesn't it follow that using 'transport only proxi= es'=C2=A0 to adapt to wireless link characteristics=C2=A0 pretty infeas= ible, because in practice such network devices would not have access to tra= nsport level crypto keys?=C2=A0 =C2=A0[ Unlike CDN operated proxies, which = have the certs for their customer origins ].

    =C2= =A0
    Mirja




    On 18.01.2018 08:21, Martin Thomson wrote:
    Yes, what Ian said (and more to what Jana said).=C2=A0 I think that we'= ve
    some proportion of the working group who are operating on one set of
    assumptions and another on a different set of assumptions on this
    subject.=C2=A0 Until now, that didn't bother me much.=C2=A0 After all, = that's
    normal for a whole range of issues.

    Now there's a concrete problem, so let's dig into this properly.
    FWIW, I don't think that we'll resolve this particular issue in
    Melbourne, but I hope that we can at least start that process.=C2=A0 This promises to be interesting.

    On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett <ianswett@google.com> wrote:
    +1 million

    On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar <jri@google.com> wrote:

    We will discuss this at the interim, but one comment, inline.


    In part, it's the ignorance of the intermediary that causes this
    particular problem.=C2=A0 If the intermediary was aware of the protocol
    details then it might be able to recognize and avoid these situations,
    but that seems a little too much to expect of intermediaries. Ruling
    out the entire class of intermediary that operates purely at the
    transport layer is extremely harsh.

    What is more likely here is that we describe this situation, explain
    that it is impossible to prevent in the presence of intermediation,
    and explain how to kill the right streams in order to ensure forward
    progress doesn't stall indefinitely.


    Exactly because intermediaries make things difficult, it's important to= be
    certain that the intermediary behavior we are discussing is one that there&= #39;s
    a strong argument for supporting. We have spent countless cycles on
    designing around uncertain and unknown intermediary behaviors in various parts of the IETF, and I don't want us to recreate these boogeymen. I t= hink
    it's reasonable to rule out classes of middleboxes if we don't have= strong
    arguments for supporting them.







    --
    =
    = Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

    --001a1140fedaf3ba41056311f7a6-- From nobody Thu Jan 18 11:29:42 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87F1A12D7ED for ; Thu, 18 Jan 2018 11:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 FqpEEO4fUwnI for ; Thu, 18 Jan 2018 11:29:38 -0800 (PST) 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 73A2D12778D for ; Thu, 18 Jan 2018 11:29:38 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id m19so12149452ywh.12 for ; Thu, 18 Jan 2018 11:29:38 -0800 (PST) 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=OQreIDJZYAZLFEHONVlBnfS8te0FWD+IDcoxZeJrDKQ=; b=R0pOPvCORbJxPljVhkCy7UrYCBYvqzqggXwIaC9XhmbiCbkZEtuuicRko1J/xQy+gA TvGQ/8ib+PXrCDT5AL+JZ6VaVWj6aDPqMZC3zfY4xx8DRAbticXoo3Lc96nTxIrYoc7c uAhX7e/XWxdQQklDlTZmyn0HJSFAROfss6XQ1dc51LQxJA0+FZUR7spda62pAUshxw6V x3DDYQyB0gSibqrLvMZ3tVEEfxqBxSEIiHn5/pNHGjJjI3RiKwaceoVaK9Wn4bXm0evy OuB2PFEtS2LbVP4scd+C5ciZ0ypLop2MlzwuCl4htJG860YEpj+VdrZdwa0snJqxGLGc e72g== 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=OQreIDJZYAZLFEHONVlBnfS8te0FWD+IDcoxZeJrDKQ=; b=B24PlSdqrpOkFRDdhY4Y0wqawJXI52dhD3m+a9+E2CmPCoit79+hl7cSJSETokd6c+ a6lk0jV9rS6WpVm86jzXr9rGE1TuPBf8IFwJM1n2FVhgjxPTBnZUfv9Wqawws/NAhr3V v/dSCezENfVEospHzfrxK54UoTrpYeCWPsoMB5HHV6mXuRrS34AKNqVPraICBxrvs73z 1e5cggUPL/bvLEJLuvXXZFvEDqiLbSImL5GzcW5OghZ8q3l6SivjJa955lz6+bJTJOpd 5w3lYhJwkj5Ra5ymxSsbhDlK+aLHB1cZHCktQ0Dkm+5oWMt/WqvrDTAYmWwT5ZBfSzAC CUjg== X-Gm-Message-State: AKwxytcv8+V9RPRx14u6MuuNHI1nEZ/ZNRoC6Aa+MF+C7S+EpadOlyQG 47m5BdDGFKPoXLAn/jiWHPokxUEYCEM/4kX9UO4Ktw== X-Google-Smtp-Source: ACJfBos2CIzgMN/W7KLrEuSafErF6LwHvIbz1tkNrUliqqzQ/7pqQazajgAqu7gLU5tKXWOkksZeNx0qjf6sCJ5qk5Y= X-Received: by 10.129.68.40 with SMTP id r40mr6704149ywa.371.1516303777237; Thu, 18 Jan 2018 11:29:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.58.1 with HTTP; Thu, 18 Jan 2018 11:29:36 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 18 Jan 2018 11:29:36 -0800 Message-ID: Subject: Re: Definition of Recovery Period End To: Ian Swett Cc: Subodh Iyengar , Nick Banks , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045ed28c043066056311fcf6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Jan 2018 19:29:40 -0000 --f403045ed28c043066056311fcf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Nick, To clarify, "recovery period" is defined in the context of loss recovery and congestion control. The congestion controller is expected to take congestion action on loss. However, it should be careful to hold off on future congestion actions until this action propagates through the network. More precisely, the Reno congestion controller will reduce its rate when the sender detects loss, and should only reduce its rate again if the new rate is too high... that is, another loss is detected on packets sent *after* the rate reduction. Feedback on the new rate takes about an RTT of time, and is measured as the time period between sending the first packet after a loss is detected to when that or a subsequently sent packet is acked. This is the recovery period. It is not meant to indicate when all losses are recovered from. Would it help to describe this in the draft? - jana On Tue, Jan 16, 2018 at 5:56 PM, Ian Swett wrote: > Nick, this is a very good question. > > Initially, this was chosen because it was the most straightforward mappin= g > of TCP's behavior. > > This has some pros and cons. The major con is that it makes direct > comparison to TCP more difficult, particularly when loss rates are high. = A > positive is that QUIC can reduce it's CWND(and sending rate) more rapidly > in the face of high loss and may provide more consistent performance in > cases when the CWND is large, so observing a loss within an epoch is comm= on. > > The intent is that the QUIC approach to recovery is an ideal embodiment o= f > the spirit of the original TCP algorithms for recovery. If we have any > data that indicates they don't work well in practice, I'd be happy to > consider changes to the recovery draft. > > On Tue, Jan 16, 2018 at 8:10 PM, Subodh Iyengar wrote: > >> All of the loss recovery modes that QUIC has have the following property >> >> >> if packet n is lost, then packet n - 1 must also be lost. >> >> >> This is true both in the threshold and time reordering based recovery. >> >> A newly sent packet in loss is triggered by either sending a TLP or RTO. >> >> If you get an ack for a new packet without getting the acks for all the >> other sent packets, QUICs threshold loss recovery will kick in and confi= rm >> that the packets that were sent before were lost. >> >> >> So I believe you don't need to wait for all the information to be ACKed >> once you get an ack for the latest packet. An argument could be made tha= t >> the ack for the new packet might not trigger loss >> >> of all the packets, however it will definitely trigger QUIC's early >> retransmit timer, which will trigger the future loss. >> >> >> Subodh >> >> >> >> >> ------------------------------ >> *From:* QUIC on behalf of Nick Banks < >> nibanks@microsoft.com> >> *Sent:* Tuesday, January 16, 2018 4:35:53 PM >> *To:* IETF QUIC WG >> *Subject:* Definition of Recovery Period End >> >> >> Asking this on here per recommendation on GitHub: >> >> >> >> According to the spec, recovery starts with detection of a lost packet >> and ends with the acknowledgement of a single, newly sent packet. Why is= n=E2=80=99t >> recovery ending only after all the information in the frames that were l= ost >> prior to the recovery period have been acknowledged? This way would seem >> more inline to what TCP does today. >> >> >> >> For instance, if 4 packets worth of STREAM frames and a MAX_DATA frame >> were lost, why shouldn=E2=80=99t recovery last until all that data had b= een resent >> and acknowledged? >> >> >> >> Thanks, >> >> - Nick Banks >> > > --f403045ed28c043066056311fcf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nick,

    To clarify, "recovery period= " is defined in the context of loss recovery and congestion control. T= he congestion controller is expected to take congestion action on loss. How= ever, it should be careful to hold off on future congestion actions until t= his action propagates through the network.=C2=A0

    M= ore precisely, the Reno congestion controller will reduce its rate when the= sender detects loss, and should only reduce its rate again if the new rate= is too high... that is, another loss is detected on packets sent *after* t= he rate reduction. Feedback on the new rate takes about an RTT of time, and= is measured as the time period between sending the first packet after a lo= ss is detected to when that or a subsequently sent packet is acked. This is= the recovery period. It is not meant to indicate when all losses are recov= ered from.

    Would it help to describe this in the d= raft?

    - jana

    On Tue, Jan 16, 2018 at 5:56 PM, Ian Swett = <ianswett@google.com> wrote:
    Nick, this is a very good question.

    Initially, this was chosen because it was the most straightforward mappin= g of TCP's behavior.

    This has some pros and co= ns.=C2=A0 The major con is that it makes direct comparison to TCP more diff= icult, particularly when loss rates are high.=C2=A0 A positive is that QUIC= can reduce it's CWND(and sending rate) more rapidly in the face of hig= h loss and may provide more consistent performance in cases when the CWND i= s large, so observing a loss within an epoch is common.

    The intent is that the QUIC approach to recovery is an ideal embodime= nt of the spirit of the original TCP algorithms for recovery.=C2=A0 If we h= ave any data that indicates they don't work well in practice, I'd b= e happy to consider changes to the recovery draft.

    On Tue, Jan 16, 2018 at 8:10 PM, Subodh Iyengar <subodh@fb.com&g= t; wrote:

    All of the loss recovery modes th= at QUIC has have the following property


    if packet n is lost, then packet = n - 1 must also be lost.


    This is true both in the threshol= d and time reordering based recovery.

    A newly sent packet in loss is triggered by either sending a TLP or RTO.

    If you get an ack for a new packe= t without getting the acks for all the other sent packets, QUICs threshold = loss recovery will kick in and confirm that the packets that were sent befo= re were lost.


    So I believe you don't need t= o wait for all the information to be ACKed once you get an ack for the late= st packet. An argument could be made that the ack for the new packet might = not trigger loss

    of all the packets, however it wi= ll definitely trigger QUIC's early retransmit timer, which will trigger= the future loss.


    Subodh




    From: QUIC <quic-bounces@ietf.org> on behalf of Nick Banks <nibanks@microsoft.= com>
    Sent: Tuesday, January 16, 2018 4:35:53 PM
    To: IETF QUIC WG
    Subject: Definition of Recovery Period End
    =C2=A0

    Asking = this on here per recommendation on GitHub:

    =C2=A0<= /p>

    Accordi= ng to the spec, recovery starts with detection of a lost packet and ends wi= th the acknowledgement of a single, newly sent packet. Why isn=E2=80=99t re= covery ending only after all the information in the frames that were lost p= rior to the recovery period have been acknowledged? This way would seem more inline to= what TCP does today.

    =C2=A0<= /p>

    For ins= tance, if 4 packets worth of STREAM frames and a MAX_DATA frame were lost, = why shouldn=E2=80=99t recovery last until all that data had been resent and= acknowledged?

    =C2=A0<= /p>

    Thanks,=

    - Nick = Banks



    --f403045ed28c043066056311fcf6-- From nobody Thu Jan 18 11:33:24 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A57C127011 for ; Thu, 18 Jan 2018 11:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9V8Xst6fDxR for ; Thu, 18 Jan 2018 11:33:20 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0100.outbound.protection.outlook.com [104.47.42.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAF112D7EA for ; Thu, 18 Jan 2018 11:33:17 -0800 (PST) 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=+RMpCsj4CLulpHlaAWnFMe+5XwPvVU5w5EP5Rg39Eqw=; b=icE85j/0tvm7fGHVYyOj+s5BjrPziMFAyuDOozkFLWgw3N+p6RythAI/kexhNB8Ob3e/3fQufMEKpyoq7Q6emtHepKtt9HetmrC9I70vw0WzqON9gUJ6K2JY2sU0WiL25kc8WApFLLhP+Dj/DxbQcOiCzyjlYX7ayDbxCfA89eY= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0835.namprd21.prod.outlook.com (10.173.205.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.444.5; Thu, 18 Jan 2018 19:33:16 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0444.004; Thu, 18 Jan 2018 19:33:16 +0000 From: Nick Banks To: Jana Iyengar , Ian Swett CC: Subodh Iyengar , IETF QUIC WG Subject: RE: Definition of Recovery Period End Thread-Topic: Definition of Recovery Period End Thread-Index: AdOPKyC5dkpgelaZSFyTiB2jNW8J3gABBbbUAAHMQoAAVxEDAAAAE3qA Date: Thu, 18 Jan 2018 19:33:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-01-18T19:33:14.5687041Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b::2ba] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0835; 7:pQBnnVLklpXu6br+qyn47Cdhdzv3KOxD8FZClogya7LqZ5mFIR7S9JPoJdjIEdwuwsAGS69unCwKI1gT6WiV+wtVDXnCGnXuG7JxMfBHoNYxcduV0rd+Etj3Do/K5w1480ulTaAF8mlDrOCV17bNqTsw0bWzGrAGe3lR5W6h+lMQ3hs/w6rxlzNIjj8FG806SI9DHpyVa5loU94B5kG26qzpNPtRNHkKJP4tV83IS40bVuBANEthUaUTRf3jRc8V x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1217939e-613c-43ca-96ab-08d55eaa525c x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:BN6PR21MB0835; x-ms-traffictypediagnostic: BN6PR21MB0835: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040495)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231046)(2400066)(944501161)(6055026)(61426038)(61427038)(6041282)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR21MB0835; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:BN6PR21MB0835; x-forefront-prvs: 05568D1FF7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(396003)(346002)(39380400002)(69224002)(189003)(199004)(10090500001)(8990500004)(790700001)(25786009)(478600001)(2906002)(8676002)(68736007)(74316002)(10290500003)(2900100001)(86612001)(8936002)(4326008)(81166006)(81156014)(7736002)(93886005)(6246003)(97736004)(6346003)(77096007)(33656002)(5660300001)(2950100002)(6116002)(110136005)(316002)(22452003)(106356001)(3280700002)(86362001)(55016002)(54906003)(3660700001)(59450400001)(9686003)(14454004)(105586002)(236005)(76176011)(6306002)(6436002)(7696005)(53546011)(53936002)(6506007)(54896002)(99286004)(229853002)(102836004)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0835; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: 3H5eWAI/DUIPVD7ZQ+fEPru2aqeU7iOyd1y237cH0oMTNWCiiOUg1ZCYha6aE6q0sY2UB6muj3Cp074xm/yEoQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178F243D65A9EC8B3126AD2B3E80BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1217939e-613c-43ca-96ab-08d55eaa525c X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 19:33:16.0452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0835 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Jan 2018 19:33:23 -0000 --_000_BN6PR21MB0178F243D65A9EC8B3126AD2B3E80BN6PR21MB0178namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBhbGwgdGhlIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24uIEl0IGFsbCBtYWtlcyBz ZW5zZS4gV2hpbGUgbm90IGNvbXBsZXRlbHkgbmVjZXNzYXJ5LCBJIGRvIHRoaW5rIGl0IHdvdWxk IGJlIGEgYml0IGhlbHBmdWwgdG8gYWRkIHRob3NlIGRldGFpbHMgb24gZXhhY3RseSB3aGF0IHJl Y292ZXJ5IHBlcmlvZCBtZWFucyBhbmQgd2hhdCBpdCBpcyB0cnlpbmcgdG8gYWNjb21wbGlzaC4N Cg0KVGhhbmtzIGFnYWluLA0KLSBOaWNrDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRvOmpy aUBnb29nbGUuY29tXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMTggMTE6MzAgQU0N ClRvOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+DQpDYzogU3Vib2RoIEl5ZW5nYXIg PHN1Ym9kaEBmYi5jb20+OyBOaWNrIEJhbmtzIDxuaWJhbmtzQG1pY3Jvc29mdC5jb20+OyBJRVRG IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogRGVmaW5pdGlvbiBvZiBSZWNv dmVyeSBQZXJpb2QgRW5kDQoNCk5pY2ssDQoNClRvIGNsYXJpZnksICJyZWNvdmVyeSBwZXJpb2Qi IGlzIGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgbG9zcyByZWNvdmVyeSBhbmQgY29uZ2VzdGlv biBjb250cm9sLiBUaGUgY29uZ2VzdGlvbiBjb250cm9sbGVyIGlzIGV4cGVjdGVkIHRvIHRha2Ug Y29uZ2VzdGlvbiBhY3Rpb24gb24gbG9zcy4gSG93ZXZlciwgaXQgc2hvdWxkIGJlIGNhcmVmdWwg dG8gaG9sZCBvZmYgb24gZnV0dXJlIGNvbmdlc3Rpb24gYWN0aW9ucyB1bnRpbCB0aGlzIGFjdGlv biBwcm9wYWdhdGVzIHRocm91Z2ggdGhlIG5ldHdvcmsuDQoNCk1vcmUgcHJlY2lzZWx5LCB0aGUg UmVubyBjb25nZXN0aW9uIGNvbnRyb2xsZXIgd2lsbCByZWR1Y2UgaXRzIHJhdGUgd2hlbiB0aGUg c2VuZGVyIGRldGVjdHMgbG9zcywgYW5kIHNob3VsZCBvbmx5IHJlZHVjZSBpdHMgcmF0ZSBhZ2Fp biBpZiB0aGUgbmV3IHJhdGUgaXMgdG9vIGhpZ2guLi4gdGhhdCBpcywgYW5vdGhlciBsb3NzIGlz IGRldGVjdGVkIG9uIHBhY2tldHMgc2VudCAqYWZ0ZXIqIHRoZSByYXRlIHJlZHVjdGlvbi4gRmVl ZGJhY2sgb24gdGhlIG5ldyByYXRlIHRha2VzIGFib3V0IGFuIFJUVCBvZiB0aW1lLCBhbmQgaXMg bWVhc3VyZWQgYXMgdGhlIHRpbWUgcGVyaW9kIGJldHdlZW4gc2VuZGluZyB0aGUgZmlyc3QgcGFj a2V0IGFmdGVyIGEgbG9zcyBpcyBkZXRlY3RlZCB0byB3aGVuIHRoYXQgb3IgYSBzdWJzZXF1ZW50 bHkgc2VudCBwYWNrZXQgaXMgYWNrZWQuIFRoaXMgaXMgdGhlIHJlY292ZXJ5IHBlcmlvZC4gSXQg aXMgbm90IG1lYW50IHRvIGluZGljYXRlIHdoZW4gYWxsIGxvc3NlcyBhcmUgcmVjb3ZlcmVkIGZy b20uDQoNCldvdWxkIGl0IGhlbHAgdG8gZGVzY3JpYmUgdGhpcyBpbiB0aGUgZHJhZnQ/DQoNCi0g amFuYQ0KDQpPbiBUdWUsIEphbiAxNiwgMjAxOCBhdCA1OjU2IFBNLCBJYW4gU3dldHQgPGlhbnN3 ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNCk5pY2ss IHRoaXMgaXMgYSB2ZXJ5IGdvb2QgcXVlc3Rpb24uDQoNCkluaXRpYWxseSwgdGhpcyB3YXMgY2hv c2VuIGJlY2F1c2UgaXQgd2FzIHRoZSBtb3N0IHN0cmFpZ2h0Zm9yd2FyZCBtYXBwaW5nIG9mIFRD UCdzIGJlaGF2aW9yLg0KDQpUaGlzIGhhcyBzb21lIHByb3MgYW5kIGNvbnMuICBUaGUgbWFqb3Ig Y29uIGlzIHRoYXQgaXQgbWFrZXMgZGlyZWN0IGNvbXBhcmlzb24gdG8gVENQIG1vcmUgZGlmZmlj dWx0LCBwYXJ0aWN1bGFybHkgd2hlbiBsb3NzIHJhdGVzIGFyZSBoaWdoLiAgQSBwb3NpdGl2ZSBp cyB0aGF0IFFVSUMgY2FuIHJlZHVjZSBpdCdzIENXTkQoYW5kIHNlbmRpbmcgcmF0ZSkgbW9yZSBy YXBpZGx5IGluIHRoZSBmYWNlIG9mIGhpZ2ggbG9zcyBhbmQgbWF5IHByb3ZpZGUgbW9yZSBjb25z aXN0ZW50IHBlcmZvcm1hbmNlIGluIGNhc2VzIHdoZW4gdGhlIENXTkQgaXMgbGFyZ2UsIHNvIG9i c2VydmluZyBhIGxvc3Mgd2l0aGluIGFuIGVwb2NoIGlzIGNvbW1vbi4NCg0KVGhlIGludGVudCBp cyB0aGF0IHRoZSBRVUlDIGFwcHJvYWNoIHRvIHJlY292ZXJ5IGlzIGFuIGlkZWFsIGVtYm9kaW1l bnQgb2YgdGhlIHNwaXJpdCBvZiB0aGUgb3JpZ2luYWwgVENQIGFsZ29yaXRobXMgZm9yIHJlY292 ZXJ5LiAgSWYgd2UgaGF2ZSBhbnkgZGF0YSB0aGF0IGluZGljYXRlcyB0aGV5IGRvbid0IHdvcmsg d2VsbCBpbiBwcmFjdGljZSwgSSdkIGJlIGhhcHB5IHRvIGNvbnNpZGVyIGNoYW5nZXMgdG8gdGhl IHJlY292ZXJ5IGRyYWZ0Lg0KDQpPbiBUdWUsIEphbiAxNiwgMjAxOCBhdCA4OjEwIFBNLCBTdWJv ZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+IHdyb3RlOg0K DQpBbGwgb2YgdGhlIGxvc3MgcmVjb3ZlcnkgbW9kZXMgdGhhdCBRVUlDIGhhcyBoYXZlIHRoZSBm b2xsb3dpbmcgcHJvcGVydHkNCg0KDQoNCmlmIHBhY2tldCBuIGlzIGxvc3QsIHRoZW4gcGFja2V0 IG4gLSAxIG11c3QgYWxzbyBiZSBsb3N0Lg0KDQoNCg0KVGhpcyBpcyB0cnVlIGJvdGggaW4gdGhl IHRocmVzaG9sZCBhbmQgdGltZSByZW9yZGVyaW5nIGJhc2VkIHJlY292ZXJ5Lg0KDQpBIG5ld2x5 IHNlbnQgcGFja2V0IGluIGxvc3MgaXMgdHJpZ2dlcmVkIGJ5IGVpdGhlciBzZW5kaW5nIGEgVExQ IG9yIFJUTy4NCg0KSWYgeW91IGdldCBhbiBhY2sgZm9yIGEgbmV3IHBhY2tldCB3aXRob3V0IGdl dHRpbmcgdGhlIGFja3MgZm9yIGFsbCB0aGUgb3RoZXIgc2VudCBwYWNrZXRzLCBRVUlDcyB0aHJl c2hvbGQgbG9zcyByZWNvdmVyeSB3aWxsIGtpY2sgaW4gYW5kIGNvbmZpcm0gdGhhdCB0aGUgcGFj a2V0cyB0aGF0IHdlcmUgc2VudCBiZWZvcmUgd2VyZSBsb3N0Lg0KDQoNCg0KU28gSSBiZWxpZXZl IHlvdSBkb24ndCBuZWVkIHRvIHdhaXQgZm9yIGFsbCB0aGUgaW5mb3JtYXRpb24gdG8gYmUgQUNL ZWQgb25jZSB5b3UgZ2V0IGFuIGFjayBmb3IgdGhlIGxhdGVzdCBwYWNrZXQuIEFuIGFyZ3VtZW50 IGNvdWxkIGJlIG1hZGUgdGhhdCB0aGUgYWNrIGZvciB0aGUgbmV3IHBhY2tldCBtaWdodCBub3Qg dHJpZ2dlciBsb3NzDQoNCm9mIGFsbCB0aGUgcGFja2V0cywgaG93ZXZlciBpdCB3aWxsIGRlZmlu aXRlbHkgdHJpZ2dlciBRVUlDJ3MgZWFybHkgcmV0cmFuc21pdCB0aW1lciwgd2hpY2ggd2lsbCB0 cmlnZ2VyIHRoZSBmdXR1cmUgbG9zcy4NCg0KDQoNClN1Ym9kaA0KDQoNCg0KDQoNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgTmljayBC YW5rcyA8bmliYW5rc0BtaWNyb3NvZnQuY29tPG1haWx0bzpuaWJhbmtzQG1pY3Jvc29mdC5jb20+ Pg0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNiwgMjAxOCA0OjM1OjUzIFBNDQpUbzogSUVURiBR VUlDIFdHDQpTdWJqZWN0OiBEZWZpbml0aW9uIG9mIFJlY292ZXJ5IFBlcmlvZCBFbmQNCg0KDQpB c2tpbmcgdGhpcyBvbiBoZXJlIHBlciByZWNvbW1lbmRhdGlvbiBvbiBHaXRIdWI6DQoNCg0KDQpB Y2NvcmRpbmcgdG8gdGhlIHNwZWMsIHJlY292ZXJ5IHN0YXJ0cyB3aXRoIGRldGVjdGlvbiBvZiBh IGxvc3QgcGFja2V0IGFuZCBlbmRzIHdpdGggdGhlIGFja25vd2xlZGdlbWVudCBvZiBhIHNpbmds ZSwgbmV3bHkgc2VudCBwYWNrZXQuIFdoeSBpc27igJl0IHJlY292ZXJ5IGVuZGluZyBvbmx5IGFm dGVyIGFsbCB0aGUgaW5mb3JtYXRpb24gaW4gdGhlIGZyYW1lcyB0aGF0IHdlcmUgbG9zdCBwcmlv ciB0byB0aGUgcmVjb3ZlcnkgcGVyaW9kIGhhdmUgYmVlbiBhY2tub3dsZWRnZWQ/IFRoaXMgd2F5 IHdvdWxkIHNlZW0gbW9yZSBpbmxpbmUgdG8gd2hhdCBUQ1AgZG9lcyB0b2RheS4NCg0KDQoNCkZv ciBpbnN0YW5jZSwgaWYgNCBwYWNrZXRzIHdvcnRoIG9mIFNUUkVBTSBmcmFtZXMgYW5kIGEgTUFY X0RBVEEgZnJhbWUgd2VyZSBsb3N0LCB3aHkgc2hvdWxkbuKAmXQgcmVjb3ZlcnkgbGFzdCB1bnRp bCBhbGwgdGhhdCBkYXRhIGhhZCBiZWVuIHJlc2VudCBhbmQgYWNrbm93bGVkZ2VkPw0KDQoNCg0K VGhhbmtzLA0KDQotIE5pY2sgQmFua3MNCg0KDQo= --_000_BN6PR21MB0178F243D65A9EC8B3126AD2B3E80BN6PR21MB0178namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm02NTYx OTc1NTMzMDI1NTQyODE4bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1hbCwgbGkubTY1NjE5 NzU1MzMwMjU1NDI4MThtLTMzNjM3MjEzOTQwNzQyMDU2OTV4bXNvbm9ybWFsLCBkaXYubTY1NjE5 NzU1MzMwMjU1NDI4MThtLTMzNjM3MjEzOTQwNzQyMDU2OTV4bXNvbm9ybWFsDQoJe21zby1zdHls ZS1uYW1lOm1fNjU2MTk3NTUzMzAyNTU0MjgxOG1fLTMzNjM3MjEzOTQwNzQyMDU2OTV4X21zb25v cm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGFua3MgZm9yIGFsbCB0aGUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbi4gSXQg YWxsIG1ha2VzIHNlbnNlLiBXaGlsZSBub3QgY29tcGxldGVseSBuZWNlc3NhcnksIEkgZG8gdGhp bmsgaXQgd291bGQgYmUgYSBiaXQgaGVscGZ1bCB0byBhZGQgdGhvc2UgZGV0YWlscyBvbiBleGFj dGx5IHdoYXQgcmVjb3ZlcnkgcGVyaW9kIG1lYW5zIGFuZCB3aGF0IGl0IGlzIHRyeWluZyB0byBh Y2NvbXBsaXNoLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgYWdhaW4sPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE5pY2s8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXSA8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTgsIDIwMTggMTE6MzAgQU08YnI+DQo8 Yj5Ubzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IFN1Ym9kaCBJeWVuZ2FyICZsdDtzdWJvZGhAZmIuY29tJmd0OzsgTmljayBCYW5rcyAm bHQ7bmliYW5rc0BtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogRGVmaW5pdGlvbiBvZiBSZWNvdmVyeSBQ ZXJpb2QgRW5kPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaWNrLDxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG8gY2xhcmlmeSwgJnF1b3Q7cmVj b3ZlcnkgcGVyaW9kJnF1b3Q7IGlzIGRlZmluZWQgaW4gdGhlIGNvbnRleHQgb2YgbG9zcyByZWNv dmVyeSBhbmQgY29uZ2VzdGlvbiBjb250cm9sLiBUaGUgY29uZ2VzdGlvbiBjb250cm9sbGVyIGlz IGV4cGVjdGVkIHRvIHRha2UgY29uZ2VzdGlvbiBhY3Rpb24gb24gbG9zcy4gSG93ZXZlciwgaXQg c2hvdWxkIGJlIGNhcmVmdWwgdG8gaG9sZCBvZmYgb24gZnV0dXJlIGNvbmdlc3Rpb24gYWN0aW9u cw0KIHVudGlsIHRoaXMgYWN0aW9uIHByb3BhZ2F0ZXMgdGhyb3VnaCB0aGUgbmV0d29yay4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TW9yZSBwcmVjaXNlbHksIHRoZSBSZW5vIGNvbmdlc3Rpb24gY29udHJvbGxlciB3aWxsIHJlZHVj ZSBpdHMgcmF0ZSB3aGVuIHRoZSBzZW5kZXIgZGV0ZWN0cyBsb3NzLCBhbmQgc2hvdWxkIG9ubHkg cmVkdWNlIGl0cyByYXRlIGFnYWluIGlmIHRoZSBuZXcgcmF0ZSBpcyB0b28gaGlnaC4uLiB0aGF0 IGlzLCBhbm90aGVyIGxvc3MgaXMgZGV0ZWN0ZWQgb24gcGFja2V0cyBzZW50ICphZnRlciogdGhl IHJhdGUgcmVkdWN0aW9uLg0KIEZlZWRiYWNrIG9uIHRoZSBuZXcgcmF0ZSB0YWtlcyBhYm91dCBh biBSVFQgb2YgdGltZSwgYW5kIGlzIG1lYXN1cmVkIGFzIHRoZSB0aW1lIHBlcmlvZCBiZXR3ZWVu IHNlbmRpbmcgdGhlIGZpcnN0IHBhY2tldCBhZnRlciBhIGxvc3MgaXMgZGV0ZWN0ZWQgdG8gd2hl biB0aGF0IG9yIGEgc3Vic2VxdWVudGx5IHNlbnQgcGFja2V0IGlzIGFja2VkLiBUaGlzIGlzIHRo ZSByZWNvdmVyeSBwZXJpb2QuIEl0IGlzIG5vdCBtZWFudCB0byBpbmRpY2F0ZQ0KIHdoZW4gYWxs IGxvc3NlcyBhcmUgcmVjb3ZlcmVkIGZyb20uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIGl0IGhlbHAgdG8gZGVzY3JpYmUgdGhpcyBp biB0aGUgZHJhZnQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBUdWUsIEphbiAxNiwgMjAxOCBhdCA1OjU2IFBNLCBJYW4gU3dldHQg Jmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5OaWNrLCB0aGlzIGlzIGEgdmVyeSBn b29kIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW5pdGlhbGx5LCB0aGlzIHdhcyBjaG9zZW4gYmVjYXVzZSBpdCB3YXMgdGhlIG1vc3Qgc3Ry YWlnaHRmb3J3YXJkIG1hcHBpbmcgb2YgVENQJ3MgYmVoYXZpb3IuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFzIHNvbWUgcHJvcyBh bmQgY29ucy4mbmJzcDsgVGhlIG1ham9yIGNvbiBpcyB0aGF0IGl0IG1ha2VzIGRpcmVjdCBjb21w YXJpc29uIHRvIFRDUCBtb3JlIGRpZmZpY3VsdCwgcGFydGljdWxhcmx5IHdoZW4gbG9zcyByYXRl cyBhcmUgaGlnaC4mbmJzcDsgQSBwb3NpdGl2ZSBpcyB0aGF0IFFVSUMgY2FuIHJlZHVjZSBpdCdz IENXTkQoYW5kIHNlbmRpbmcgcmF0ZSkgbW9yZSByYXBpZGx5IGluIHRoZSBmYWNlIG9mIGhpZ2gN CiBsb3NzIGFuZCBtYXkgcHJvdmlkZSBtb3JlIGNvbnNpc3RlbnQgcGVyZm9ybWFuY2UgaW4gY2Fz ZXMgd2hlbiB0aGUgQ1dORCBpcyBsYXJnZSwgc28gb2JzZXJ2aW5nIGEgbG9zcyB3aXRoaW4gYW4g ZXBvY2ggaXMgY29tbW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgaW50ZW50IGlzIHRoYXQgdGhlIFFVSUMgYXBwcm9hY2ggdG8gcmVj b3ZlcnkgaXMgYW4gaWRlYWwgZW1ib2RpbWVudCBvZiB0aGUgc3Bpcml0IG9mIHRoZSBvcmlnaW5h bCBUQ1AgYWxnb3JpdGhtcyBmb3IgcmVjb3ZlcnkuJm5ic3A7IElmIHdlIGhhdmUgYW55IGRhdGEg dGhhdCBpbmRpY2F0ZXMgdGhleSBkb24ndCB3b3JrIHdlbGwgaW4gcHJhY3RpY2UsIEknZCBiZSBo YXBweSB0byBjb25zaWRlciBjaGFuZ2VzIHRvDQogdGhlIHJlY292ZXJ5IGRyYWZ0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgSmFuIDE2LCAyMDE4IGF0IDg6MTAgUE0sIFN1Ym9kaCBJeWVuZ2FyICZsdDs8 YSBocmVmPSJtYWlsdG86c3Vib2RoQGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN1Ym9kaEBmYi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp diBpZD0ibV82NTYxOTc1NTMzMDI1NTQyODE4bV8tMzM2MzcyMTM5NDA3NDIwNTY5NWRpdnRhZ2Rl ZmF1bHR3cmFwcGVyIj4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkFsbCBvZiB0aGUg bG9zcyByZWNvdmVyeSBtb2RlcyB0aGF0IFFVSUMgaGFzIGhhdmUgdGhlIGZvbGxvd2luZyBwcm9w ZXJ0eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPmlmIHBhY2tldCBuIGlzIGxvc3QsIHRoZW4gcGFja2V0IG4gLSAxIG11c3QgYWxzbyBiZSBs b3N0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPlRoaXMgaXMgdHJ1ZSBib3RoIGluIHRoZSB0aHJlc2hvbGQgYW5kIHRpbWUgcmVvcmRlcmlu ZyBiYXNlZCByZWNvdmVyeS48YnI+DQo8YnI+DQpBIG5ld2x5IHNlbnQgcGFja2V0IGluIGxvc3Mg aXMgdHJpZ2dlcmVkIGJ5IGVpdGhlciBzZW5kaW5nIGEgVExQIG9yIFJUTy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5JZiB5b3UgZ2V0IGFuIGFj ayBmb3IgYSBuZXcgcGFja2V0IHdpdGhvdXQgZ2V0dGluZyB0aGUgYWNrcyBmb3IgYWxsIHRoZSBv dGhlciBzZW50IHBhY2tldHMsIFFVSUNzIHRocmVzaG9sZCBsb3NzIHJlY292ZXJ5IHdpbGwga2lj ayBpbiBhbmQgY29uZmlybSB0aGF0IHRoZSBwYWNrZXRzIHRoYXQgd2VyZQ0KIHNlbnQgYmVmb3Jl IHdlcmUgbG9zdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjtt YXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBp bjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5TbyBJIGJlbGlldmUgeW91IGRvbid0IG5lZWQgdG8gd2FpdCBmb3IgYWxsIHRo ZSBpbmZvcm1hdGlvbiB0byBiZSBBQ0tlZCBvbmNlIHlvdSBnZXQgYW4gYWNrIGZvciB0aGUgbGF0 ZXN0IHBhY2tldC4gQW4gYXJndW1lbnQgY291bGQgYmUgbWFkZSB0aGF0IHRoZSBhY2sgZm9yIHRo ZSBuZXcgcGFja2V0DQogbWlnaHQgbm90IHRyaWdnZXIgbG9zczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW46MGluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm9mIGFsbCB0aGUgcGFja2V0cywgaG93 ZXZlciBpdCB3aWxsIGRlZmluaXRlbHkgdHJpZ2dlciBRVUlDJ3MgZWFybHkgcmV0cmFuc21pdCB0 aW1lciwgd2hpY2ggd2lsbCB0cmlnZ2VyIHRoZSBmdXR1cmUgbG9zcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TdWJvZGg8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBpbjttYXJnaW4tYm90dG9tOi4w MDAxcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxp Z249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0 aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPGRpdiBpZD0ibV82NTYxOTc1NTMzMDI1 NTQyODE4bV8tMzM2MzcyMTM5NDA3NDIwNTY5NWRpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gUVVJQyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBOaWNrIEJhbmtzICZsdDs8YSBocmVmPSJtYWlsdG86bmliYW5rc0Bt aWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmliYW5rc0BtaWNyb3NvZnQuY29tPC9hPiZn dDs8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSAxNiwgMjAxOCA0OjM1OjUzIFBN PGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRGVmaW5p dGlvbiBvZiBSZWNvdmVyeSBQZXJpb2QgRW5kPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im02NTYxOTc1NTMzMDI1 NTQyODE4bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1hbCI+QXNraW5nIHRoaXMgb24gaGVy ZSBwZXIgcmVjb21tZW5kYXRpb24gb24gR2l0SHViOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Im02NTYxOTc1NTMzMDI1NTQyODE4bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTY1NjE5NzU1MzMwMjU1NDI4MThtLTMzNjM3 MjEzOTQwNzQyMDU2OTV4bXNvbm9ybWFsIj5BY2NvcmRpbmcgdG8gdGhlIHNwZWMsIHJlY292ZXJ5 IHN0YXJ0cyB3aXRoIGRldGVjdGlvbiBvZiBhIGxvc3QgcGFja2V0IGFuZCBlbmRzIHdpdGggdGhl IGFja25vd2xlZGdlbWVudCBvZiBhIHNpbmdsZSwgbmV3bHkgc2VudCBwYWNrZXQuIFdoeSBpc27i gJl0IHJlY292ZXJ5IGVuZGluZyBvbmx5IGFmdGVyIGFsbCB0aGUgaW5mb3JtYXRpb24NCiBpbiB0 aGUgZnJhbWVzIHRoYXQgd2VyZSBsb3N0IHByaW9yIHRvIHRoZSByZWNvdmVyeSBwZXJpb2QgaGF2 ZSBiZWVuIGFja25vd2xlZGdlZD8gVGhpcyB3YXkgd291bGQgc2VlbSBtb3JlIGlubGluZSB0byB3 aGF0IFRDUCBkb2VzIHRvZGF5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02NTYxOTc1NTMz MDI1NTQyODE4bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0ibTY1NjE5NzU1MzMwMjU1NDI4MThtLTMzNjM3MjEzOTQwNzQyMDU2 OTV4bXNvbm9ybWFsIj5Gb3IgaW5zdGFuY2UsIGlmIDQgcGFja2V0cyB3b3J0aCBvZiBTVFJFQU0g ZnJhbWVzIGFuZCBhIE1BWF9EQVRBIGZyYW1lIHdlcmUgbG9zdCwgd2h5IHNob3VsZG7igJl0IHJl Y292ZXJ5IGxhc3QgdW50aWwgYWxsIHRoYXQgZGF0YSBoYWQgYmVlbiByZXNlbnQgYW5kIGFja25v d2xlZGdlZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjU2MTk3NTUzMzAyNTU0MjgxOG0t MzM2MzcyMTM5NDA3NDIwNTY5NXhtc29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im02NTYxOTc1NTMzMDI1NTQyODE4bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1h bCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02NTYxOTc1NTMzMDI1NTQyODE4 bS0zMzYzNzIxMzk0MDc0MjA1Njk1eG1zb25vcm1hbCI+LSBOaWNrIEJhbmtzPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR21MB0178F243D65A9EC8B3126AD2B3E80BN6PR21MB0178namp_-- From nobody Thu Jan 18 11:46:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9CE12D7FC for ; Thu, 18 Jan 2018 11:46:52 -0800 (PST) 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=P/+Pi30m; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iBRb7vz2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXxyO7KnAQ-w for ; Thu, 18 Jan 2018 11:46:50 -0800 (PST) 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 DA55512D7FB for ; Thu, 18 Jan 2018 11:46:50 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0IJkjwx027565; Thu, 18 Jan 2018 11:46:47 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=GFv/mhp5p6nvJ3ovFGbhqBxIPRbFq/3hw95IPO9ksrQ=; b=P/+Pi30mrLyakwAHXC5XxNoeVTx3gxymrME8VO3OhYwnjsH6EWuzJwTdBI7wUrBcCn5K rSg3OvI2ULF0SJPTkm6auUeUzfhpMVtKSb5ixgnZj5UMFivmKC8alzPqDzA9wSQ1q4sk NBl8xgpq8DfSVKqLZ/fhePgEwwwRCO6aids= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fjyhp0vgc-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Jan 2018 11:46:47 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 18 Jan 2018 11:46:26 -0800 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=GFv/mhp5p6nvJ3ovFGbhqBxIPRbFq/3hw95IPO9ksrQ=; b=iBRb7vz2n16bvqrt0jdvYVe4x0f2KFKOlYPR7zokISZhMzuX5vOQOR38EppBCONT1H/4FbFyvd2npNEVNKnZg1jcW7xWpi9dSLIyphkUYLbZKabV4TEj/r7PbNAHAWLtcRa8zAxHr9Ah4V7NZzDIHiPZTX9OBgcrDfZThJ5BlHU= Received: from SN6PR1501MB2191.namprd15.prod.outlook.com (52.132.120.28) by SN6PR1501MB2190.namprd15.prod.outlook.com (52.132.120.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.386.5; Thu, 18 Jan 2018 19:46:22 +0000 Received: from SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d]) by SN6PR1501MB2191.namprd15.prod.outlook.com ([fe80::a873:4c9f:f589:4b2d%13]) with mapi id 15.20.0366.011; Thu, 18 Jan 2018 19:46:22 +0000 From: Roberto Peon To: Martin Thomson , Ian Swett CC: Jana Iyengar , QUIC WG Subject: Re: Deadlocking in the transport Thread-Topic: Deadlocking in the transport Thread-Index: AQHTidq/6Mg61g6LuEipz9qoFIGKPqNsqpwAgAC3uoCAAB3vgIAAA6iAgAAEuYCAAAC5AIAAAhWAgAACuICAAAJVAIAAGr0AgAAIxgCAAADWgIACtUUA//+auwCAA/jxgIAEpw2AgAAOwICAAJKjgIAASfqA Date: Thu, 18 Jan 2018 19:46:22 +0000 Message-ID: <40331485-F99A-4CE3-BAE9-D448046620DF@fb.com> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:1ae7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR1501MB2190; 7:q0Fi7CgLWJhYpeRbXanXRDF62tePdLCusLDwjSCjHRdLwkMmoQ7s3cNGUiyopSfpo42bvJoZkf3zk3pPo61C3vRRxH+Xf3f2Aq/uTv3tdenBofutw8kMv1eFofb09Zie9UJ943PZtIjT50jNiWrPdneU9LqC6b9Ixq81E02l4i6bSD8JF755efLoMcHgLjQSmVZHhQS8g/qYozOIN9kuz5SicLv7riidMDySSWOqML5CAZaDy2m2sE7d+pVibmSs; 20:D/WF09Z/sR49fUyZXFqC169xyhNOlhNUT4EvRksDYKHKqvn09b0a+8v3GOCeJwio6nBzUxfEkTwVKCW6h3IGctxVz6cnCqvK1LuAupRqyNsXAJmpieAkwQ9xsg6tnWMo6/t5PUyHR3uHVWP/jrAyINh5mgWyeGhvrmECmNuJO9I= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 306f74e9-af54-412d-380e-08d55eac2737 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:SN6PR1501MB2190; x-ms-traffictypediagnostic: SN6PR1501MB2190: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040495)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231023)(11241501184)(2400066)(944501161)(6041282)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:SN6PR1501MB2190; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:SN6PR1501MB2190; x-forefront-prvs: 05568D1FF7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(376002)(366004)(39860400002)(39380400002)(51444003)(189003)(199004)(7736002)(39060400002)(82746002)(478600001)(2950100002)(105586002)(229853002)(3660700001)(99286004)(106356001)(33656002)(4326008)(25786009)(5660300001)(14454004)(97736004)(6116002)(53546011)(2906002)(6486002)(316002)(6506007)(102836004)(110136005)(81166006)(3280700002)(6246003)(8676002)(54906003)(59450400001)(6436002)(305945005)(81156014)(5250100002)(2900100001)(6512007)(53936002)(36756003)(3480700004)(83716003)(86362001)(68736007)(8936002)(93886005)(76176011)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR1501MB2190; H:SN6PR1501MB2191.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Rq8j1xaeYibepnGLoJbH0XbePdTOCssbmQh6B7VoAtaSMPSvU0PimepRA0/7hqokEYZ+rbnehP88jHvb9Yr/OQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 306f74e9-af54-412d-380e-08d55eac2737 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2018 19:46:22.6703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2190 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-18_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Jan 2018 19:46:52 -0000 SSBkb27igJl0IGJlbGlldmUgdGhhdCBhbnl0aGluZyB3ZSBzcGVjaWZ5IGluIHRoZSBwcm90b2Nv bCBjYW4gc29sdmUgdGhlIGlzc3VlIHcuci50LiBmbG93IGNvbnRyb2wgYW5kIGludGVybWVkaWFy aWVzIChpbiAgd2hpY2ggdGhlIGFwcGxpY2F0aW9uIGZyYW1ld29yayBpdHNlbGYgbWlnaHQgY291 bnQgYXMgYW4gaW50ZXJtZWRpYXJ5KS4NCkF0IGJlc3Qgd2UgbWF5IG1pdGlnYXRlIHRoZSBpc3N1 ZSBieSBvZmZlcmluZyBhIHN0cmF0ZWd5IHRoYXQgb2ZmZXJzIGJldHRlciBvdXRjb21lcyB0aGFu IOKAnHRyeSwgdGltZW91dCwgcmV0cnku4oCdDQoNCldlIGhhdmUgYSBjb25jcmV0ZSBjYXNlIGhl cmUgaW4gY29tcHJlc3Npb24uIEluIHBhcnRpY3VsYXIsIGNvbXByZXNzaW9uIG1heSBiZSBwb2lu dC10by1wb2ludCBhbmQgZW50aXJlbHkgd2l0aGluIHRoZSBkb21haW4gb2YgdGhlIHByb3RvY29s IGltcGxlbWVudGF0aW9ucywgYnV0IGZsb3ctY29udHJvbCBpcyBleGVydGVkIGVuZC10by1lbmQg YW5kIGJleW9uZCB0aGUgZG9tYWluIG9mIHRoZSBwcm90b2NvbC4NCklmIGNvbXByZXNzaW9uL2Nv bXByZXNzaW9uIGRhdGEgaXMgdG8gYmUgZmxvdy1jb250cm9sbGVkLCB0aGVuIGl0IGlzIHdvcnRo IHRoaW5raW5nIGFib3V0IGNvbXByZXNzaW9uLXNwZWNpZmljIG1pdGlnYXRpb25zIHdoaWNoIGFy ZSBiZXR0ZXIgdGhhbiDigJh0cnksIHRpbWVvdXQsIHJldHJ5LuKAmQ0KDQotPVINCg0KT24gMS8x Ny8xOCwgMTE6MjIgUE0sICJNYXJ0aW4gVGhvbXNvbiIgPG1hcnRpbi50aG9tc29uQGdtYWlsLmNv bT4gd3JvdGU6DQoNCiAgICBZZXMsIHdoYXQgSWFuIHNhaWQgKGFuZCBtb3JlIHRvIHdoYXQgSmFu YSBzYWlkKS4gIEkgdGhpbmsgdGhhdCB3ZSd2ZQ0KICAgIHNvbWUgcHJvcG9ydGlvbiBvZiB0aGUg d29ya2luZyBncm91cCB3aG8gYXJlIG9wZXJhdGluZyBvbiBvbmUgc2V0IG9mDQogICAgYXNzdW1w dGlvbnMgYW5kIGFub3RoZXIgb24gYSBkaWZmZXJlbnQgc2V0IG9mIGFzc3VtcHRpb25zIG9uIHRo aXMNCiAgICBzdWJqZWN0LiAgVW50aWwgbm93LCB0aGF0IGRpZG4ndCBib3RoZXIgbWUgbXVjaC4g IEFmdGVyIGFsbCwgdGhhdCdzDQogICAgbm9ybWFsIGZvciBhIHdob2xlIHJhbmdlIG9mIGlzc3Vl cy4NCiAgICANCiAgICBOb3cgdGhlcmUncyBhIGNvbmNyZXRlIHByb2JsZW0sIHNvIGxldCdzIGRp ZyBpbnRvIHRoaXMgcHJvcGVybHkuDQogICAgDQogICAgRldJVywgSSBkb24ndCB0aGluayB0aGF0 IHdlJ2xsIHJlc29sdmUgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlIGluDQogICAgTWVsYm91cm5lLCBi dXQgSSBob3BlIHRoYXQgd2UgY2FuIGF0IGxlYXN0IHN0YXJ0IHRoYXQgcHJvY2Vzcy4gIFRoaXMN CiAgICBwcm9taXNlcyB0byBiZSBpbnRlcmVzdGluZy4NCiAgICANCiAgICBPbiBUaHUsIEphbiAx OCwgMjAxOCBhdCA5OjM2IEFNLCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+IHdyb3Rl Og0KICAgID4gKzEgbWlsbGlvbg0KICAgID4NCiAgICA+IE9uIFdlZCwgSmFuIDE3LCAyMDE4IGF0 IDQ6NDMgUE0sIEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+IHdyb3RlOg0KICAgID4+DQog ICAgPj4gV2Ugd2lsbCBkaXNjdXNzIHRoaXMgYXQgdGhlIGludGVyaW0sIGJ1dCBvbmUgY29tbWVu dCwgaW5saW5lLg0KICAgID4+DQogICAgPj4+DQogICAgPj4+IEluIHBhcnQsIGl0J3MgdGhlIGln bm9yYW5jZSBvZiB0aGUgaW50ZXJtZWRpYXJ5IHRoYXQgY2F1c2VzIHRoaXMNCiAgICA+Pj4gcGFy dGljdWxhciBwcm9ibGVtLiAgSWYgdGhlIGludGVybWVkaWFyeSB3YXMgYXdhcmUgb2YgdGhlIHBy b3RvY29sDQogICAgPj4+IGRldGFpbHMgdGhlbiBpdCBtaWdodCBiZSBhYmxlIHRvIHJlY29nbml6 ZSBhbmQgYXZvaWQgdGhlc2Ugc2l0dWF0aW9ucywNCiAgICA+Pj4gYnV0IHRoYXQgc2VlbXMgYSBs aXR0bGUgdG9vIG11Y2ggdG8gZXhwZWN0IG9mIGludGVybWVkaWFyaWVzLiBSdWxpbmcNCiAgICA+ Pj4gb3V0IHRoZSBlbnRpcmUgY2xhc3Mgb2YgaW50ZXJtZWRpYXJ5IHRoYXQgb3BlcmF0ZXMgcHVy ZWx5IGF0IHRoZQ0KICAgID4+PiB0cmFuc3BvcnQgbGF5ZXIgaXMgZXh0cmVtZWx5IGhhcnNoLg0K ICAgID4+Pg0KICAgID4+PiBXaGF0IGlzIG1vcmUgbGlrZWx5IGhlcmUgaXMgdGhhdCB3ZSBkZXNj cmliZSB0aGlzIHNpdHVhdGlvbiwgZXhwbGFpbg0KICAgID4+PiB0aGF0IGl0IGlzIGltcG9zc2li bGUgdG8gcHJldmVudCBpbiB0aGUgcHJlc2VuY2Ugb2YgaW50ZXJtZWRpYXRpb24sDQogICAgPj4+ IGFuZCBleHBsYWluIGhvdyB0byBraWxsIHRoZSByaWdodCBzdHJlYW1zIGluIG9yZGVyIHRvIGVu c3VyZSBmb3J3YXJkDQogICAgPj4+IHByb2dyZXNzIGRvZXNuJ3Qgc3RhbGwgaW5kZWZpbml0ZWx5 Lg0KICAgID4+DQogICAgPj4NCiAgICA+PiBFeGFjdGx5IGJlY2F1c2UgaW50ZXJtZWRpYXJpZXMg bWFrZSB0aGluZ3MgZGlmZmljdWx0LCBpdCdzIGltcG9ydGFudCB0byBiZQ0KICAgID4+IGNlcnRh aW4gdGhhdCB0aGUgaW50ZXJtZWRpYXJ5IGJlaGF2aW9yIHdlIGFyZSBkaXNjdXNzaW5nIGlzIG9u ZSB0aGF0IHRoZXJlJ3MNCiAgICA+PiBhIHN0cm9uZyBhcmd1bWVudCBmb3Igc3VwcG9ydGluZy4g V2UgaGF2ZSBzcGVudCBjb3VudGxlc3MgY3ljbGVzIG9uDQogICAgPj4gZGVzaWduaW5nIGFyb3Vu ZCB1bmNlcnRhaW4gYW5kIHVua25vd24gaW50ZXJtZWRpYXJ5IGJlaGF2aW9ycyBpbiB2YXJpb3Vz DQogICAgPj4gcGFydHMgb2YgdGhlIElFVEYsIGFuZCBJIGRvbid0IHdhbnQgdXMgdG8gcmVjcmVh dGUgdGhlc2UgYm9vZ2V5bWVuLiBJIHRoaW5rDQogICAgPj4gaXQncyByZWFzb25hYmxlIHRvIHJ1 bGUgb3V0IGNsYXNzZXMgb2YgbWlkZGxlYm94ZXMgaWYgd2UgZG9uJ3QgaGF2ZSBzdHJvbmcNCiAg ICA+PiBhcmd1bWVudHMgZm9yIHN1cHBvcnRpbmcgdGhlbS4NCiAgICA+Pg0KICAgID4NCiAgICA+ DQogICAgDQoNCg== From nobody Thu Jan 18 15:11:06 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC95129C6E for ; Thu, 18 Jan 2018 15:11:04 -0800 (PST) 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 UAm1PY020v_Y for ; Thu, 18 Jan 2018 15:11:02 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 C43E0126C3D for ; Thu, 18 Jan 2018 15:11:01 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id t35so14960783otd.13 for ; Thu, 18 Jan 2018 15:11:01 -0800 (PST) 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=TxmbbEMTlcqFScZ5J+Nlp5Zj02IbT1nKoCbakfhZdzQ=; b=ktyObuqpldAHpdK5GTjx34zD6lk/+ij7oe1laSsW7gKA+s/PuW807sM96XeM7NIpXE 7N5gArp/fvWqgTwjZsg26Zm+SOiEhZI1ThLazOgEaSgYLZ1OHR9ocyO2lkk75cd33V35 xadu9CuWtvtji0CaoFxTUJ7e7XJUXfXUN7Vsn9HsLP4W9LY6S3oiBbuyeabqAaR2drq1 YIu9ErTYR4kSOQTubfsDr672jIhI4A3z7UcgCWYy/p03ucHhbh9b9EsBRUm9S95UQwe1 FWnG+45HC2A/miB/RKyyCSK0YSVfirwSDNSiTlehsJaIOI2TPv/dZq9Bo1zwKygbXhIi hr7g== 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=TxmbbEMTlcqFScZ5J+Nlp5Zj02IbT1nKoCbakfhZdzQ=; b=Z6a0JZUqzdDeyfIkTAS4/J2eaEr9S0cPPdqqPavHGtFV6YhCOiwzqJLRFWWFtg9+Yz syq1Xl33L2AvARvyiRg8XUF0qbyw1GckGROmUCUaQ8gqh89JyIEBHYnKr4cMJHKsNXoi NnIqRVouypJSaUMtlnf4waWKtNCSTXXIY0v8za17TduhkSvSQ+YlBtDPNlbNxkTTdHBS SNIBAdFJJtnxWC6AEZY+u9jBYdJ1vLLsfAR9KL0ebZBNqsMZR4m70uAQlPM6IHRAtOVi VV99Qn81q1/beasSNbIZPoeplb44Z9IFK/y4iYLZJUTVIlPWw8j2l1aRd7BimAk61oEa npwA== X-Gm-Message-State: AKwxytcx+rTu7EEoYBETgTO+nbP0+zLEWDJB1ymMZMXlN90diP0Uk2Iz p+9liSjXl9LFuvnadELhP6njAEpADJGOhGtM3ys= X-Google-Smtp-Source: ACJfBouCnzpNXE456TljIG5fB9/HHDMsw4rXrFVpgin/InrIzdCSuG7uTeJ4n6bj+rxACV76W8+kIPRDAx9xR/BVm/s= X-Received: by 10.157.68.154 with SMTP id v26mr4546151ote.308.1516317060609; Thu, 18 Jan 2018 15:11:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.39.16 with HTTP; Thu, 18 Jan 2018 15:10:59 -0800 (PST) In-Reply-To: <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch> References: <20180110194716.GA30573@ubuntu-dmitri> <20180110200646.GB30573@ubuntu-dmitri> <20180110202357.GC30573@ubuntu-dmitri> <51C80222-9513-4CF6-82FD-5692C1DAB058@fb.com> <96c30da5-d7ab-d7cf-32c6-262183232a24@tik.ee.ethz.ch> From: Martin Thomson Date: Fri, 19 Jan 2018 10:10:59 +1100 Message-ID: Subject: Re: Deadlocking in the transport To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Ian Swett , Jana Iyengar , QUIC WG , Roberto Peon Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 23:11:04 -0000 Let's be really crisp about what we mean here. I think that we have used "middlebox" to refer to those things that are on path, but do not hold keys. In contrast, this is an issue that affects intermediation by entities that terminate the security association. These entities hold keys. Specifically, this is an issue when those intermediaries only understand QUIC-the-transport-protocol, and not the thing that is running atop it. I separately have a little trouble with the assertion that you might want to terminate transport on path. Managing trust there is basically intractable (ask around for the history of "trusted proxy" discussions in HTTP if you don't believe me). Also, that sort of termination is a large part of why QUIC encrypts. On Thu, Jan 18, 2018 at 8:29 PM, Mirja K=C3=BChlewind wrote: > Hi all, > > while I agree that we need to decide which middlebox behavior we want to > support, I don't really think this is a middlebox issue. If the transport > you are using is offering you an interface where you can send data over > independent streams (which was the goal to avoid HOL blocking) but the > application sends not-independent data over the streams, it is an > application-layer issue to handle that. > > Regarding middlebox behavior, I think we should support transport level > proxies because especially in mobile networks where the link characterist= ics > are quite different from the rest of the network this seems still to be t= he > appropriate solution. However, I would wish that we could separate transp= ort > state from end-to-end payload encryption and would not need to terminate > both... > > Mirja > > > > > On 18.01.2018 08:21, Martin Thomson wrote: >> >> Yes, what Ian said (and more to what Jana said). I think that we've >> some proportion of the working group who are operating on one set of >> assumptions and another on a different set of assumptions on this >> subject. Until now, that didn't bother me much. After all, that's >> normal for a whole range of issues. >> >> Now there's a concrete problem, so let's dig into this properly. >> >> FWIW, I don't think that we'll resolve this particular issue in >> Melbourne, but I hope that we can at least start that process. This >> promises to be interesting. >> >> On Thu, Jan 18, 2018 at 9:36 AM, Ian Swett wrote: >>> >>> +1 million >>> >>> On Wed, Jan 17, 2018 at 4:43 PM, Jana Iyengar wrote: >>>> >>>> >>>> We will discuss this at the interim, but one comment, inline. >>>> >>>>> >>>>> In part, it's the ignorance of the intermediary that causes this >>>>> particular problem. If the intermediary was aware of the protocol >>>>> details then it might be able to recognize and avoid these situations= , >>>>> but that seems a little too much to expect of intermediaries. Ruling >>>>> out the entire class of intermediary that operates purely at the >>>>> transport layer is extremely harsh. >>>>> >>>>> What is more likely here is that we describe this situation, explain >>>>> that it is impossible to prevent in the presence of intermediation, >>>>> and explain how to kill the right streams in order to ensure forward >>>>> progress doesn't stall indefinitely. >>>> >>>> >>>> >>>> Exactly because intermediaries make things difficult, it's important t= o >>>> be >>>> certain that the intermediary behavior we are discussing is one that >>>> there's >>>> a strong argument for supporting. We have spent countless cycles on >>>> designing around uncertain and unknown intermediary behaviors in vario= us >>>> parts of the IETF, and I don't want us to recreate these boogeymen. I >>>> think >>>> it's reasonable to rule out classes of middleboxes if we don't have >>>> strong >>>> arguments for supporting them. >>>> >>> >>> >> > From nobody Thu Jan 18 21:12:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A33212711E for ; Thu, 18 Jan 2018 21:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=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 hztiybTREpL2 for ; Thu, 18 Jan 2018 21:12:45 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D840A127342 for ; Thu, 18 Jan 2018 21:12:44 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,380,1511856000"; d="asc'?scan'208";a="251167483" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx141-out.netapp.com with ESMTP; 18 Jan 2018 21:12:44 -0800 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 18 Jan 2018 21:12:44 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Thu, 18 Jan 2018 21:12:44 -0800 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=LcO6tq/AzDOxWLBYiGrrQ8Ti/ysRapcG5Y+gRi2Gnz0=; b=gnfgs3Ldaurvv/OG4dujCI7k/4ZpMfAC8v/WKK10aQQKZ9yKhE84FPHpD/kiwMS06Adv+mnn7PVGr4h+9DApsO6Knvc0iR6YELcUtogpqphVP6lS9wCVrkrM49DL98NPVEk2yn9z6PuTs7CU0yITaGHuTh5LUCqCwvbwccsu7Nc= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB146.namprd06.prod.outlook.com (10.242.190.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.407.7; Fri, 19 Jan 2018 05:12:42 +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.20.0428.014; Fri, 19 Jan 2018 05:12:41 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Wanted: presentations for interim Thread-Topic: Wanted: presentations for interim Thread-Index: AQHTkOQh1C+OAmkWrkWg7d+h7FCfaw== Date: Fri, 19 Jan 2018 05:12:41 +0000 Message-ID: <4C89FC5D-D857-4F19-8F41-437EFAB573D5@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [203.38.90.218] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB146; 7:6wHBrcQx9UKeUxLCH03Thxtp7JPYc1IO+6r/v5BUJcS3FMVukxZ+t/WiEkxEpGCc7vdhfGofH3DxwRLcs57B2jTY+L3vI/uub4lyESGGX6d96pHoZLFbPELqgPWZwikLqAigeFRhE6USC2Pehd7+bMsC0d3DybtHVi55oQXkPk5NKIZJ0FPoPPTAtXUHgaDINv9lOdTLaXwp5hhojsFS73MRBM3IKF3LEQ6qie8fJAxG+nqUJc/WulYiA8CJI9hN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7e70cd82-7c7a-4b16-33f8-08d55efb4446 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB146; x-ms-traffictypediagnostic: BLUPR06MB146: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040470)(2401047)(8121501046)(5005006)(3231023)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041268)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB146; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB146; x-forefront-prvs: 0557CBAD84 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(396003)(39380400002)(366004)(376002)(189003)(199004)(6306002)(81156014)(966005)(478600001)(81166006)(25786009)(82746002)(33656002)(53936002)(68736007)(6506007)(36756003)(99286004)(66066001)(14454004)(106356001)(50226002)(59450400001)(6436002)(102836004)(8676002)(83716003)(77096007)(2906002)(8936002)(316002)(105586002)(86362001)(3660700001)(2900100001)(99936001)(5660300001)(6916009)(6486002)(7736002)(305945005)(57306001)(97736004)(26005)(3846002)(6116002)(3280700002)(6512007); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB146; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: HyGmsbJl2AtzUlI0BgJCKta+Jpl+KAD1/fKceZWDC56TsPtBBR3NQ9iPKuxc2CCtaYnAZkt7zlA7qyX8ldiUNw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5941C503-CFED-4469-8175-7D8E47127100"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7e70cd82-7c7a-4b16-33f8-08d55efb4446 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2018 05:12:41.7109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB146 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, 19 Jan 2018 05:12:46 -0000 --Apple-Mail=_5941C503-CFED-4469-8175-7D8E47127100 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, for those of you on the agenda to present at the interim next week, = please send your final presentations ASAP. Preferred way is a pull request against the wg-materials repository = (example: https://github.com/quicwg/wg-materials/pull/20). We'll populate the datatracker from GitHub on Monday or early Tuesday. Thanks, Lars --Apple-Mail=_5941C503-CFED-4469-8175-7D8E47127100 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlphfkgACgkQVLXDCb9w wVc9NQ/+MchrBXxwSE8v74I0cwPCPqg6SomM3Zdb1SrR94/HjlitnQJOaj/6rkDb tL2jA/5OEMwo5FIa1CzQsJ3UOnA0L/nHRmQVNp0SPKiRMua9T6xGtoh1rSsurysD E8ELRk9KZdE2yTlbmDeLyg0/A+K1Dvbm5ldGuzu0z0GgaUWgMtgkfJMmWUxavXzs rVDwG1NrW2L2ggF1KUH6g5pI1DnoSVujtG0PZiRJhxcLPqvIZHYu9uA7VeGIn6wh 98moz7SwdfXvEGGeOJBRkp/iyPYaDowZjPq77q1AIlZ5GgQOqxRN8t31vCCnO+++ W8owAojxoQnmDUteJD5e7p+Di+++PaAPYDC3b3vCfFO83A0MrSubtPKvo/oRt6h0 r7EulMujc3GXIpF+8KNb6i85yxNWxz7b6mN6fttD8ssYik/JPxcoyJBI62Sj+/FV 1Y9sjPGrFTxTDsGNUIBwlXwVWnGUyyhOAoYEtBQvo/jF+bFldLyt0auArtWo4G5D scDaX+I76qQaEGKMAFhBFrLaqtGKOMiZ2E7bP5vZ6smb2nhYPzbciDf5wwJDDAvm UWi8RZOeXc4Fs6Hjw0u6x9RMxw0y+oRXfPz16245dlh/osPj90tV7nm1/7WpQ5Zh U1bkqqivJzCU3nOrAI5Osc3KJOK08ESrpUCtjd5Yp6R5KVJFHyc= =bDvV -----END PGP SIGNATURE----- --Apple-Mail=_5941C503-CFED-4469-8175-7D8E47127100-- From nobody Fri Jan 19 18:09:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B98D1273B1 for ; Fri, 19 Jan 2018 18:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUGomALS2g9S for ; Fri, 19 Jan 2018 18:09:04 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B70D124BAC for ; Fri, 19 Jan 2018 18:09:04 -0800 (PST) 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=UTwEBbW9dbaPL+UoTlGybKtarG33WONkv6kXJ05Xbxg=; b=jvJI8/5ZSy9Y2SSw3kerVVKLKsMk12pB/Op0RuybsLEFW8XYsyCeZqagCAa9whtE11N228SlSXhL2v7vu5JruwRqtV/l+QwkllE1UCIUYp3G3BaJzObU5vBG4/ql9pYnd/ml2usbZO59orws9wCPLNHM5HgWg6f6rKCrG0EOSWU= Received: from DM5PR21MB0140.namprd21.prod.outlook.com (10.173.173.15) by DM5PR21MB0827.namprd21.prod.outlook.com (10.173.172.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.444.7; Sat, 20 Jan 2018 02:09:02 +0000 Received: from DM5PR21MB0140.namprd21.prod.outlook.com ([10.173.173.15]) by DM5PR21MB0140.namprd21.prod.outlook.com ([10.173.173.15]) with mapi id 15.20.0444.004; Sat, 20 Jan 2018 02:09:02 +0000 From: Praveen Balasubramanian To: IETF QUIC WG Subject: Review of draft-ietf-quic-recovery-08 Thread-Topic: Review of draft-ietf-quic-recovery-08 Thread-Index: AdORjmRPMviMG51TQciBUgn+esABGQ== Date: Sat, 20 Jan 2018 02:09:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:f::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0827; 7:1zclbYRkpuo42K7GRxBiwgb3MYV7J1RA5syNyMohlUJLqx2Zq13OoD56zvtAsNiSdJfnid0RY+P7X8M4juESlybJ+H0hMvuTnaTF42jzn4txDnDd+gW/y9jUarU7YpDxCxbI83Z3Eyg2ziIY026LorJ8xtUfAILMuxwfCu5nKSiRocsHPGBLuJBff3noTmu1/RKbptWEgytQdzO7CWd+iTww792Wq50bFaDb+n2bRJ6ow3gEkTHLw27VWDsMQrDC x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5164f7e4-9c5a-41a5-d5e6-08d55faac6f1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534125)(4602075)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:DM5PR21MB0827; x-ms-traffictypediagnostic: DM5PR21MB0827: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231046)(2400081)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR21MB0827; BCL:0; PCL:0; RULEID:(100000803126)(100110400120); SRVR:DM5PR21MB0827; x-forefront-prvs: 0558D3C5AC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(366004)(346002)(39380400002)(189003)(199004)(966005)(10290500003)(230783001)(10090500001)(9686003)(236005)(478600001)(33656002)(86612001)(6436002)(790700001)(54896002)(55016002)(53936002)(6116002)(97736004)(6306002)(8936002)(8990500004)(2906002)(25786009)(6346003)(2900100001)(74316002)(316002)(68736007)(102836004)(3280700002)(6506007)(81166006)(77096007)(22452003)(86362001)(14454004)(7736002)(8676002)(81156014)(5660300001)(606006)(99286004)(6916009)(3660700001)(59450400001)(106356001)(7696005)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0827; H:DM5PR21MB0140.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: +lwopWgiDdtXBcg0g9F66wa4CVBweBRzwYCjCuG2CRYkvRoYIwqR+MhaiamjxR07FXW9IPoV5PrZJ1LrALfwZw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0140970AEECE237E9F02D131B6EE0DM5PR21MB0140namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5164f7e4-9c5a-41a5-d5e6-08d55faac6f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2018 02:09:02.7678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0827 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 20 Jan 2018 02:09:07 -0000 --_000_DM5PR21MB0140970AEECE237E9F02D131B6EE0DM5PR21MB0140namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 2.1.4. "This mechanism also allows a receiver to measure and report the delay from when a packet was received by the OS kernel, which is useful in receivers which may incur delays such as context-switch latency before a userspace QUIC receiver processes a received packet. " Such context switch delays are possible in a kernel implementation as well = based on whether execution is deferred to worker threads. Suggest that we r= emove the userspace word. Section 3.1 "Ignoring ack delay for min RTT prevents intentional or unintentional underestimation of min RTT, which in turn prevents underestimating smoothed RTT." Does this prevent converging to the actual minimum RTT if the receiver is a= lways delaying ACKs. I can't tell for sure if this will hurt congestion con= trol algorithms like BBR and LEDBAT. Section 3.2.1 It seems in general that the text does not specify the actions to take as a= result of loss detection whereas the pseudocode does (for example cwnd red= uctions). Should we add a section on "Congestion Control" before the pseud= o code? Section 3.3.1 "PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, 10ms)" https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rack has an explanati= on for the 10ms value. Should it be a goal to explain the rationale for it = here or do we point the reader to the RACK draft? Section 3.3.2 "When this alarm fires, the sender sends two packets, to evoke acknowledgements from the receiver, and restarts the RTO alarm. kMinimumWindow (default 2 * kDefaultMss): Default minimum congestion window." This implies that the slow start process post loss for a QUIC flow will be = twice as aggressive as TCP sharing the same bottleneck link. Is it a goal t= hat we want to fair share with TCP? If 2 is the right value of cwnd post ti= meout, should TCP implementations also switch to this? Seems like 2 versus = 1 is worthy of an experiment if its not been done before. Is this better tr= acked as a github issue? "QUIC's RTO algorithm differs from TCP in that the firing of an RTO alarm is not considered a strong enough signal of packet loss, so does not result in an immediate change to congestion window or recovery state" I found this sentence a bit misleading and seems to imply that a genuine RT= O does not alter congestion window state. The pseudocode does change the cw= nd to kMinimumWindow post a confirmed RTO and I think it should. Section 3 seems to be missing "Time Based Loss Detection" section but the p= seudocode uses kUsingTimeLossDetection. Section 3.4.7.3 "It is part of QUIC's time based loss detection" ER is listed in Ack-based detection in section 3.2.2. Section 4 "QUIC's congestion control is based on TCP NewReno[RFC6582] congestion control to determine the congestion window and pacing rate." Looks like pacing is addressed in the editors copy already and this sentenc= e has been modified to not reference pacing as part of NewReno. Section 4.6 in Editor's copy "It is RECOMMENDED that a sender pace sending of all data" I think we will have to mark it a MUST for safety. Since QUIC increases the= congestion window by the number of acknowledged bytes when each ack is pr= ocessed and there is no ABC limit, not having pacing will cause burst losse= s. OR maybe we should just call out the problems by not pacing. Thoughts? Section 4.3 "from TCP's definition of recovery ending when the lost packet that started recovery is acknowledged" I saw the discussion on this in the mailing list. I think we should call ou= t that while QUIC can as a result drop the cwnd multiple times if there is = sustained loss, this definition of recovery exit primarily serves to ensure= the cwnd is dropped only once per RTT. Is there any other side effect I am= missing? Section 4.6 "In order to fairly compete with flows that are not pacing, it is recommended to not pace the first 10 sent packets when exiting quiescence." This is now not in the Editor's copy so I assume this is not required. Is t= here a quiescence check in gQUIC? Does Linux TCP consistently pace througho= ut? Section 4.7.1. "kDefaultMss" I think we should just have kMss and have that used everywhere and initiali= ze kMss to max(kDefaultMss, "PMTU discovery MSS"). --_000_DM5PR21MB0140970AEECE237E9F02D131B6EE0DM5PR21MB0140namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Section 2.1.4. 

    “This mechanism also allows a receiver to measure and report the=

       delay from when a packet was received by the = OS kernel, which is

       useful in receivers which may incur delays su= ch as context-switch

       latency before a userspace QUIC receiver proc= esses a received packet.

    “

    Such context switch delays are possible in a kernel = implementation as well based on whether execution is deferred to worker thr= eads. Suggest that we remove the userspace word.

     

     

    Section 3.1

    “Ignoring ack delay for min RTT prevents
       intentional or unintentional underestimation of min RTT, =
which in
       turn prevents underestimating smoothed RTT.”

    Does this prevent converging to the actual minimum R= TT if the receiver is always delaying ACKs. I can’t tell for sure if = this will hurt congestion control algorithms like BBR and LEDBAT.

     

     

    Section 3.2.1

    It seems in general that the text does not specify t= he actions to take as a result of loss detection whereas the pseudocode doe= s (for example cwnd reductions). Should we add a section on  “Co= ngestion Control” before the pseudo code?

     

    Section 3.3.1

    “PTO SHOULD be scheduled for max(1.5*SRTT+MaxAckDelay, 10ms)=
”

     

    https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-ra= ck has an explanation for the 10ms value. Should it be a goal to explai= n the rationale for it here or do we point the reader to the RACK draft?

     

    Section 3.3.2

    “When this alarm fires, the sender sends two packets, to
       evoke acknowledgements from the receiver, and restarts th=
e RTO alarm.
    kMinimumWindow (default 2 * kDefaultMss):  Default minimum conges=
tion
          window.”
     

    This implies that the slow start process post loss f= or a QUIC flow will be twice as aggressive as TCP sharing the same bottlene= ck link. Is it a goal that we want to fair share with TCP? If 2 is the righ= t value of cwnd post timeout, should TCP implementations also switch to this? Seems like 2 versus 1 is worthy o= f an experiment if its not been done before. Is this better tracked as a gi= thub issue?

     

     

    “QUIC's RTO algorithm differs from TCP in that the f= iring of an RTO

       alarm is not considered a strong enough signa= l of packet loss, so

       does not result in an immediate change to con= gestion window or

       recovery state”

     

    I found this sentence a bit misleading and seems to = imply that a genuine RTO does not alter congestion window state. The pseudo= code does change the cwnd to kMinimumWindow post a confirmed RTO and I thin= k it should.

     

     

     

    Section 3 seems to be missing “Time Based Loss= Detection” section but the pseudocode uses kUsingTimeLossDetection.

     

     

     

    Section 3.4.7.3

    “It

       is part of QUIC's time based loss detec= tion”

    ER is listed in Ack-based detection in section 3.2.2= .

     

     

     

    Section 4

    “QUIC's congestion control is based on TCP NewReno[R= FC6582] congestion

       control to determine the congestion win= dow and pacing rate.”

    Looks like pacing is addressed in the editors copy a= lready and this sentence has been modified to not reference pacing as part = of NewReno.

     

    Section 4.6 in Editor’s copy

    “It is RECOMMENDED that a sender pace sending = of all data”

    I think we will have to mark it a MUST for safety. S= ince QUIC increases the congestion window by the number of  acknowledg= ed bytes when each ack is processed and there is no ABC limit, not having p= acing will cause burst losses. OR maybe we should just call out the problems by not pacing. Thoughts?

     

    Section 4.3

    “from TCP's definition of recovery ending when= the lost packet that

       started recovery is acknowledged”=

    I saw the discussion on this in the mailing list. I = think we should call out that while QUIC can as a result drop the cwnd mult= iple times if there is sustained loss, this definition of recovery exit pri= marily serves to ensure the cwnd is dropped only once per RTT. Is there any other side effect I am missing?

     

     

    Section 4.6

    “In order to fairly compete with flows that ar= e

       not pacing, it is recommended to not pa= ce the first 10 sent packets

       when exiting quiescence.”

    This is now not in the Editor’s copy so I assu= me this is not required. Is there a quiescence check in gQUIC? Does Linux T= CP consistently pace throughout?

     

     

    Section 4.7.1.

    “kDefaultMss”

    I think we should just have kMss and have that used = everywhere and initialize kMss to max(kDefaultMss, “PMTU discovery MS= S”).

    --_000_DM5PR21MB0140970AEECE237E9F02D131B6EE0DM5PR21MB0140namp_-- From nobody Sat Jan 20 16:45:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D4C126DC2 for ; Sat, 20 Jan 2018 16:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=FSM6ybcp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=arTwTrZc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slUtTyKr-j2D for ; Sat, 20 Jan 2018 16:45:18 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6B9B126BF0 for ; Sat, 20 Jan 2018 16:45:18 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 3F78520C11 for ; Sat, 20 Jan 2018 19:45:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 20 Jan 2018 19:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=L2BTDOBHNfe/+Sthc dQ7+xUsQoFg5RTo7kZcQW1LhVM=; b=FSM6ybcpiyQ5yiDV67nLNsMUIC6d9gtcz moqXIjJ31vEk11mTBTTPXnE0cEfyQKc6xVcXVmxKfZ95loK53QoLSk2zSDSoKvrc nGOeyDltsbyimRVs83Z0tYbwR4Nf1mswaRpuTykQIIWj6jhGJDwKZaEeCnlSit6S zjUgdXpzjyFvgIKYjs+RdKDc8YRVTgyS/4p2lO8tkymwbX9WDN7AsasULNDvueHt a15KCbWy348rAdHEi3fYGE30/izrFvJBN4R5HdZUqULvn9vg4fk30/z64sAn+2kK kXIBljq3RSza6P1pWUH7jsDJBS0sn8LaJhBuSGRPemLnLb19t6R9w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=L2BTDOBHNfe/+SthcdQ7+xUsQoFg5RTo7kZcQW1LhVM=; b=arTwTrZc Q0Tq0paOtg4FzrlS7idZmD+VuQ9pyyLOAQsIvkNWBEQYl5L9n2AUG+uvEhseUKw8 ZyJ6sXPvvGSkTVeqDufpPFfCYm6T3/ijoE33SRLb8Ta6xxY5+2hog2ipPDZoIMzS ceH3iIsgF+qcnXcqC118o3UVAVDf5r0lIYrrN+DFTYvEG6931hFtwaep64l47BZw 07M/eJTn2q30wkD9wcQkSDIaopvIKYiiz6HLlWLrt+cA8HCw/KeD8olBzXGLHuTw 6aeNKKzrXNSIl6Zy4JtjOv2CfhFd+8rV6aIBVGJw+AsU1+I9kW6Dl7HgRvy4Oc3s dUD70ucg9yygnQ== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B0E32418B for ; Sat, 20 Jan 2018 19:45:16 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id EB318C766D for ; Sun, 21 Jan 2018 00:45:13 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1819121680935186317==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180121004513.EB318C766D@cloud.mnot.net> Date: Sun, 21 Jan 2018 00:45:13 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 21 Jan 2018 00:45:22 -0000 --===============1819121680935186317== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+4/-14/=F0=9F=92=AC52) 4 issues created: - Definition of Recovery End (by nibanks) https://github.com/quicwg/base-drafts/issues/1059 - "CanSendPacket" function or equivalent function (by martinthomson) https://github.com/quicwg/base-drafts/issues/1056 - Increase the size of connection ID (by martinthomson) https://github.com/quicwg/base-drafts/issues/1052 - PING/PONG ambiguity (by boisjacques) https://github.com/quicwg/base-drafts/issues/1051 25 issues received 52 new comments: - #219 Increasing initial flow control window for streams (11 by mikkelfj= , mcmanus, martinthomson, ianswett) https://github.com/quicwg/base-drafts/issues/219 - #203 Connection migration should be indistinguishable from a new connec= tion (4 by mirjak, martinthomson, ianswett, mikkelfj) https://github.com/quicwg/base-drafts/issues/203 - #751 Handling un-ackable packets (4 by martinthomson, janaiyengar, mikk= elfj) https://github.com/quicwg/base-drafts/issues/751 - #1047 Handling of Frames Inappropriate for Unidirectional Streams (3 by= martinthomson, janaiyengar, martinduke) https://github.com/quicwg/base-drafts/issues/1047 - #1048 Packet number rework (3 by martinthomson, hardie) https://github.com/quicwg/base-drafts/issues/1048 - #1051 PING/PONG ambiguity (3 by martinthomson, boisjacques, mikkelfj) https://github.com/quicwg/base-drafts/issues/1051 - #1055 Exclusion from congestion control for ACK (3 by martinthomson, ro= nieven, ianswett) https://github.com/quicwg/base-drafts/issues/1055 - #1056 "CanSendPacket" function or equivalent function (3 by martinthoms= on, janaiyengar, ianswett) https://github.com/quicwg/base-drafts/issues/1056 - #1059 Definition of Recovery End (2 by martinthomson, janaiyengar) https://github.com/quicwg/base-drafts/issues/1059 - #778 Streams start as "idle" (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/778 - #783 QUIC streams abstraction (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/783 - #912 No way to explicitly communicate an ack delay (1 by janaiyengar) https://github.com/quicwg/base-drafts/issues/912 - #917 Allow removal of ACK blocks that are in flight (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/917 - #1050 STOP_SENDING before stream open (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1050 - #942 Do you need to supply max_early_data in NST to enable 0-RTT (1 by = martinthomson) https://github.com/quicwg/base-drafts/issues/942 - #816 Version Negotiation when Version =3D 0 (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/816 - #568 Cleartext integrity as version independent (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/568 - #826 clients always must regenerate client hello (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/826 - #707 Changelog in Transport (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/707 - #464 Rename CONNECTION_CLOSE (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/464 - #466 Stateless Reset from clients (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/466 - #230 When/how often to send ACK frames (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/230 - #487 Long and short packet type 00? (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/487 - #502 Rename connection id (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/502 - #1023 Is zero a valid stream-ID in Transport Parameters? (1 by martindu= ke) https://github.com/quicwg/base-drafts/issues/1023 14 issues closed: - Definition of Recovery End https://github.com/quicwg/base-drafts/issues= /1059 - No way to explicitly communicate an ack delay https://github.com/quicwg= /base-drafts/issues/912 - Do you need to supply max_early_data in NST to enable 0-RTT https://git= hub.com/quicwg/base-drafts/issues/942 - Clarify normative language for Transport Parameter omit_connection_id h= ttps://github.com/quicwg/base-drafts/issues/953 - Version Negotiation when Version =3D 0 https://github.com/quicwg/base-d= rafts/issues/816 - Allow removal of ACK blocks that are in flight https://github.com/quicw= g/base-drafts/issues/917 - Streams start as "idle" https://github.com/quicwg/base-drafts/issues/778 - clients always must regenerate client hello https://github.com/quicwg/b= ase-drafts/issues/826 - Changelog in Transport https://github.com/quicwg/base-drafts/issues/707 - Graceful shutdown https://github.com/quicwg/base-drafts/issues/604 - Rename connection id https://github.com/quicwg/base-drafts/issues/502 - Cleartext integrity as version independent https://github.com/quicwg/ba= se-drafts/issues/568 - Rename CONNECTION_CLOSE https://github.com/quicwg/base-drafts/issues/464 - Long and short packet type 00? https://github.com/quicwg/base-drafts/is= sues/487 Pull requests ------------- * quicwg/base-drafts (+4/-0/=F0=9F=92=AC17) 4 pull requests submitted: - Remove transport parameters from NewSessionTicket (by martinthomson) https://github.com/quicwg/base-drafts/pull/1058 - Remove cross-protocol resumption (by martinthomson) https://github.com/quicwg/base-drafts/pull/1057 - Tweak send stream figure (by martinthomson) https://github.com/quicwg/base-drafts/pull/1054 - Rework packetization section (by martinthomson) https://github.com/quicwg/base-drafts/pull/1053 4 pull requests received 17 new comments: - #1058 Remove transport parameters from NewSessionTicket (9 by martintho= mson, ianswett, janaiyengar, hardie) https://github.com/quicwg/base-drafts/pull/1058 - #1039 Rewrite text about Version Negotiation (6 by martinthomson, marti= nduke, mikkelfj) https://github.com/quicwg/base-drafts/pull/1039 - #1032 Python linting script (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1032 - #609 Latency Spin Bit (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/609 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1819121680935186317== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

    Sunday January 21, 2018

    Issues

    quicwg/base-drafts (+4/-14/=F0=9F=92=AC52)

    4 issues created:

    25 issues received 52 new comments:

    14 issues closed:

    Pull requests

    quicwg/base-drafts (+4/-0/=F0=9F=92=AC17)

    4 pull requests submitted:

    4 pull requests received 17 new comments:

    Repositories tracked by this digest:

    --===============1819121680935186317==-- From nobody Sat Jan 20 22:10:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07B8126CD8 for ; Sat, 20 Jan 2018 22:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEVtEQ4fRIrh for ; Sat, 20 Jan 2018 22:10:45 -0800 (PST) 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 5EB19126C83 for ; Sat, 20 Jan 2018 22:10:45 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ed8q2-0007HL-GJ for quic@ietf.org; Sun, 21 Jan 2018 07:10:43 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ed8pz-0002x8-QY for quic@ietf.org; Sun, 21 Jan 2018 01:10:40 -0500 Received: (qmail 25705 invoked from network); 21 Jan 2018 06:10:37 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Jan 2018 06:10:37 -0000 To: Michael Tuexen References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG From: Christian Huitema Message-ID: <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> Date: Sat, 20 Jan 2018 20:10:34 -1000 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: <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> Content-Type: multipart/alternative; boundary="------------D0A2405547FB08E6C3809962" Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5il7EG9TbWSGhDGl5JbJQMoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvr1TWd95YLbTMNwzaw0iTwB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P/oQ1EzuEfiLKxxAy46D0GjGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA+RIanNskcVaAsgQvWYhIsUONoJfh+XjGSeeT90H/uIFb b4HHKRuIHoQeG0jQmHnJeoPXVyRORlQAvrAqTChPtGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWN4ZNH6v0KsokFeP+Z5h4BvfFcHV2tQAVqGdj/zM7G/GWbjl4MpjTNPMnYcbh6U8Z5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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: Sun, 21 Jan 2018 06:10:48 -0000 This is a multi-part message in MIME format. --------------D0A2405547FB08E6C3809962 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/10/2018 8:57 AM, Michael Tuexen wrote: >> Several QUIC implementations do PMTUD already, building simple probes = with QUIC's Ping and Padding frames. Probes are then encrypted, and sent = as QUIC packets in UDP with segmentation turned off. If the probe packet = is acknowledged, the applications know that this much MTU can be sent. > Your description of the probe packets is the one we have in mind. It ju= st needs to be specified. > The more interesting part of the document is the way (when and which si= ze) you probe, > not how you probe. >> Note the encrypted part. Replacing such mechanisms by a clear text exc= hange is not desirable. > And not intended... Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema --------------D0A2405547FB08E6C3809962 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

    On 1/10/2018 8:57 AM, Michael Tuexen wrote:

    Several QUIC implementations do PMTUD already, building simple probes with QUIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC packets in UDP with segmentation turned off. If the probe packet is acknowledged, the applications know that this much MTU can be sent.

    Your description of the probe packets is the one we have in mind. It just needs to be specified.
The more interesting part of the document is the way (when and which size) you probe,
not how you probe.

    Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.

    And not intended...

    Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size.

    -- Christian Huitema
    --------------D0A2405547FB08E6C3809962-- From nobody Sun Jan 21 00:28:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAA1127241; Sun, 21 Jan 2018 00:28:37 -0800 (PST) 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 QCm3NIf0nT6c; Sun, 21 Jan 2018 00:28:34 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001: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 C8C8F120725; Sun, 21 Jan 2018 00:28:34 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id t22so6384721ioa.7; Sun, 21 Jan 2018 00:28:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=pHvLDSoPhIToZ2A7CUeArUyLwpGyphMOE7TAXm5L1VM=; b=c20a58TC4Qx06hfRqJqVITAuiZjqTY5OYgUwipsxCyoGazwaL3yfJGsO97AbvBOVbh arM0KMgoEqpW2x1DgOAqm4JN7fYsvTcIa0ZNprrnNR9q8kT2IA4h+QJ/Oxs/Z3F+RF9a XygoIPDYwE4LDTLZ8Ox3exVRAahBie0DAYl512Ro/jONdD8cnNle0i4gdV98+bf/l2bh XuHRwBLzp0UjXeVt+R+Jawjz38nufftXJD9CWUKEwghBkFK5c1Cf+k9i0FGNvDceJ4QX bKNLQr6INezZPIiObzkSxf1RU2QmDBGrv5N0qNml8+JKw7lBAPBLidDZjXt5hE3pNoRb XG+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=pHvLDSoPhIToZ2A7CUeArUyLwpGyphMOE7TAXm5L1VM=; b=ggSminGFYZjsmfsULjZ5EgY3G4JzckzN4rKIl5Ice0BBOLwfiVpGRYbiFNK1uLAJ42 UW2EM/tNnmlx2jl6bYFBgU7i9Gvy1+59zxcyjMZubd4sBOYSAVurysr1eHUjgrHonFea RKxn4PHFlCggj+WjugDC49uIblX6xHYWZq3KxnevYXk1a0au9PQ6TDnlsfHkIVfAknSI x69ZPE1t9o8KPRzv7EWKmkwwDqmX6HUnCOP8nKPrNo8Yn3zrCSig3y4xvn4jzZfo6Kqg qgwUEFGit05EfCN6uxDkwUR3tu3riI0KYFL3SedKNoIszhu4KHQiiRIAeSEinqOSZT2B JfqA== X-Gm-Message-State: AKwxyte36gXNeQiYyqRcRL70IQjEpwg5n0vFlQgsibnxHP8VmhYCe3WK JlHsM1ciBTFcnHMXa3CjA1HVbfuiymvFajbGGlY= X-Google-Smtp-Source: AH8x227NzXt1LSCiVGkSc+vfI3cuPWnTLsy5oBnniCzZJPI6aoe9k8+3kTXA30amVF3Dd7LFFWSdDrVDq6N+MlOUNdI= X-Received: by 10.107.3.209 with SMTP id e78mr3870586ioi.96.1516523313813; Sun, 21 Jan 2018 00:28:33 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jan 2018 00:28:32 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 21 Jan 2018 00:28:32 -0800 Message-ID: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 To: Christian Huitema , Michael Tuexen Cc: Gorry Fairhurst , "Black, David" , QUIC WG , "Eggert, Lars" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="001a113dea6469dcbc05634519de" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 21 Jan 2018 08:28:37 -0000 --001a113dea6469dcbc05634519de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true. I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s= earlier since early guesses are more likely to succeed. /* roughly like this - untestet */ a =3D minPMTU b =3D maxPMTU k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */ while a <=3D b k =3D min(a + k, b) - a n =3D binsearch(a, a + k - 1) if n return n a =3D a + k /* this doubles the search range */ end return not found https://en.wikipedia.org/wiki/Exponential_search --001a113dea6469dcbc05634519de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
    Since you mentioned it, I implemented "= application level" PMTUD in my implementation of QUIC (ht= tps://github.com/private-octopus/picoquic). Basic "probe" str= ategy. Start with the min value (from IPv6), then learn the peer-supported = value during the handshake (standard QUIC), then send probes to perform a b= inary search between min and max. Stop the binary search if the range of se= arch is less than 10 bytes. No ICMP dependency. Some overhead, but that is = amortized by sending a dozen packets or so at the maximum size instead of t= he default size.

    -- Christian Huitema

    How you considered exponential search where you start with a co= nservative limit for the upper bound, then exponentially increase that limi= t until maxPMTU. It is not faster than binary search if each size is equall= y likely, but that is probably not true.
    I assume it would use le= ss bandwidth if the max is much larger than the typical PMTU, and allow the= application to start using larger MTU=E2=80=99s earlier since early guesse= s are more likely to succeed.

    /* roughly like this= - untestet */
    a =3D minPMTU
    b =3D maxPMTU
    k = =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */
    while a <=3D= b
    =C2=A0 k =3D min(a + k, b) - a
    =C2=A0 n = =3D binsearch(a, a + k - 1)=C2=A0
    =C2=A0 if n return n
    = =C2=A0 a =3D a + k /* this doubles the search range */
    end
    <= div>return not found


    --001a113dea6469dcbc05634519de-- From nobody Sun Jan 21 01:50:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B39124239; Sun, 21 Jan 2018 01:50:33 -0800 (PST) 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 oeO3q0_0xlS2; Sun, 21 Jan 2018 01:50:30 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E4C41201F8; Sun, 21 Jan 2018 01:50:30 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id 68so6660602ite.4; Sun, 21 Jan 2018 01:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=Pi6tdFcNLHY5EFyBLVLlc8Rd7S7hOgq7a0fudMuUzjzYG7ytXd+oVVoPOWY/J5NfhF ElJeGM39LQi3/DIhC+O6TC/uWJO155rcADR343IZk+SVCJX9YwBskOx89l0m4qX1Ksfx +cfVtkjFxqyFHmMJk15kNWenEs0p65WBZ0D6o8IxsafE40qqOLT4CUc4DuJSWe9MiAOW wKjRRUQs9W+2e+68BgSOhjqish1+w2IBWtd9SWjX24At87aWGVTLtaYeo5S98jQU9yYf /iHBHQJ15MMYDLRV/7+UK6Yv1gw+K1bg46UNgHVQ44Dr/oEzurHZoaxUTzoP+KXX+cYU 63PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=CLm0fKvh23szIeaCKf8WY+OmJ+IgiRrQdPlo/abD7H0=; b=pFYBvm6wfsvC1AAGWHfqDjqX5l8dsOCN3iO88LlgnV6cjAPG01YVsMhRByM4GukkJj wGeHNj1NFSyyv1pn1r1Yf8iyzDOldIU0xkqfhfdA8GicoJ7q66xAHzuVtrdxBcc9NMTv oJs/AUn47nuiv4d5Ur1QBkDH5ifr9AwbHOyX5h1JD2ZndoGhq5TzGC5HW03IC25Zq4nL HsocV8GL+M+LEmoVdIeecmSYrTH+2/Br+kBdp5rMJG+zsM+7/srCf5MsKCHAry3PDq8+ u0ohnD3Edzj6pZU2ZE/+ocfB46MkROxmonevV32yvL0PhgpcrQIvn3bc4i3hFXdxgqVY ofng== X-Gm-Message-State: AKwxytfX68747GPc/El7kKg+CZqUc5VKqhxUbvLwnKlDpmw6LqtaonR5 vIKVb+E8XqgBkhPcNzRiWdaHCusYthb+/RaNlVM= X-Google-Smtp-Source: AH8x2267rljw79xUqIJ3esxJu7tPe0KiFiAL3cEswXIGTtRf/Q6/an3S0Kh1113wTGN8HC2W/K3PA6xN2G+rZdjCVmc= X-Received: by 10.36.189.129 with SMTP id x123mr2752657ite.31.1516528229648; Sun, 21 Jan 2018 01:50:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 21 Jan 2018 01:50:28 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 21 Jan 2018 01:50:28 -0800 Message-ID: Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 To: Christian Huitema , Michael Tuexen Cc: Gorry Fairhurst , "Black, David" , QUIC WG , "Eggert, Lars" , "tsvwg@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c196d286b8f990563463e38" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 21 Jan 2018 09:50:33 -0000 --94eb2c196d286b8f990563463e38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Here is a Fibonacci variant the grows slower. Not sure it is any better, but the intention is to avoid probing very large packets too early. It could probably be applied recursively to avoid bin search altogether. The same idea might be applicable to reducing the congestion window as opposed to doubling or halving. /* Fibonacci variant */ /* roughly like this - untestet */ unit =3D 10 /* min probe increment */ a =3D minPMTU / unit b =3D maxPMTU / unit k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ k0 =3D 0 while a + k0 <=3D b k2 =3D k0 + k1 n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) if n return n k0 =3D k1 k1 =3D k2 end /* binsearch probes multiples of unit and calls updatePMTUEstimate(n) whenever n is a larger valid probe than previously reported */ Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 January 2018 at 09.28.32, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github.com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), then learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size. -- Christian Huitema How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true. I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s= earlier since early guesses are more likely to succeed. /* roughly like this - untestet */ a =3D minPMTU b =3D maxPMTU k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */ while a <=3D b k =3D min(a + k, b) - a n =3D binsearch(a, a + k - 1) if n return n a =3D a + k /* this doubles the search range */ end return not found https://en.wikipedia.org/wiki/Exponential_search --94eb2c196d286b8f990563463e38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Here is a Fibonacci = variant the grows slower.
    Not sure it is any better, but the intention is to avoid probi= ng very large packets too early.
    It could probably be applied recursively to avoid bin s= earch altogether.
    The same idea might be applicable to reducing the congestion window as= opposed to doubling or halving.

    <= div id=3D"bloop_customfont" style=3D"color:rgb(0,0,0);margin:0px">
    /* Fi= bonacci variant */
    /* roughly like this - untestet */<= /div>
    unit =3D 10 /* min probe increment */
    a =3D minPMTU / = unit
    b =3D maxPMTU / unit
    k1 =3D initDelta /* 1= or larger, e.g. a / 4 */
    k0 =3D 0
    while a + k0= <=3D b
    =C2=A0 k2 =3D k0 + k1
    =C2=A0 n =3D b= insearch(a + k0, min(a + k1 - 1, b), unit)
    =C2=A0 if n return= n
    =C2=A0 k0 =3D k1
    =C2=A0 k1 =3D k2
    end
    /* binsearch probes multiples of unit and calls
    =C2=A0 =C2=A0updatePMTUEstimate(n) whenever n is a larger
    =C2=A0 =C2=A0valid probe than previously reported=C2=A0*/

    Kind Regards,
    Mikkel Fahn=C3=B8e J=C3=B8r= gensen


    On 21 January 2018 a= t 09.28.32, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:


    Since you mentioned it, I implemented "application level" PMTUD in my implementation of QUIC (https://github= .com/private-octopus/picoquic). Basic "probe" strategy. Start with the min value (from IPv6), the= n learn the peer-supported value during the handshake (standard QUIC), then send probes to perform a binary search between min and max. Stop the binary search if the range of search is less than 10 bytes. No ICMP dependency. Some overhead, but that is amortized by sending a dozen packets or so at the maximum size instead of the default size.

    -- Christian Huitema


    How you considered exponential search where you start with a conservative limit for the upper bound, then exponentially increase that limit until maxPMTU. It is not faster than binary search if each size is equally likely, but that is probably not true.
    I assume it would use less bandwidth if the max is much larger than the typical PMTU, and allow the application to start using larger MTU=E2=80=99s earlier since early guesses are more likely to succeed.

    /* roughly like this - untestet */
    a =3D minPMTU
    b =3D maxPMTU
    k =3D initDelta /* 1 or larger, e.g. minPMTU / 4 */
    while a <=3D b
    =C2=A0 k =3D min(a + k, b) - a
    =C2=A0 n =3D binsearch(a, a + k - 1)=C2=A0
    =C2=A0 if n return n
    =C2=A0 a =3D a + k /* this doubles the search range */
    end
    return not found


    --94eb2c196d286b8f990563463e38-- From nobody Sun Jan 21 20:42:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DABF1241F8 for ; Sun, 21 Jan 2018 20:42:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6Y2EC9BjEg0 for ; Sun, 21 Jan 2018 20:42:40 -0800 (PST) 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 EA3BF12704A for ; Sun, 21 Jan 2018 20:42:39 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1edTwK-0006nc-6S for quic@ietf.org; Mon, 22 Jan 2018 05:42:37 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1edTwI-000109-A4 for quic@ietf.org; Sun, 21 Jan 2018 23:42:35 -0500 Received: (qmail 9234 invoked from network); 22 Jan 2018 04:42:32 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jan 2018 04:42:32 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Michael Tuexen References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> Cc: Gorry Fairhurst , "Black, David" , "Eggert, Lars" , "tsvwg@ietf.org" , QUIC WG From: Christian Huitema Message-ID: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> Date: Sun, 21 Jan 2018 18:42:27 -1000 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="------------BF4705958E1D67DBB5B8A056" Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5r3d1FEZaJyy6RdGXSw7HVoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftEU8aM6MfxYCcR8Fh3AbpAB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CoMUI2V1gIW0H5wha94dZjfHJ9u0kPRauioqi6k0R8EPx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5rXFXkQEnTC9rKm30SFEfAxD bFosV7q/YY6M+t085tvsRb/dy1Din9mPcafaVFLA8lz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBnVLUE5wQMuDWRk3qAUSk9R3h1vgDbEdmhrg3iVBpdRa29tyIytZRvp0Gut3t97wmGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 04:42:42 -0000 This is a multi-part message in MIME format. --------------BF4705958E1D67DBB5B8A056 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Here is a Fibonacci variant the grows slower. > Not sure it is any better, but the intention is to avoid probing very > large packets too early. > It could probably be applied recursively to avoid bin search altogether= =2E > The same idea might be applicable to reducing the congestion window as > opposed to doubling or halving. > > /* Fibonacci variant */ > /* roughly like this - untestet */ > unit =3D 10 /* min probe increment */ > a =3D minPMTU / unit > b =3D maxPMTU / unit > k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ > k0 =3D 0 > while a + k0 <=3D b > k2 =3D k0 + k1 > n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) > if n return n > k0 =3D k1 > k1 =3D k2 > end > /* binsearch probes multiples of unit and calls > updatePMTUEstimate(n) whenever n is a larger > valid probe than previously reported */ > Yes, there are multiple ways to go about sending probes. In the QUIC case, the peer sends its own version of MAX MTU during the handshake. So what I did was simply try the peer's MTU, and if that fail do a binary search between that and the initial value. The peer MTU is typically between 1470 and 1500, so the binary search converges very quickly. There are certainly ways to do better, especially if the peer sets its own MTU to some large value, e.g. in a data center environment. For example, one could have a table of probability of finding some particular MTU. And then apply logic based on how much the connection wants to send, what it costs to send a probe, and what is the likely gain if the probe succeeds. You could use that to choose the next probed value. Or to decide to stop probing if no plausible next value can bring a potential gain. Or to send several probes in parallel... -- Christian Huitema =20 --------------BF4705958E1D67DBB5B8A056 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
    Here is a Fibonacci variant the grows slower.
    Not sure it is any better, but the intention is to avoid probing very large packets too early.
    It could probably be applied recursively to avoid bin search altogether.
    The same idea might be applicable to reducing the congestion window as opposed to doubling or halving.

    /* Fibonacci variant */
    /* roughly like this - untestet */
    unit = 10 /* min probe increment */
    a = minPMTU / unit
    b = maxPMTU / unit
    k1 = initDelta /* 1 or larger, e.g. a / 4 */
    k0 = 0
    while a + k0 <= b
      k2 = k0 + k1
      n = binsearch(a + k0, min(a + k1 - 1, b), unit)
      if n return n
      k0 = k1
      k1 = k2
    end
    /* binsearch probes multiples of unit and calls
       updatePMTUEstimate(n) whenever n is a larger
       valid probe than previously reported */

    Yes, there are multiple ways to go about sending probes. In the QUIC case, the peer sends its own version of MAX MTU during the handshake. So what I did was simply try the peer's MTU, and if that fail do a binary search between that and the initial value. The peer MTU is typically between 1470 and 1500, so the binary search converges very quickly.

    There are certainly ways to do better, especially if the peer sets its own MTU to some large value, e.g. in a data center environment. For example, one could have a table of probability of finding some particular MTU. And then apply logic based on how much the connection wants to send, what it costs to send a probe, and what is the likely gain if the probe succeeds. You could use that to choose the next probed value. Or to decide to stop probing if no plausible next value can bring a potential gain. Or to send several probes in parallel...

    -- Christian Huitema

     

    --------------BF4705958E1D67DBB5B8A056-- From nobody Mon Jan 22 19:50:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D871312D95F for ; Mon, 22 Jan 2018 19:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DwYBv3WQBypp for ; Mon, 22 Jan 2018 19:49:59 -0800 (PST) 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 CECDB12D959 for ; Mon, 22 Jan 2018 19:49:54 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0N3lBs2004614; Tue, 23 Jan 2018 03:49:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=Ql+zyyIJXtd2OAyJjvxe6sDbV61j4FeyD+gNN20+ioA=; b=SKzrmvAeWGWWX3HF7n89IPAZUb7Kq67Wyi3vigQm1zaxth+NgkbHqNGThr5Dy+2H+8HU xzpuv7HbWE5YemHpGudxCRj/HP/+JhKDL5UxBZjfdsppoVYK2pJ+FiaZzlP7aBJz0ofz HF/WZ9rQiqM2uYUjbZyplRos21cpQZVwkn9UB101cTKYIBSjjMVbotG31il6kT8gwjX8 mR9wGS7yW5EPUlpenqiS6arrlNYi0uaffAPwSs0fQC5Hwj0SJDQmnMsptBGK6DFgctXh TbpgQfUhoX6/G1/NyDTrx2bKufIfEay5MgwgPzf4Xe1wyZkoJ+ZO1L4HF4HPxxiOW+Uf +A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2fkwwrsjev-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 03:49:47 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0N3jbu2028967; Mon, 22 Jan 2018 22:49:45 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fm1yyg7dv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 22 Jan 2018 22:49:45 -0500 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; Mon, 22 Jan 2018 22:49:44 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Mon, 22 Jan 2018 22:49:44 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMA== Date: Tue, 23 Jan 2018 03:49:43 +0000 Message-ID: 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.41] Content-Type: multipart/alternative; boundary="_000_f15e0c6088444db6a15c811cdfcabfb5usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230049 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230049 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 03:50:01 -0000 --_000_f15e0c6088444db6a15c811cdfcabfb5usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The problem with deadlocking QUIC streams is the possibility that the sende= r (or proxy) will "use up" connection flow control credits on lower-priorit= y streams, blocking the receiver from making forward progress with any stre= ams. The receiver has no mechanism to direct/force the sender to send on p= referred streams. I would like to propose a concept of "stream data credit" - the concept of = extra flow control credits that can only be used by a specific stream. A S= TREAM_DATA_CREDIT frame would update such credits (see below). Data sent o= n a stream will consume its own credits as much as it can and connection cr= edits (updated by MAX_DATA) for the rest of the data. The updated connection flow control accounting: " For each stream, "used connection credits" is "MAX(the_largest_received_off= set - stream_data_credits, 0)". The sum of "used connection credits" on all streams - including streams in terminal states, but excluding stream 0 - MUST NOT exc= eed the value advertised by a receiver (i.e. MAX_DATA). An endpoint MUST termi= nate a connection with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it used more conne= ction credits than the maximum data value that it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). " The receiver will be able to grant dedicated credits to the high-priority s= tream w/o requiring the sender or the intermediary to know anything about t= he semantics of the protocol and without worrying that the sender/intermedi= ary will "squander" the credits on unimportant streams. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D STREAM_DATA_CREDIT frame. The frame updates Data Credit for a stream. ~~~ 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 (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Credit (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the STREAM_DATA_CREDIT frame are as follows: Stream ID: : The stream ID of the stream that is affected encoded as a variable-length integer. Data Credit: : A variable-length integer indicating the new total data credit for the st= ream. For each stream Data Credit starts with 0. The sender can only increase Da= ta Credit in subsequent STREAM_DATA_CREDIT frames for the same stream, but = loss and reordering can cause STREAM_DATA_CREDIT frames to be received out = of order. STREAM_DATA_CREDIT frames that do not advance Data Credit for th= e stream MUST be ignored. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comments? * Igor --_000_f15e0c6088444db6a15c811cdfcabfb5usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    The problem with deadlocking QUIC streams is the pos= sibility that the sender (or proxy) will “use up” connection fl= ow control credits on lower-priority streams, blocking the receiver from ma= king forward progress with any streams.  The receiver has no mechanism to direct/force the sender to send on preferred streams.<= o:p>

     

    I would like to propose a concept of “stream d= ata credit” – the concept of extra flow control credits that ca= n only be used by a specific stream.  A STREAM_DATA_CREDIT frame would= update such credits (see below).  Data sent on a stream will consume its own credits as much as it can and connection credits (upd= ated by MAX_DATA) for the rest of the data.

     

    The updated connection flow control accounting: = ;

     

    “

    For each stream, “used connection credits̶= 1; is “MAX(the_largest_received_offset - stream_data_credits, 0)̶= 1;.

     

    The sum of “used connection credits” on = all streams -

    including streams in terminal states, but excluding = stream 0 - MUST NOT exceed

    the value advertised by a receiver (i.e. MAX_DATA).&= nbsp; An endpoint MUST terminate a connection

    with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA erro= r if it used more connection credits

    than the maximum data value that it has sent, unless= this is a result of a

    change in the initial limits (see {{zerortt-paramete= rs}}).

    “

     

    The receiver will be able to grant dedicated credits= to the high-priority stream w/o requiring the sender or the intermediary t= o know anything about the semantics of the protocol and without worrying th= at the sender/intermediary will “squander” the credits on unimportant streams.

     

     

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

     

    STREAM_DATA_CREDIT frame.

     

    The frame updates Data Credit for a stream.

     

    ~~~

    0        &nb= sp;          1  &nbs= p;            &= nbsp;   2         &n= bsp;         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

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    |        &nb= sp;            =    Stream ID (i)        &= nbsp;           &nbs= p;   ...

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    |        &nb= sp;            =    Data Credit (i)        = ;            &n= bsp;   ...

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    ~~~

     

    The fields in the STREAM_DATA_CREDIT frame are as fo= llows:

     

    Stream ID:

     

    : The stream ID of the stream that is affected encod= ed as a variable-length

      integer.

     

    Data Credit:

     

    : A variable-length integer indicating the new total= data credit for the stream.

     

    For each stream Data Credit starts with 0.  The= sender can only increase Data Credit in subsequent STREAM_DATA_CREDIT fram= es for the same stream, but loss and reordering can cause STREAM_DATA_CREDI= T frames to be received out of order.  STREAM_DATA_CREDIT frames that do not advance Data Credit for the stream M= UST be ignored.

     

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

     

     

    Comments?

     

    • Igor

    --_000_f15e0c6088444db6a15c811cdfcabfb5usma1exdag1mb5msgcorpak_-- From nobody Mon Jan 22 20:32:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB581127201 for ; Mon, 22 Jan 2018 20:32:53 -0800 (PST) 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 bsqSszdbG00J for ; Mon, 22 Jan 2018 20:32:52 -0800 (PST) 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 1825A1200F1 for ; Mon, 22 Jan 2018 20:32:52 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id 65so4414432ybz.6 for ; Mon, 22 Jan 2018 20:32:52 -0800 (PST) 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=VQsyrnUNGELqPjItiQtY7nFkn9OhBMJ4gV4Z3ubPHvE=; b=LWBb2x7vvESlus3kQJtId1Tnh5de6Q4VYo0HQRynHeYC0Z81Ywl1bfsfff0stK+ICG XUMPlSJF8hFpN9tYXgpESvuYLqfXa0K28iLyroOoa3AxzNy2ISlfgQPjhvMWVc5f4uVr 0YpxnDDUEfchXtah79niQ6gur6Ux1w0y8/v5QKydvlHIlQo5jyWuXgNqpkGF0wLlSv9l p9+e+KBPxzBdaHn+rWeMzGfq6GnZB58yIkj/HsKdWU/SHpa6uq8Vn5trtXvoQbULSNdB m9n+SP7DP+2dIlz+bj6Mg4COSGIywdbwPsONf/ox2GVNy4nlkRG3PiQFrP22uLzwH0NH uGNQ== 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=VQsyrnUNGELqPjItiQtY7nFkn9OhBMJ4gV4Z3ubPHvE=; b=dRjZwd+uWCKRJcYOb08jj9GE01nMcTyZLnw2Mq9/vUHfLfH+yEfGCxn0hqoNQOjSz4 K2rlYSqK2oV5m09GaP8YbUeizfT0Iol+5J9R/vM8MvjkrTM7tbxvl9pYo7djDqhEQw4s I28yufJa3NyCjul255C/KlIyYspn2NYOlMiHSwTbiRVJKfrYaB/Gt8l8vZ6mnxCqaQNG YsavDvq7tmK4oYsgdZQDI8jrDBKXopsMKzC9uLnJCcoU2wwBRqcpFOECFJ0ODpHUz9Yg Fn2Wr+sjxhKC0Sz2+JV7cSmdDurXB6Q9Pvx672Ettm6mV6nFQpbbnAtZrtz73zPFjAuZ 2OHw== X-Gm-Message-State: AKwxytfXsCV0EP86QFWS5RCa4Ih/u3yHyDyzj4kG/8nNJ7fBub7yvFFT VHsCMR0kdzsZKQiV7H3fAFLYhROeEZR2qC5h2WQ= X-Google-Smtp-Source: AH8x2253ZLKTmGtdj9iVbTmAMc6dMXNyZYCWMy05h8o4Y7orjo2mByKbKY0x9UOCbKVo25jcpiE9N5RbLOXCGbk271Q= X-Received: by 10.13.194.70 with SMTP id e67mr1200352ywd.448.1516681970873; Mon, 22 Jan 2018 20:32:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Mon, 22 Jan 2018 20:32:50 -0800 (PST) Received: by 10.37.20.4 with HTTP; Mon, 22 Jan 2018 20:32:50 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Mon, 22 Jan 2018 22:32:50 -0600 Message-ID: Subject: So how critical is header compression? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114f50061c7c1205636a0aad" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 04:32:54 -0000 --001a114f50061c7c1205636a0aad Content-Type: text/plain; charset="UTF-8" If I understood correctly (and this is my most accessible remote meeting ever, so I have hopes), there was a tension in today's meeting between not wanting to make a premature choice on header compression, and not wanting to have header compression make meeting the current milestone dates in QUICv1 harder than that needs to be. Was that about right? Spencer --001a114f50061c7c1205636a0aad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    If I understood correctly (and this is my most accessible= remote meeting ever, so I have hopes), there was a tension in today's = meeting between not wanting to make a premature choice on header compressio= n,=C2=A0 and not wanting to have header compression make meeting the curren= t milestone dates in QUICv1 harder than that needs to be.
    =
    Was that about right?
    Spencer
    --001a114f50061c7c1205636a0aad-- From nobody Mon Jan 22 21:43:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1088C12DA09 for ; Mon, 22 Jan 2018 21:43:48 -0800 (PST) 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 of0KQdoSQJzb for ; Mon, 22 Jan 2018 21:43:46 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 5C8A312DA08 for ; Mon, 22 Jan 2018 21:43:46 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id a24so9689815otd.4 for ; Mon, 22 Jan 2018 21:43:46 -0800 (PST) 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=OxDBrNV4ncGAaZkzchka5hgKwfUInDjAX4PYRe9E0EY=; b=EqqXgXY92NrcF8ogM4+YOIZy3d8MuuCZB+boqGkUpz0a7Vdp0YejPDzvRR7bfZLfu7 mwebAafJMZ3Du0qTv9TET6D6xIXUSclN7ue+U0zD/cRFhU+ZlkHfaRJtSmr9Jq6FdavV g7r6JsiIcC/5O869dNslc7svhoVIIaGA9e/n/fxh8sXj/Mn7SeXpyKeOtDkeUnToXr6x 5H6A3MH5Gor2j7KO1+B+aRwUx/CXto4vNnjvqWVxj8dVNzMiLNMb4cia33zsUgNpm/uS /nOkfg7nQxJjTUJzYYdAsS4LROu3OktfUzXYevkq0yxV5xFyJKCp58rcfFuNMnk0iB62 fi4Q== 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=OxDBrNV4ncGAaZkzchka5hgKwfUInDjAX4PYRe9E0EY=; b=twgYCcl9B2ylEi93IgV/PztOy82HyXtbawHd9v9dBoUaJjRyYp6vb4d8g7gJQs0u1p 3S8ksQE32e0hj0LvMJ0GlKpB4KzhCrlK6rTNHzAwpI5X8h+bZqDbDPzwUC11RRpTbYml qqDAOFROD09LM8uhK3HlkYYihhQjCo1rXYTYtFEx9T9+ti74iz0BygFafih6PfLPCz4Z EN92O8YzpFW9VJL7Ka+A6qLEYs9axMeLU3cjl5N1ckdlJkC/REN8yZ8Kmp3bqPtDyYlK A8XCElVtquuzWmP759ayuxm0TcvE36otkAXGQYda9IYpv0ayURKfddQRzzcYTpkV3Jwr VSkQ== X-Gm-Message-State: AKwxytd89yHacxddUXr99djdIaqLX9LjvbFpRs/Q8jDFjU+5kZowHa8v Bhgj8IV5cyvKLPUBzXzNmDuxVqoEpDp4TLvw+wM= X-Google-Smtp-Source: AH8x224Js71YI2Ssga9dlaH9FaQT16n7eiFyK9w9/sBdHC+AER3vSxBEAQ46rAAaYkXXgZ9/dz4soIOH8n2865a0Nn0= X-Received: by 10.157.72.138 with SMTP id d10mr6415484otf.93.1516686225450; Mon, 22 Jan 2018 21:43:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Mon, 22 Jan 2018 21:43:44 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 23 Jan 2018 16:43:44 +1100 Message-ID: Subject: Re: So how critical is header compression? To: Spencer Dawkins at IETF 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: Tue, 23 Jan 2018 05:43:48 -0000 Buck tells me that header compression is critical: they can't deploy QUIC without it and that 30% (what we get now) is still completely unacceptable. This is probably a moot point given the decision today. I think that we have a plan. On Tue, Jan 23, 2018 at 3:32 PM, Spencer Dawkins at IETF wrote: > If I understood correctly (and this is my most accessible remote meeting > ever, so I have hopes), there was a tension in today's meeting between not > wanting to make a premature choice on header compression, and not wanting > to have header compression make meeting the current milestone dates in > QUICv1 harder than that needs to be. > > Was that about right? > > Spencer From nobody Mon Jan 22 22:31:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1BD12D963 for ; Mon, 22 Jan 2018 22:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dQgqnoZnBRa for ; Mon, 22 Jan 2018 22:31:06 -0800 (PST) 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 11FFA12D960 for ; Mon, 22 Jan 2018 22:31:06 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id f4so27184419qtj.6 for ; Mon, 22 Jan 2018 22:31:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=408ngYONOyGKJQ2EKajU0l1/rcaEX9Esp/OjkdtRjPA=; b=0xEw/4IKqU0SEBd61jGog1Sgz2o4zRikQ1fozORkLUxW1eXlltvE+ryFGQUGSPu7Xo MjhoLTZJxamDjSUzIb6WX9dqnyTQRV3f7CcovU4uOEQ7iduS7R7Zza+K+JYTNXoSJhzr CUOxTzvyhyM725YJNzcCG8VCCj+NhdnQkgG+ys5da/p/pTto6VKAmqL+/Buwv9IPC6/A yTWdGnlEbJ5OsNBv+31P6mtfXfWpC25gJglfH2GpH59RkeNsqIcSDrbnFd1E+Q6G/DN9 HA54c7rsTohNJ6mmLPQ1C29pVRMZjUXqMTeENuXBtJ6NfYAaCA8J+SYo6smCMvFBruS5 48QA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=408ngYONOyGKJQ2EKajU0l1/rcaEX9Esp/OjkdtRjPA=; b=KHeAMheFVQD7NH/vflIVLGyn7HzO0lHPdJBddKMVNOqTDeEBXo8zLN8BXx+/nmQuOi wElcRikJilygBhR/uniB5Un6aW+u0+3P86AglBSDurdmz9oVkUUNmJuJWcgwNyVcaVl9 F/xTzQGjqNHY09XCStAtZxrAseHmtwp9V66s/gEP+dWgV8xvrekWZ4DNz/z6uJ1ag0eF QJEbKPq51cOtWkDBWUa9jT5N6x50UvQgeNxtPz5hdMP0LqXdxWeT9y7P6/ZM3lP1Nqs9 bv0NwaafQFOR6AoR+wTyXHaIgzKPoj0tl/M1Dvlokr/rK4wvvI8HeONIHygj5b7eD18/ i65Q== X-Gm-Message-State: AKwxytdL+I9Fe3WFf7B7zyHkI+8ogX9ekibKScqRlEgBclB/Q9OKedex Rb9f5wNQZrlLk+hFAJZP3kECMw== X-Google-Smtp-Source: AH8x226B2765MLuy7Of5iIs8NY50P/UOENF/GdYY1mRAhXefF70l/RGab3dpEqERRh6svs2DaD41zw== X-Received: by 10.200.55.227 with SMTP id e32mr2145926qtc.158.1516689065180; Mon, 22 Jan 2018 22:31:05 -0800 (PST) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id s7sm2511563qkd.67.2018.01.22.22.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jan 2018 22:31:05 -0800 (PST) Date: Tue, 23 Jan 2018 01:30:59 -0500 From: Dmitri Tikhonov To: Martin Thomson Cc: Spencer Dawkins at IETF , IETF QUIC WG Subject: Re: So how critical is header compression? Message-ID: <20180123063052.GA25014@ubuntu-dmitri> Mail-Followup-To: Martin Thomson , Spencer Dawkins at IETF , IETF QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 06:31:08 -0000 On Tue, Jan 23, 2018 at 04:43:44PM +1100, Martin Thomson wrote: > This is probably a moot point given the decision today. I think that > we have a plan. The Working Group decided only two of the three questions that were to be posed, as the last slide never quite made it onto the main screen. The questions were: 1. Allow or disallow blocking? 2. Configurable (or negotiable) blocking or not blocking? 3. Delayed reading from transport OK? In regards to 1 and 2 the Working Group responded with "allow" and "yes: make this into a knob." The answer to the last question, however, has important implications. I think we should revisit this issue: that is, the Working Group should decide explicitly whether not reading from stream is appropriate. Now is the time to think about corner cases. - Dmitri. From nobody Tue Jan 23 00:06:19 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8C3912D95C for ; Tue, 23 Jan 2018 00:06:12 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 jrAjBF5bXLqi for ; Tue, 23 Jan 2018 00:06:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 A32D912D956 for ; Tue, 23 Jan 2018 00:06:09 -0800 (PST) Received: from [192.168.178.20] ([93.217.126.170]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M6ilI-1eybH82ANg-00wSuc; Tue, 23 Jan 2018 09:06:06 +0100 Subject: Re: So how critical is header compression? To: Martin Thomson , Spencer Dawkins at IETF , IETF QUIC WG References: <20180123063052.GA25014@ubuntu-dmitri> From: Julian Reschke Message-ID: <9586bc06-dd5c-1a93-e91b-64fd3126ceff@gmx.de> Date: Tue, 23 Jan 2018 09:06:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180123063052.GA25014@ubuntu-dmitri> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:rQI77ENYpAenWkoNnuRiYGAELoFjXQJ78hWOvaSZNzsPYpRmSRL x831YfEJNaCWUCUB8PMRloQPlq9Tqjkbq8DJ0eLDb5smxCIoIgRWORRZ/9BzEUvV+5+2UD7 oWmYWi0rkHLmXg1XxCwfCbZD+S1rl1N9Xnk+uVvM0guTSLHx0IY2anCVMtfZAXbRfTdIBCg tjknNyv1SlFFLS70NqQBg== X-UI-Out-Filterresults: notjunk:1;V01:K0:NfH4NRc4FP4=:lhiGt3g3M3PxRKsXbac3/C GTvm/avEOQxyIQfINyHytthGJSpk9m7WF04sd2V6AckYrz7alMrMWY/aU+h21Le6MgHTEmPZC w8er53OgvjkLXDIlasBOsn2jtBO4I7Wvv0nQjqM0N+BjYlaTMA1MkzYuCCaO1z/pYHh/ygyq5 lpORUSekfnm4TFIQOxWlBMvtTPMQTMp243g5o+UUMPMFKFg19v61IiS2Wc0x7KyBisP/16cDx UW6i8rsRUw/2vsEFo8zUrn9NPiKLaCHepohk3lbymdhffFry2TuWpG1ROZVGL6LX+qwwjQMcs cQyZnhA54q4jVoTlb2qSZmBUYpRUsSCqtYWFvkByThYVTlDemnvxaXxeAtOhwP2k3rkvVXyeP MjvWQcyV3kfiduLaNgLNpfjp6yQ+Rju432sszLzw8sUpXOw0TFXy6X1/J+GucxL8EnNrVoMqT 58SCv2VwvjH+egQ4kzM4R+d3LDswFyusoI6kxOeZIgJPAoaYu11XgveQV7OBCL29RIX0OWkNC Ac08efbZgsmtMiHEt2GHy+wzU53buPMc5VHprtgMXwnK2OCYwknKpzhwFntXQMPhM6BPjCRSH fdOu1IeQ4114O1kD4JjX0p8DxEUOkJ2qN3WKSeIj+hMzipRFYt0IvDLTFvlJK7gKGQ3GcejkI rPslzgL/LC5JjVF2PXCEVaw3ShXnNtxH4QswGahZpctJjDgnXzs8Ex20F7ogP0rwdCS6/r/n9 zldZCMnH/A/kjO4alf84K3zauiMp1i+oIL3RmxNwIHVx16Z1nsAGlDWKBqQti0eEm7fSfnR6s XxKB33/iWrzW7MCguFN906HfWAc0NacDD9A6vt72/bQGdDWUaQ= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 08:06:17 -0000 On 2018-01-23 07:30, Dmitri Tikhonov wrote: > On Tue, Jan 23, 2018 at 04:43:44PM +1100, Martin Thomson wrote: >> This is probably a moot point given the decision today. I think that >> we have a plan. > > The Working Group decided only two of the three questions that were > to be posed, as the last slide never quite made it onto the main > screen. The questions were: > ... FWIW (and just to clarify): anything discussed at a meeting (be it IETF or interim) will need to be confirmed on the mailing list... Best regards, Julian From nobody Tue Jan 23 03:15:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927DA1200C1 for ; Tue, 23 Jan 2018 03:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=evequefou.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 L4K7SidmUM5T for ; Tue, 23 Jan 2018 03:15:06 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0090.outbound.protection.outlook.com [104.47.32.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FA31200F1 for ; Tue, 23 Jan 2018 03:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ukzNCR/wBOUnw8x2HHB47hZJlCQOfE8Kx5s3Cwof+j8=; b=JvoUE2KX7r6/0D3m2iwax/09QCrqWBrLZvwkAkZHgduHjxyGNuC6ohMmPl4JAD6llr2nWVqSeSCLruZgKcWj/Gh/QGFix1ZsC+tY+bpiLUGx4fMHb2xIGjfVcHI3j8KJGunbkJvhQZFLAuYxMcNe+6akgDao0hRsyrI/6nHqjGA= Received: from CY4PR08MB2423.namprd08.prod.outlook.com (10.168.169.142) by CY4PR08MB2758.namprd08.prod.outlook.com (10.173.59.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Tue, 23 Jan 2018 11:14:51 +0000 Received: from CY4PR08MB2423.namprd08.prod.outlook.com ([fe80::45a3:8d61:7a81:3ef2]) by CY4PR08MB2423.namprd08.prod.outlook.com ([fe80::45a3:8d61:7a81:3ef2%18]) with mapi id 15.20.0428.019; Tue, 23 Jan 2018 11:14:51 +0000 From: Mike Bishop To: Dmitri Tikhonov , Martin Thomson CC: IETF QUIC WG , Spencer Dawkins at IETF Subject: RE: So how critical is header compression? Thread-Topic: So how critical is header compression? Thread-Index: AQHTlANANMX5dmynhU+d/aNds3hfO6OA8jwAgAANM4CAAE7p8A== Date: Tue, 23 Jan 2018 11:14:50 +0000 Message-ID: References: <20180123063052.GA25014@ubuntu-dmitri> In-Reply-To: <20180123063052.GA25014@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [59.100.149.226] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR08MB2758; 7:9ICrHqQBB3LGvB0aH8Ki8s4v/EUHxxRSgoQPxqZtDSWZHxLrSRYNiKpUz9R0xZpfJpdgVSOPFPgUCTfGd/iNx94i2NK7AArrLkrV1YqlWaHfNEdwT1WGnB3eQMpEeARxGoPyS8EK/0ShPKgXZ7YVyXYdvv+gPqYiUcrbW6Wrmr7NWQJ5TUNDAOpnk2xHEZSzC+m02HyhcCGJ+X2mHrXtgtzWJR5Cz8DDivpf/0p8jZMOlol5DfR+7xPoKFT9CGxV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2586aa24-0eee-4db5-7833-08d5625285de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(7094020)(4603075)(4627221)(201702281549075)(7048125)(7027125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR08MB2758; x-ms-traffictypediagnostic: CY4PR08MB2758: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(2400081)(944501161)(93006095)(93001095)(10201501046)(3002001)(6041288)(20161123560045)(20161123558120)(20161123562045)(2016111802025)(20161123564045)(6072148)(6043046)(201708071742011); SRVR:CY4PR08MB2758; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:CY4PR08MB2758; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(51444003)(199004)(13464003)(189003)(102836004)(81156014)(6506007)(8676002)(81166006)(93886005)(6436002)(5660300001)(229853002)(2950100002)(55016002)(9686003)(76176011)(59450400001)(53936002)(8936002)(53546011)(7696005)(2906002)(25786009)(86362001)(68736007)(4326008)(26005)(6246003)(3846002)(99286004)(508600001)(54906003)(14454004)(6116002)(97736004)(305945005)(74316002)(110136005)(39060400002)(3660700001)(7736002)(105586002)(3280700002)(106356001)(5250100002)(74482002)(33656002)(66066001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR08MB2758; H:CY4PR08MB2423.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: V8B4MerDn6iyVCmdvrUlQbSTADoKJgFeOFZ29usIFVgceRN74EiC1+nZRxenMcvVsBvhFqksCAEz9g8yRXka4A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 2586aa24-0eee-4db5-7833-08d5625285de X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 11:14:50.9176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR08MB2758 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 11:15:11 -0000 I thought the last one was pretty clearly answered as well: The transport = doesn't trust that the application will read. If HTTP fails to read in cer= tain cases, that's exactly what flow control is for. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov Sent: Tuesday, January 23, 2018 5:31 PM To: Martin Thomson Cc: IETF QUIC WG ; Spencer Dawkins at IETF Subject: Re: So how critical is header compression? On Tue, Jan 23, 2018 at 04:43:44PM +1100, Martin Thomson wrote: > This is probably a moot point given the decision today. I think that=20 > we have a plan. The Working Group decided only two of the three questions that were to be p= osed, as the last slide never quite made it onto the main screen. The ques= tions were: 1. Allow or disallow blocking? 2. Configurable (or negotiable) blocking or not blocking? 3. Delayed reading from transport OK? In regards to 1 and 2 the Working Group responded with "allow" and "yes: make this into a knob." The answer to the last question, however, has important implications. I think we should revisit this issue: that is, the Working Group should dec= ide explicitly whether not reading from stream is appropriate. Now is the = time to think about corner cases. - Dmitri. From nobody Tue Jan 23 07:04:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 584DE126C2F for ; Tue, 23 Jan 2018 07:04:24 -0800 (PST) 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 0jY-a0WOM4Ai for ; Tue, 23 Jan 2018 07:04:22 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D73126C23 for ; Tue, 23 Jan 2018 07:04:22 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B6D5F340E35 for ; Tue, 23 Jan 2018 16:04:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.27869); Tue, 23 Jan 2018 16:04:19 +0100 (CET) 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 ; Tue, 23 Jan 2018 16:04:19 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43033085 for quic@ietf.org; Tue, 23 Jan 2018 16:04:19 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_7A5481AE-EA37-47B9-B634-36EAC81A08CE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: what was yesterday's packet number decision? Message-Id: Date: Tue, 23 Jan 2018 16:04:18 +0100 To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 15:04:24 -0000 --Apple-Mail=_7A5481AE-EA37-47B9-B634-36EAC81A08CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, I've reviewed the notes of the discussion on yesterday's greasing = discussion at the interim, and while there's not *quite* enough context = there for me to figure out what was decided, I think this is the = proposal: (1) Packet numbers in both long and short headers should no longer have = the property that they monotonically increase (a) on the theory that an intermediary that is attempting to lazily = classify QUIC will may classify future discontinuity in this packet = number space as not-QUIC; and (b) because packet number monotonicity increases flow linkability over = migration events that the sender does not know about, and we would like = to avoid these. Is this the scope of the new PR Martin has volunteered to send? Thanks, cheers, Brian --Apple-Mail=_7A5481AE-EA37-47B9-B634-36EAC81A08CE 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpnTvIACgkQihK3vwvq RqM2Pw/9FWZZWW1we1f8fYUVjPy6rhjSRICH83Otp05lfLl/CQJD29svgFQAFMXl 3twrzoYskGlM9pAKgXPzso1jxnggldyo1xY/lNSd17QMPULPnQtdmUZlP4Rk+MCF /8nv3Qn+SoFPXahjT2VZoxpVhtV8nNIxWEjGahG86fh5hq5I0jTs4ZyJL9NoFH0m hQVyYSkYXdukh/q9eqzZPG2YzOFnlfCKttvpuFln/qx3z+KNEvlTbWIhDhFAC4qS 6G9dcNgScBkFU/oEPlqZZwJU44yoCKxDyh7Xfa6D2ag/Cy0CHiuFU6rHpCmqca99 z7gDrSbQtZ0G/2VN+JNBl4IQngM50ENzDUIekO5pGmRHSjFEgCPI4aKIwzT4od4m NBP5mGqoAJMQBZIlT7unbp496CQUNGj1k8SsFfZG7OBfY7dzKBjof8CACkeoP5S+ +WNLEyiMV4DRhwZIPpnQgkx2AjXUrVr50vgiyclJFK3O6IYj9pJPEeZRpOZZSIxx hN6t1S0c+qfb5mW4izd7BlNHRKlaqQAWFqKH7q2uZGu+uc1TTsbKnrtWdiLt9T67 /9Xp+/zjAcMPy73oX9dLXfM+iJqk2aKcOoofF7twGr3WifImsG1tpDC/tKev0HT3 keQbEQQYBUf7AMvwEVy7LApv3Bxz4pSrxQsf7N+SCdZy6D+uMkM= =eQrl -----END PGP SIGNATURE----- --Apple-Mail=_7A5481AE-EA37-47B9-B634-36EAC81A08CE-- From nobody Tue Jan 23 07:18:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAEB126CF6 for ; Tue, 23 Jan 2018 07:18:35 -0800 (PST) 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=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 NtGLgterlY_l for ; Tue, 23 Jan 2018 07:18:33 -0800 (PST) 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 AF6291205D3 for ; Tue, 23 Jan 2018 07:18:33 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NFIUm8005551; Tue, 23 Jan 2018 15:18:30 GMT 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 : content-transfer-encoding : mime-version; s=jan2016.eng; bh=1NzLx5XL3W3A2WYaGaDVF2lIZB2iZEZF6kR2m72E/uM=; b=J8vDFdBbKrCjd01neRXl9/bU7IQ6LVZ5EPQFvVRAdRJ0TZSoIud1SX9DM6McND1CHVwo JFxPx5OwjYth5vRhuWgSZ7QSxgUOc2X0IpFxQdT2XUt5sxu9C0N1c0bwVHcxzHT/7ngj PbxfMFO1b5+ng+4qfxV1cekCnlPTdp1dbivvrwa9UCfU04MWqCDfRpqCEqsa6yFjTmVI gQqRhVW0ubiy00ha+ijcVQctGUrWTLqiJcB6Rh1XfVWeDIR5vI620in0eeOcfSsRg1af lO2uZHtnX1nJKjmFU1fTwqeg43cMDiaK81gFhU5mS8eELMaNbKi5VNqzhvm/I3b7ZuyG HA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2fkxa1rgy0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 15:18:30 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0NFGEw7008807; Tue, 23 Jan 2018 10:18:29 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ehx3k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 10:18:29 -0500 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; Tue, 23 Jan 2018 10:18:28 -0500 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; Tue, 23 Jan 2018 10:18:28 -0500 From: "Lubashev, Igor" To: "Brian Trammell (IETF)" , QUIC WG Subject: RE: what was yesterday's packet number decision? Thread-Topic: what was yesterday's packet number decision? Thread-Index: AQHTlFt5lJbAUhYRJEKQNaIzogOgZ6OBj6oA Date: Tue, 23 Jan 2018 15:18:27 +0000 Message-ID: <2c53f35a0cc440cb98bfe1a99cd4ee72@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.33.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230210 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 15:18:35 -0000 > (b) because packet number monotonicity increases flow linkability over mi= gration events that the sender does not know about, and we would like to av= oid these. Would not the Connection ID give it away in these cases anyway? Cases when= the sender does know about migration events may fare better, if the sender= has received NEW_CONNECTION_ID in advance of the migration event. - Igor -----Original Message----- From: Brian Trammell (IETF) [mailto:ietf@trammell.ch]=20 Sent: Tuesday, January 23, 2018 10:04 AM To: QUIC WG Subject: what was yesterday's packet number decision? Greetings, all, I've reviewed the notes of the discussion on yesterday's greasing discussio= n at the interim, and while there's not *quite* enough context there for me= to figure out what was decided, I think this is the proposal: (1) Packet numbers in both long and short headers should no longer have the= property that they monotonically increase (a) on the theory that an intermediary that is attempting to lazily classif= y QUIC will may classify future discontinuity in this packet number space a= s not-QUIC; and (b) because packet number monotonicity increases flow linkability over migr= ation events that the sender does not know about, and we would like to avoi= d these. Is this the scope of the new PR Martin has volunteered to send? Thanks, cheers, Brian From nobody Tue Jan 23 08:12:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDD712706D for ; Tue, 23 Jan 2018 08:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrYSW2qGo0cx for ; Tue, 23 Jan 2018 08:12:40 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1246124235 for ; Tue, 23 Jan 2018 08:12:39 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BD7A7340F25; Tue, 23 Jan 2018 17:12:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.11996); Tue, 23 Jan 2018 17:12:35 +0100 (CET) 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; Tue, 23 Jan 2018 17:12:35 +0100 (CET) Received: from [195.176.110.236] (account ietf@trammell.ch HELO public-docking-etx-1921.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43045079; Tue, 23 Jan 2018 17:12:35 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_84FF6327-1B5B-4D21-B1BD-8184553125A5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: what was yesterday's packet number decision? Date: Tue, 23 Jan 2018 17:12:34 +0100 In-Reply-To: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: QUIC WG To: "Lubashev, Igor" References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> 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, 23 Jan 2018 16:12:42 -0000 --Apple-Mail=_84FF6327-1B5B-4D21-B1BD-8184553125A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 Jan 2018, at 16:18, Lubashev, Igor wrote: >=20 >> (b) because packet number monotonicity increases flow linkability = over migration events that the sender does not know about, and we would = like to avoid these. >=20 > Would not the Connection ID give it away in these cases anyway? Cases = when the sender does know about migration events may fare better, if the = sender has received NEW_CONNECTION_ID in advance of the migration event. Yeah, that's part of why I'm confused by the notes. I think the underlying requirement here is to give an endpoint (defined = either as "the sender of a direction of a QUIC flow" or more explicitly = as "the client") some measure of control over how linkable its packets = are. Not using CID at all, and obfuscating the packet sequence, = increases the complexity of flow linkage during involuntary migration. (I say "increases the complexity" as opposed to "reduces linkability" = because, as a measurement geek, I'm deeply pessimistic about the ability = to eliminate linkability of packets sent by the same sender. After you = have added a runtime requirement to keep some amount of per-flow state = in order to link packets to a flow, any additional complexity in packet = number obfuscation only serves to increase the amount of work to design = an algorithm for linking packets, i.e., it increases the number of = masters' and/or doctoral degrees awarded to people who work on solving = the problem of linking QUIC flows.) Cheers, Brian > - Igor >=20 > -----Original Message----- > From: Brian Trammell (IETF) [mailto:ietf@trammell.ch] > Sent: Tuesday, January 23, 2018 10:04 AM > To: QUIC WG > Subject: what was yesterday's packet number decision? >=20 > Greetings, all, >=20 > I've reviewed the notes of the discussion on yesterday's greasing = discussion at the interim, and while there's not *quite* enough context = there for me to figure out what was decided, I think this is the = proposal: >=20 > (1) Packet numbers in both long and short headers should no longer = have the property that they monotonically increase >=20 > (a) on the theory that an intermediary that is attempting to lazily = classify QUIC will may classify future discontinuity in this packet = number space as not-QUIC; and >=20 > (b) because packet number monotonicity increases flow linkability over = migration events that the sender does not know about, and we would like = to avoid these. >=20 > Is this the scope of the new PR Martin has volunteered to send? >=20 > Thanks, cheers, >=20 > Brian >=20 >=20 --Apple-Mail=_84FF6327-1B5B-4D21-B1BD-8184553125A5 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpnXvIACgkQihK3vwvq RqPicQ//XiUZ+UqcSwkDZbHaUJugqdc65aavrlxmIBOyDADLshm2KRO5y8JHdLE4 ICU5gSpAW8yvzYUKe1Z2+Fd8gJHx19VeA3ETfEk3cXj/CpDBvyZkX6xDJEGl1l0c 8r+1MP0m/BRbMBZS2hYK132aFjK+K3WqILUxaaPrGcN8UTCplosqpvzMUeU9BROr DpZoTkPLyWwjLCcpSkMqfeG8qYdmYz0LwZSBHf6rjD9iBZBcocJXT+gWY+u4Jc2l HspLYT4ChygW3KQPZN1Ewfbd6GT33YMFB6HDxxb1lpiWTYvIVSX4PYzF6dA+MOuX W66DEGCMIEF/u9CPr77OdbNHQQ60XddOivhjjWnByM1Lm1BkT8sVXlHI0sFAto1b k1prmZA8jW9Xgd+nCOI+elLSqEY+kfS9a1iIVn1KUDW1OiBpwZ49aRv3Efn9HeoA jXR0288zqYndpvBBqPsFUUt/MbLkWaTeHEAjSeDmEbyKyDEsczaNJSQBgbT6lLxQ sv1ZTHpvYW386ExUkgeBJ67wPfntt7jOZ0qvjCmxeHT4N+L4ehgAgDGD/JOQLwBT sb6iVDPc6t6EE5n4cDvhoVkDKTsjCzrBtkcPwMwychfOA9WzIAnU/1Y2QROqGLrl LV887CuJhx6g2D7H1pplOK12O7DmZe81yhNeO10NjXifL2sN4oI= =w8vB -----END PGP SIGNATURE----- --Apple-Mail=_84FF6327-1B5B-4D21-B1BD-8184553125A5-- From nobody Tue Jan 23 09:27:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE296127522 for ; Tue, 23 Jan 2018 09:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 y8VK5Tti5xqK for ; Tue, 23 Jan 2018 09:27:21 -0800 (PST) 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 3493212706D for ; Tue, 23 Jan 2018 09:27:21 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NHM15m010582; Tue, 23 Jan 2018 17:27:16 GMT 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=e/MWtc+mtwJSOxLpJmFxgeP0jJ9Kjx0OhSpSV4t9fbw=; b=NljpMlFvteBtpZUp+iaccEDtoXkzhpu5AUWA6zn+aIsaKtWWS81C04nBeHxDxv/s3MC+ VcIYdipcAGKKhGcL+Y2aGW4XxopM5ZeyGskhf57GnsyeT5w/KQG6qbei4T3rp8f25cY/ IpTHCsIKqTPTHpKOdRkmAMqhb0MGiNVpVGh8DyaYx2FDe5CWnUt6dAk5MjZFmaJtL6RB yn4d3wUx7g4Hb/yJly8Q1kiMw8oidCcq1/noSjyvAJRO+2Cw7mNsQZyJ4KcouA7c2W6d xZ8eDkzWfR+3R3/O2nvDBe2YOo/QJazwZtZwA8V6nr5nXoUaim7kskQTOyAUnSPl2S2B 6w== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2fkuqg29yx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 17:27:16 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0NHQT0c022547; Tue, 23 Jan 2018 12:27:15 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ejbmm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 12:27:15 -0500 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; Tue, 23 Jan 2018 12:27:14 -0500 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; Tue, 23 Jan 2018 12:27:14 -0500 From: "Lubashev, Igor" To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: RE: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAAZnH4g Date: Tue, 23 Jan 2018 17:27:13 +0000 Message-ID: <432ca45e129d488a859a3c0123ad8571@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.38.42] Content-Type: multipart/alternative; boundary="_000_432ca45e129d488a859a3c0123ad8571usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230239 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230238 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 17:27:24 -0000 --_000_432ca45e129d488a859a3c0123ad8571usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think one can take this idea one step further. Right now, flow control on a stream is limiting stream_data_offset to MIN(stream_max_data, connection_max_data - SUM(stream_data_offset)) The new alternative would be limiting stream_data_offset to MAX(stream_max_data, connection_max_data - SUM(stream_data_offset)) A simple way this would work is that the receiver would designate, say, 75%= of connection buffer space to the "common" connection pool (and try to kee= p it at that level via MAX_DATA frames) and 25% of the buffer space - to pe= r-streams buffers. That way, no stream can be starved just because the sen= der has chosen to send data on some other stream earlier. In this scheme, = the total_buffer_space, per_stream_buffer_size, max_concurrent_streams can = determine commn_buffer_size. An alternative way to manage space would be = reserving some per-stream buffers only for "high-priority" streams that can= not be blocked - the scheme to use could be an application's decision. * Igor From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Monday, January 22, 2018 10:50 PM To: quic@ietf.org; igorlord@alum.mit.edu Subject: Deadlock avoidance proposal The problem with deadlocking QUIC streams is the possibility that the sende= r (or proxy) will "use up" connection flow control credits on lower-priorit= y streams, blocking the receiver from making forward progress with any stre= ams. The receiver has no mechanism to direct/force the sender to send on p= referred streams. I would like to propose a concept of "stream data credit" - the concept of = extra flow control credits that can only be used by a specific stream. A S= TREAM_DATA_CREDIT frame would update such credits (see below). Data sent o= n a stream will consume its own credits as much as it can and connection cr= edits (updated by MAX_DATA) for the rest of the data. The updated connection flow control accounting: " For each stream, "used connection credits" is "MAX(the_largest_received_off= set - stream_data_credits, 0)". The sum of "used connection credits" on all streams - including streams in terminal states, but excluding stream 0 - MUST NOT exc= eed the value advertised by a receiver (i.e. MAX_DATA). An endpoint MUST termi= nate a connection with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it used more conne= ction credits than the maximum data value that it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). " The receiver will be able to grant dedicated credits to the high-priority s= tream w/o requiring the sender or the intermediary to know anything about t= he semantics of the protocol and without worrying that the sender/intermedi= ary will "squander" the credits on unimportant streams. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D STREAM_DATA_CREDIT frame. The frame updates Data Credit for a stream. ~~~ 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 (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Credit (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the STREAM_DATA_CREDIT frame are as follows: Stream ID: : The stream ID of the stream that is affected encoded as a variable-length integer. Data Credit: : A variable-length integer indicating the new total data credit for the st= ream. For each stream Data Credit starts with 0. The sender can only increase Da= ta Credit in subsequent STREAM_DATA_CREDIT frames for the same stream, but = loss and reordering can cause STREAM_DATA_CREDIT frames to be received out = of order. STREAM_DATA_CREDIT frames that do not advance Data Credit for th= e stream MUST be ignored. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comments? * Igor --_000_432ca45e129d488a859a3c0123ad8571usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I think one can take this idea one step further.

     

    Right now, flow control on a stream is limiting stre= am_data_offset to

      MIN(stream_max_data, connection_max_data - SU= M(stream_data_offset))

     

    The new alternative would be limiting stream_data_of= fset to

      MAX(stream_max_data, connection_max_data - SU= M(stream_data_offset))

     

     

    A simple way this would work is that the receiver wo= uld designate, say, 75% of connection buffer space to the “commonR= 21; connection pool (and try to keep it at that level via MAX_DATA frames) = and 25% of the buffer space – to per-streams buffers.  That way, no stream can be starved just because the sender has chosen to s= end data on some other stream earlier.  In this scheme, the total_buff= er_space, per_stream_buffer_size, max_concurrent_streams can determine comm= n_buffer_size.   An alternative way to manage space would be reserving some per-stream buffers only for “hi= gh-priority” streams that cannot be blocked – the scheme to use= could be an application’s decision.

     

    • Igor

     

    From: Lubashev, Igor [mailto:ilubashe@akamai.= com]
    Sent: Monday, January 22, 2018 10:50 PM
    To: quic@ietf.org; igorlord@alum.mit.edu
    Subject: Deadlock avoidance proposal

     

    The problem with deadlocking QUIC streams is the pos= sibility that the sender (or proxy) will “use up” connection fl= ow control credits on lower-priority streams, blocking the receiver from ma= king forward progress with any streams.  The receiver has no mechanism to direct/force the sender to send on preferred streams.<= o:p>

     

    I would like to propose a concept of “stream d= ata credit” – the concept of extra flow control credits that ca= n only be used by a specific stream.  A STREAM_DATA_CREDIT frame would= update such credits (see below).  Data sent on a stream will consume its own credits as much as it can and connection credits (upd= ated by MAX_DATA) for the rest of the data.

     

    The updated connection flow control accounting: = ;

     

    “

    For each stream, “used connection credits̶= 1; is “MAX(the_largest_received_offset - stream_data_credits, 0)̶= 1;.

     

    The sum of “used connection credits” on = all streams -

    including streams in terminal states, but excluding = stream 0 - MUST NOT exceed

    the value advertised by a receiver (i.e. MAX_DATA).&= nbsp; An endpoint MUST terminate a connection

    with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA erro= r if it used more connection credits

    than the maximum data value that it has sent, unless= this is a result of a

    change in the initial limits (see {{zerortt-paramete= rs}}).

    “

     

    The receiver will be able to grant dedicated credits= to the high-priority stream w/o requiring the sender or the intermediary t= o know anything about the semantics of the protocol and without worrying th= at the sender/intermediary will “squander” the credits on unimportant streams.

     

     

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

     

    STREAM_DATA_CREDIT frame.

     

    The frame updates Data Credit for a stream.

     

    ~~~

    0        &nb= sp;          1  &nbs= p;            &= nbsp;   2         &n= bsp;         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

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    |        &nb= sp;            =    Stream ID (i)        &= nbsp;           &nbs= p;   ...

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    |        &nb= sp;            =    Data Credit (i)        = ;            &n= bsp;   ...

    +-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+=

    ~~~

     

    The fields in the STREAM_DATA_CREDIT frame are as fo= llows:

     

    Stream ID:

     

    : The stream ID of the stream that is affected encod= ed as a variable-length

      integer.

     

    Data Credit:

     

    : A variable-length integer indicating the new total= data credit for the stream.

     

    For each stream Data Credit starts with 0.  The= sender can only increase Data Credit in subsequent STREAM_DATA_CREDIT fram= es for the same stream, but loss and reordering can cause STREAM_DATA_CREDI= T frames to be received out of order.  STREAM_DATA_CREDIT frames that do not advance Data Credit for the stream M= UST be ignored.

     

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

     

     

    Comments?

     

    • Igor

     

    --_000_432ca45e129d488a859a3c0123ad8571usma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 12:55:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3051112D7E8 for ; Tue, 23 Jan 2018 12:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.281 X-Spam-Level: ** X-Spam-Status: No, score=2.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=I+D5Odrm; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=i6jRniEs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id af8lCsKEoauj for ; Tue, 23 Jan 2018 12:55:16 -0800 (PST) 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 69BBD12AF83 for ; Tue, 23 Jan 2018 12:55:16 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NJxDSr007143; Tue, 23 Jan 2018 12:55:10 -0800 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=bX+QQnzisJcmAWupW6DRmTY8iVS75dwfK0EUvjbv/ww=; b=I+D5OdrmZmG3/gI6/5E6lgygeYxyUgf9xcAxtFju7UawugxvM4HqNR0NZkvnekiuXDaf 6RUpnXg+WVmXYvrQccc21FaNYYkBhTnCmg3BLLaUNqb41gDmDms7c+/Eh5O3tibpeel1 FMZbZIjJNvAYz8pODO9Snn/ens8aLvbPX28= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fpbbw8854-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 12:55:09 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.18) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 12:55:08 -0800 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=bX+QQnzisJcmAWupW6DRmTY8iVS75dwfK0EUvjbv/ww=; b=i6jRniEsaxZQrKejKUUECG/g3N1CL4d47eLZNegUIlCVIPTUrF0dFxkqpDxmGzWQHlN/YuuIEAR+X0Qoy+MfsUgBm4LnEGQFFDxV52U365b0+s/99kGlWTIrAyhYTuwpDvMushEwAcUXt8FfoDi7lvrY8bZo9N1wJtrdFxXT/eY= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2184.namprd15.prod.outlook.com (52.132.131.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.18; Tue, 23 Jan 2018 20:54:51 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Tue, 23 Jan 2018 20:54:51 +0000 From: Roberto Peon To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Re: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMA Date: Tue, 23 Jan 2018 20:54:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::ec7e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2184; 7:aSZcu41Eel0HPm68NoJibzo37lfsT/0sFPxY6Vx0rb1aufUS80C/4kpHnCbbggdUffKC9Xq8TACmhcA8ZC6sGr/O37IWfJY3ZrwYePbqb06/oUeYXGQFX6u/YxVBquCVyxgl6ZwLlxapoIv6bm/cBG5Ob/zHBWBM+Aj/rpN632PNM+moEm90JF0ReB0j7taiN+rsJ9ilj4cLjJ2wS8p/bIYR5B/Vpv/IogR202e5zKI+Kvy2EQ681VhivKON0Wk7; 20:jqUSuTcV9mv4p8Qr9MrKKasiPVwg4MFDv4OZGqbUVVWPQSLT5M8go7HpprF0PruQeM6q+cqNua4XOPk9cPVyCVigVYtd4P2a1CVh/9+L90kioaCkuuWsiUYp1jWGeny4LBj2U7k1yakuURV1WLh20Vx+/dgAT5hGhYTD0xPSuWE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4f517d40-5fce-46e4-6eaf-08d562a38c15 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2184; x-ms-traffictypediagnostic: DM5PR1501MB2184: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(11241501184)(2400081)(944501161)(3002001)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR1501MB2184; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2184; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(346002)(366004)(376002)(199004)(189003)(59450400001)(478600001)(14454004)(76176011)(6506007)(36756003)(53546011)(102836004)(33656002)(6246003)(229853002)(2906002)(3280700002)(6346003)(25786009)(6116002)(83716003)(316002)(561944003)(5660300001)(6512007)(81166006)(6436002)(54896002)(105586002)(86362001)(68736007)(3660700001)(8936002)(2501003)(7736002)(82746002)(2900100001)(97736004)(81156014)(5250100002)(99286004)(2171002)(2201001)(2950100002)(6306002)(3480700004)(106356001)(110136005)(53936002)(8676002)(551984002)(6486002)(7116003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2184; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DF1E63xEM1RepYVZXn58rjnB6ktPjpfM0YiTF+PcRoShCWXsJ8vmrmUkW35WqMUYcmvvLOhvQz7dwv8EIr8pmA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E4300D0B6C204857ABCFF261EDBC2613fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4f517d40-5fce-46e4-6eaf-08d562a38c15 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 20:54:51.1138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2184 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 20:55:19 -0000 --_000_E4300D0B6C204857ABCFF261EDBC2613fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3VsZCBuZWVkIHRvIGJlIGV4cHJlc3NlZCBhcyBhIHN0 cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMgdGhlIHJhY2VzIGFuZCBhbGxvd3MgdGhlIG1hdGgg eW91IGhhdmUgZG93biB0aGVyZSB0byB3b3JrIHByb3Blcmx5KS4gSSBzdXNwZWN0IHRoaXMgaXMg d2hhdCB5b3UgbWVhbiBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCk90aGVyd2lzZSwgbG9va3MgZ29v ZC4gVGhpcyB3b3VsZCBmYWxsIHVuZGVyIHRoZSDigJhhbGxvdyBtb3JlIGJ1ZmZlcmluZyBhdCB0 aGUgYXBwbGljYXRpb27igJkgYnVsbGV0IE1hcnRpbiBoYWQsIGJ1dCBJIGJlbGlldmUgdGhhdCBp cyBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZG8gaWYgaXQgaXMgY29uc3RyYWluZWQgYW5kIGRpcmVj dGVkIGJ5IHRoZSBhcHBsaWNhdGlvbiAod2hpY2ggY291bGQgZGVjaWRlIHRvIGNhbmNlbCBhIHN0 cmVhbSB0b28pLg0KDQpTaW5jZSBmbG93IGNvbnRyb2wgaXMgZTJlLCB0aGlzIGRvZXNu4oCZdCBp bXBhY3QgbWVtb3J5IGF0IGEgcHJveHkuDQoNCldoYXQgdGhpcyBkb2VzbuKAmXQgc29sdmUgaXMg dGhlIGRldGVjdGlvbiBwcm9ibGVt4oCUaWYgdGhlcmUgYXJlIG11bHRpLXBhcnRpZXMgZ29pbmcg dGhyb3VnaCBhbnkgY2hva2Vwb2ludCwgdGhhdCBjaG9rZXBvaW50IHdvdWxkIG5lZWQgdG8gYWR2 ZXJ0aXNlIHRoYXQgaXQgd2FzIGJsb2NrZWQgb24gZmxvdyBjb250cm9sIHRvIHRoZSBlbnRpdGll cyB3aGljaCB3ZXJlIGRyYWluaW5nIGRhdGEgZnJvbSBpdC4gQW4gYXBwbGljYXRpb24gY291bGQg aW5mZXIgdGhhdCB0aGlzIG1pZ2h0IGJlIGhhcHBlbmluZyBieSBub3QgcmVjZWl2aW5nIGRhdGEs IGJ1dCB0aGF0IGNvdWxkIGhhcHBlbiBiZWNhdXNlIHRoZSBzZW5kZXIgaXMgc2xvdyByYXRoZXIg dGhhbiBiZWluZyBibG9ja2VkLg0KDQotPVINCg0KDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNl c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJMdWJhc2hldiwgSWdvciIgPGlsdWJhc2hlQGFrYW1h aS5jb20+DQpEYXRlOiBUdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDI6NTAgUE0NClRvOiAi cXVpY0BpZXRmLm9yZyIgPHF1aWNAaWV0Zi5vcmc+LCAiaWdvcmxvcmRAYWx1bS5taXQuZWR1IiA8 aWdvcmxvcmRAYWx1bS5taXQuZWR1Pg0KU3ViamVjdDogRGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bv c2FsDQoNClRoZSBwcm9ibGVtIHdpdGggZGVhZGxvY2tpbmcgUVVJQyBzdHJlYW1zIGlzIHRoZSBw b3NzaWJpbGl0eSB0aGF0IHRoZSBzZW5kZXIgKG9yIHByb3h5KSB3aWxsIOKAnHVzZSB1cOKAnSBj b25uZWN0aW9uIGZsb3cgY29udHJvbCBjcmVkaXRzIG9uIGxvd2VyLXByaW9yaXR5IHN0cmVhbXMs IGJsb2NraW5nIHRoZSByZWNlaXZlciBmcm9tIG1ha2luZyBmb3J3YXJkIHByb2dyZXNzIHdpdGgg YW55IHN0cmVhbXMuICBUaGUgcmVjZWl2ZXIgaGFzIG5vIG1lY2hhbmlzbSB0byBkaXJlY3QvZm9y Y2UgdGhlIHNlbmRlciB0byBzZW5kIG9uIHByZWZlcnJlZCBzdHJlYW1zLg0KDQpJIHdvdWxkIGxp a2UgdG8gcHJvcG9zZSBhIGNvbmNlcHQgb2Yg4oCcc3RyZWFtIGRhdGEgY3JlZGl04oCdIOKAkyB0 aGUgY29uY2VwdCBvZiBleHRyYSBmbG93IGNvbnRyb2wgY3JlZGl0cyB0aGF0IGNhbiBvbmx5IGJl IHVzZWQgYnkgYSBzcGVjaWZpYyBzdHJlYW0uICBBIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSB3 b3VsZCB1cGRhdGUgc3VjaCBjcmVkaXRzIChzZWUgYmVsb3cpLiAgRGF0YSBzZW50IG9uIGEgc3Ry ZWFtIHdpbGwgY29uc3VtZSBpdHMgb3duIGNyZWRpdHMgYXMgbXVjaCBhcyBpdCBjYW4gYW5kIGNv bm5lY3Rpb24gY3JlZGl0cyAodXBkYXRlZCBieSBNQVhfREFUQSkgZm9yIHRoZSByZXN0IG9mIHRo ZSBkYXRhLg0KDQpUaGUgdXBkYXRlZCBjb25uZWN0aW9uIGZsb3cgY29udHJvbCBhY2NvdW50aW5n Og0KDQrigJwNCkZvciBlYWNoIHN0cmVhbSwg4oCcdXNlZCBjb25uZWN0aW9uIGNyZWRpdHPigJ0g aXMg4oCcTUFYKHRoZV9sYXJnZXN0X3JlY2VpdmVkX29mZnNldCAtIHN0cmVhbV9kYXRhX2NyZWRp dHMsIDAp4oCdLg0KDQpUaGUgc3VtIG9mIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIG9u IGFsbCBzdHJlYW1zIC0NCmluY2x1ZGluZyBzdHJlYW1zIGluIHRlcm1pbmFsIHN0YXRlcywgYnV0 IGV4Y2x1ZGluZyBzdHJlYW0gMCAtIE1VU1QgTk9UIGV4Y2VlZA0KdGhlIHZhbHVlIGFkdmVydGlz ZWQgYnkgYSByZWNlaXZlciAoaS5lLiBNQVhfREFUQSkuICBBbiBlbmRwb2ludCBNVVNUIHRlcm1p bmF0ZSBhIGNvbm5lY3Rpb24NCndpdGggYSBRVUlDX0ZMT1dfQ09OVFJPTF9SRUNFSVZFRF9UT09f TVVDSF9EQVRBIGVycm9yIGlmIGl0IHVzZWQgbW9yZSBjb25uZWN0aW9uIGNyZWRpdHMNCnRoYW4g dGhlIG1heGltdW0gZGF0YSB2YWx1ZSB0aGF0IGl0IGhhcyBzZW50LCB1bmxlc3MgdGhpcyBpcyBh IHJlc3VsdCBvZiBhDQpjaGFuZ2UgaW4gdGhlIGluaXRpYWwgbGltaXRzIChzZWUge3t6ZXJvcnR0 LXBhcmFtZXRlcnN9fSkuDQrigJwNCg0KVGhlIHJlY2VpdmVyIHdpbGwgYmUgYWJsZSB0byBncmFu dCBkZWRpY2F0ZWQgY3JlZGl0cyB0byB0aGUgaGlnaC1wcmlvcml0eSBzdHJlYW0gdy9vIHJlcXVp cmluZyB0aGUgc2VuZGVyIG9yIHRoZSBpbnRlcm1lZGlhcnkgdG8ga25vdyBhbnl0aGluZyBhYm91 dCB0aGUgc2VtYW50aWNzIG9mIHRoZSBwcm90b2NvbCBhbmQgd2l0aG91dCB3b3JyeWluZyB0aGF0 IHRoZSBzZW5kZXIvaW50ZXJtZWRpYXJ5IHdpbGwg4oCcc3F1YW5kZXLigJ0gdGhlIGNyZWRpdHMg b24gdW5pbXBvcnRhbnQgc3RyZWFtcy4NCg0KDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQpTVFJFQU1f REFUQV9DUkVESVQgZnJhbWUuDQoNClRoZSBmcmFtZSB1cGRhdGVzIERhdGEgQ3JlZGl0IGZvciBh IHN0cmVhbS4NCg0Kfn5+DQowICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAg ICAgICAgICAgU3RyZWFtIElEIChpKSAgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCnwgICAgICAgICAgICAgICAgICAgICAgICBEYXRhIENyZWRpdCAoaSkgICAgICAgICAgICAg ICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp+fn4NCg0KVGhlIGZpZWxkcyBpbiB0aGUgU1RSRUFN X0RBVEFfQ1JFRElUIGZyYW1lIGFyZSBhcyBmb2xsb3dzOg0KDQpTdHJlYW0gSUQ6DQoNCjogVGhl IHN0cmVhbSBJRCBvZiB0aGUgc3RyZWFtIHRoYXQgaXMgYWZmZWN0ZWQgZW5jb2RlZCBhcyBhIHZh cmlhYmxlLWxlbmd0aA0KICBpbnRlZ2VyLg0KDQpEYXRhIENyZWRpdDoNCg0KOiBBIHZhcmlhYmxl LWxlbmd0aCBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIG5ldyB0b3RhbCBkYXRhIGNyZWRpdCBmb3Ig dGhlIHN0cmVhbS4NCg0KRm9yIGVhY2ggc3RyZWFtIERhdGEgQ3JlZGl0IHN0YXJ0cyB3aXRoIDAu ICBUaGUgc2VuZGVyIGNhbiBvbmx5IGluY3JlYXNlIERhdGEgQ3JlZGl0IGluIHN1YnNlcXVlbnQg U1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyBmb3IgdGhlIHNhbWUgc3RyZWFtLCBidXQgbG9zcyBh bmQgcmVvcmRlcmluZyBjYW4gY2F1c2UgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyB0byBiZSBy ZWNlaXZlZCBvdXQgb2Ygb3JkZXIuICBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIHRoYXQgZG8g bm90IGFkdmFuY2UgRGF0YSBDcmVkaXQgZm9yIHRoZSBzdHJlYW0gTVVTVCBiZSBpZ25vcmVkLg0K DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KDQoNCkNvbW1lbnRzPw0KDQoNCiAgKiAgIElnb3INCg== --_000_E4300D0B6C204857ABCFF261EDBC2613fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNv SW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTAyMzM1 NzM5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NzE4 MTYwNDAgLTE2ODE3MjUwMDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNl cmlmO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXtt c28tbGlzdC1pZDoxOTg4OTY4NTk0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTEzMzg1NTEz ODt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3RyZWFtLWRhdGEtY3JlZGl0 IHdvdWxkIG5lZWQgdG8gYmUgZXhwcmVzc2VkIGFzIGEgc3RyZWFtIG9mZnNldCAodGhpcyByZXNv bHZlcyB0aGUgcmFjZXMgYW5kIGFsbG93cyB0aGUgbWF0aCB5b3UgaGF2ZSBkb3duIHRoZXJlIHRv IHdvcmsgcHJvcGVybHkpLiBJIHN1c3BlY3QgdGhpcyBpcyB3aGF0IHlvdSBtZWFuIGluIHRoZSBm aXJzdCBwbGFjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCk90 aGVyd2lzZSwgbG9va3MgZ29vZC4gVGhpcyB3b3VsZCBmYWxsIHVuZGVyIHRoZSDigJhhbGxvdyBt b3JlIGJ1ZmZlcmluZyBhdCB0aGUgYXBwbGljYXRpb27igJkgYnVsbGV0IE1hcnRpbiBoYWQsIGJ1 dCBJIGJlbGlldmUgdGhhdCBpcyBhIHJlYXNvbmFibGUgdGhpbmcgdG8gZG8gaWYgaXQgaXMgY29u c3RyYWluZWQgYW5kIGRpcmVjdGVkIGJ5IHRoZSBhcHBsaWNhdGlvbiAod2hpY2ggY291bGQgZGVj aWRlIHRvIGNhbmNlbCBhIHN0cmVhbSB0b28pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KU2luY2UgZmxvdyBjb250cm9sIGlzIGUyZSwgdGhpcyBkb2VzbuKAmXQg aW1wYWN0IG1lbW9yeSBhdCBhIHByb3h5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IHRo aXMgZG9lc27igJl0IHNvbHZlIGlzIHRoZSBkZXRlY3Rpb24gcHJvYmxlbeKAlGlmIHRoZXJlIGFy ZSBtdWx0aS1wYXJ0aWVzIGdvaW5nIHRocm91Z2ggYW55IGNob2tlcG9pbnQsIHRoYXQgY2hva2Vw b2ludCB3b3VsZCBuZWVkIHRvIGFkdmVydGlzZSB0aGF0IGl0IHdhcyBibG9ja2VkIG9uIGZsb3cg Y29udHJvbCB0byB0aGUgZW50aXRpZXMgd2hpY2ggd2VyZSBkcmFpbmluZyBkYXRhIGZyb20gaXQu IEFuIGFwcGxpY2F0aW9uDQogY291bGQgaW5mZXIgdGhhdCB0aGlzIG1pZ2h0IGJlIGhhcHBlbmlu ZyBieSBub3QgcmVjZWl2aW5nIGRhdGEsIGJ1dCB0aGF0IGNvdWxkIGhhcHBlbiBiZWNhdXNlIHRo ZSBzZW5kZXIgaXMgc2xvdyByYXRoZXIgdGhhbiBiZWluZyBibG9ja2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm IG9mICZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDI6NTAgUE08 YnI+DQo8Yj5UbzogPC9iPiZxdW90O3F1aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtpZ29ybG9yZEBhbHVtLm1pdC5lZHUmcXVvdDsgJmx0O2lnb3Jsb3JkQGFs dW0ubWl0LmVkdSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+RGVhZGxvY2sgYXZvaWRhbmNlIHBy b3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBwcm9ibGVtIHdpdGggZGVhZGxvY2tpbmcgUVVJQyBzdHJlYW1zIGlzIHRoZSBwb3Nz aWJpbGl0eSB0aGF0IHRoZSBzZW5kZXIgKG9yIHByb3h5KSB3aWxsIOKAnHVzZSB1cOKAnSBjb25u ZWN0aW9uIGZsb3cgY29udHJvbCBjcmVkaXRzIG9uIGxvd2VyLXByaW9yaXR5IHN0cmVhbXMsIGJs b2NraW5nIHRoZSByZWNlaXZlciBmcm9tIG1ha2luZyBmb3J3YXJkIHByb2dyZXNzIHdpdGggYW55 IHN0cmVhbXMuJm5ic3A7IFRoZSByZWNlaXZlcg0KIGhhcyBubyBtZWNoYW5pc20gdG8gZGlyZWN0 L2ZvcmNlIHRoZSBzZW5kZXIgdG8gc2VuZCBvbiBwcmVmZXJyZWQgc3RyZWFtcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBjb25jZXB0IG9mIOKAnHN0 cmVhbSBkYXRhIGNyZWRpdOKAnSDigJMgdGhlIGNvbmNlcHQgb2YgZXh0cmEgZmxvdyBjb250cm9s IGNyZWRpdHMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGJ5IGEgc3BlY2lmaWMgc3RyZWFtLiZuYnNw OyBBIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSB3b3VsZCB1cGRhdGUgc3VjaCBjcmVkaXRzIChz ZWUgYmVsb3cpLiZuYnNwOyBEYXRhIHNlbnQgb24gYSBzdHJlYW0NCiB3aWxsIGNvbnN1bWUgaXRz IG93biBjcmVkaXRzIGFzIG11Y2ggYXMgaXQgY2FuIGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVw ZGF0ZWQgYnkgTUFYX0RBVEEpIGZvciB0aGUgcmVzdCBvZiB0aGUgZGF0YS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIHVwZGF0ZWQgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgYWNjb3VudGlu ZzombmJzcDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGVhY2ggc3RyZWFtLCDigJx1c2VkIGNvbm5lY3Rpb24gY3Jl ZGl0c+KAnSBpcyDigJxNQVgodGhlX2xhcmdlc3RfcmVjZWl2ZWRfb2Zmc2V0IC0gc3RyZWFtX2Rh dGFfY3JlZGl0cywgMCnigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzdW0gb2Yg4oCc dXNlZCBjb25uZWN0aW9uIGNyZWRpdHPigJ0gb24gYWxsIHN0cmVhbXMgLTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5jbHVkaW5nIHN0cmVhbXMgaW4gdGVybWluYWwgc3Rh dGVzLCBidXQgZXhjbHVkaW5nIHN0cmVhbSAwIC0gTVVTVCBOT1QgZXhjZWVkPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgdmFsdWUgYWR2ZXJ0aXNlZCBieSBhIHJlY2Vp dmVyIChpLmUuIE1BWF9EQVRBKS4mbmJzcDsgQW4gZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgYSBj b25uZWN0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoIGEgUVVJ Q19GTE9XX0NPTlRST0xfUkVDRUlWRURfVE9PX01VQ0hfREFUQSBlcnJvciBpZiBpdCB1c2VkIG1v cmUgY29ubmVjdGlvbiBjcmVkaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij50aGFuIHRoZSBtYXhpbXVtIGRhdGEgdmFsdWUgdGhhdCBpdCBoYXMgc2VudCwgdW5sZXNzIHRo aXMgaXMgYSByZXN1bHQgb2YgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Y2hhbmdlIGluIHRoZSBpbml0aWFsIGxpbWl0cyAoc2VlIHt7emVyb3J0dC1wYXJhbWV0ZXJzfX0p LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSByZWNlaXZlciB3aWxsIGJlIGFibGUgdG8gZ3JhbnQgZGVkaWNhdGVkIGNy ZWRpdHMgdG8gdGhlIGhpZ2gtcHJpb3JpdHkgc3RyZWFtIHcvbyByZXF1aXJpbmcgdGhlIHNlbmRl ciBvciB0aGUgaW50ZXJtZWRpYXJ5IHRvIGtub3cgYW55dGhpbmcgYWJvdXQgdGhlIHNlbWFudGlj cyBvZiB0aGUgcHJvdG9jb2wgYW5kIHdpdGhvdXQgd29ycnlpbmcgdGhhdCB0aGUgc2VuZGVyL2lu dGVybWVkaWFyeSB3aWxsIOKAnHNxdWFuZGVy4oCdDQogdGhlIGNyZWRpdHMgb24gdW5pbXBvcnRh bnQgc3RyZWFtcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5TVFJFQU1fREFUQV9DUkVESVQgZnJhbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoZSBmcmFtZSB1cGRhdGVzIERhdGEgQ3JlZGl0IGZvciBhIHN0cmVhbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+fn5+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN0cmVhbSBJRCAoaSkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRhIENyZWRpdCAoaSkm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+fn5+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmaWVsZHMgaW4g dGhlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3RyZWFtIElEOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj46IFRoZSBzdHJl YW0gSUQgb2YgdGhlIHN0cmVhbSB0aGF0IGlzIGFmZmVjdGVkIGVuY29kZWQgYXMgYSB2YXJpYWJs ZS1sZW5ndGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbnRl Z2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXRhIENyZWRpdDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+OiBBIHZhcmlhYmxlLWxlbmd0aCBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIG5ldyB0 b3RhbCBkYXRhIGNyZWRpdCBmb3IgdGhlIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Rm9yIGVhY2ggc3RyZWFtIERhdGEgQ3JlZGl0IHN0YXJ0cyB3aXRoIDAuJm5ic3A7IFRoZSBzZW5k ZXIgY2FuIG9ubHkgaW5jcmVhc2UgRGF0YSBDcmVkaXQgaW4gc3Vic2VxdWVudCBTVFJFQU1fREFU QV9DUkVESVQgZnJhbWVzIGZvciB0aGUgc2FtZSBzdHJlYW0sIGJ1dCBsb3NzIGFuZCByZW9yZGVy aW5nIGNhbiBjYXVzZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIHRvIGJlIHJlY2VpdmVkIG91 dCBvZiBvcmRlci4mbmJzcDsNCiBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIHRoYXQgZG8gbm90 IGFkdmFuY2UgRGF0YSBDcmVkaXQgZm9yIHRoZSBzdHJlYW0gTVVTVCBiZSBpZ25vcmVkLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRz PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8z Ij5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E4300D0B6C204857ABCFF261EDBC2613fbcom_-- From nobody Tue Jan 23 13:43:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BF012D834 for ; Tue, 23 Jan 2018 13:43:47 -0800 (PST) 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 05F3Sur769F5 for ; Tue, 23 Jan 2018 13:43:44 -0800 (PST) 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 4891F127735 for ; Tue, 23 Jan 2018 13:43:44 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ee6M1-0003Op-H5 for quic@ietf.org; Tue, 23 Jan 2018 22:43:42 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ee6LQ-0008Sm-J5 for quic@ietf.org; Tue, 23 Jan 2018 16:43:38 -0500 Received: (qmail 15160 invoked from network); 23 Jan 2018 21:43:02 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Jan 2018 21:43:01 -0000 To: "Brian Trammell (IETF)" , "Lubashev, Igor" References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: QUIC WG From: Christian Huitema Message-ID: <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> Date: Tue, 23 Jan 2018 11:42:44 -1000 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="s1CPwgdnXocqkPJhelIKRQoKIq1ttU2TU" Subject: Re: what was yesterday's packet number decision? X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.30) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lRrHGvCGfgVjOvrpfBDy7QXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuPVyM8qKTGI5Y1HV044foBB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P70Wh5w/+UOMJWpUhakfGXPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA+RIanNskcVaAsgQvWYhIsUONoJfh+XjGSeeT90H/uIEE 5WkevlzBXGpgauriE9hyv5HoHJ+E6SnvFSGdX3dU6mbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWN4ZNH6v0KsokFeP+Z5h4BvfFcHV2tQAVqGdj/zM7G/GWbjl4MpjTNPMnYcbh6U8Z5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 21:43:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s1CPwgdnXocqkPJhelIKRQoKIq1ttU2TU Content-Type: multipart/mixed; boundary="CArGwJuOLsBfoELa4R1FcqpW0L8NKdCLh"; protected-headers="v1" From: Christian Huitema To: "Brian Trammell (IETF)" , "Lubashev, Igor" Cc: QUIC WG Message-ID: <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> Subject: Re: what was yesterday's packet number decision? References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: --CArGwJuOLsBfoELa4R1FcqpW0L8NKdCLh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/23/2018 6:12 AM, Brian Trammell (IETF) wrote: >> On 23 Jan 2018, at 16:18, Lubashev, Igor wrote: >> >>> (b) because packet number monotonicity increases flow linkability ove= r migration events that the sender does not know about, and we would like= to avoid these. >> Would not the Connection ID give it away in these cases anyway? Cases= when the sender does know about migration events may fare better, if the= sender has received NEW_CONNECTION_ID in advance of the migration event.= > Yeah, that's part of why I'm confused by the notes. > > I think the underlying requirement here is to give an endpoint (define= d either as "the sender of a direction of a QUIC flow" or more explicitly= as "the client") some measure of control over how linkable its packets a= re. Not using CID at all, and obfuscating the packet sequence, increases = the complexity of flow linkage during involuntary migration. > > (I say "increases the complexity" as opposed to "reduces linkability" b= ecause, as a measurement geek, I'm deeply pessimistic about the ability t= o eliminate linkability of packets sent by the same sender. After you hav= e added a runtime requirement to keep some amount of per-flow state in or= der to link packets to a flow, any additional complexity in packet number= obfuscation only serves to increase the amount of work to design an algo= rithm for linking packets, i.e., it increases the number of masters' and/= or doctoral degrees awarded to people who work on solving the problem of = linking QUIC flows.)\ In addition to linkability, there is an AEAD issue. We MUST guarantee that the same packet sequence number will not be used twice with the same key. One class of solution is to use different encryption keys per connection ID. We looked at that, and the sense of the room was that it was very complex. But if we use the same encryption context across multiple connection ID, the simplest way to guarantee that packet sequence numbers don't repeat on multiple connection is to use a "global sequence". And if you do that, you have a really big issue with linkability, and the easiest way to solve that is to encrypt the packet sequence number. Encrypting the packet sequence number also has the nice property of ensuring that non invariant bits cannot be easily guessed by middle-boxes. So, it prevent ossification, and will allow us to later switch to for example var length encoding. Another nice property of encrypted sequence numbers is that they can start at zero, which reduces the size of ACK packets. We may want to have a discussion about exposing a 1, 2 or 3 bit sequence number in clear text, so intermediaries can observe it and deduce issues like losses or reordering. But we should be deliberate about that, and follow pretty much the same process as for reserving the spin bit. -- Christian Huitema --CArGwJuOLsBfoELa4R1FcqpW0L8NKdCLh-- --s1CPwgdnXocqkPJhelIKRQoKIq1ttU2TU 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 iQEcBAEBCAAGBQJaZ6xiAAoJELba05IUOHVQL2AIAJZ6cCfj1T0OH0BOg9Yb+RNn BMCVDdIDoCSJV1mnNyH1hgy7W9bGUDpsGEDa0Yoqc+oQE/pEApnuEoTx9cNKCzWv lt50gnxK8JOg6KPiErJ3KwyH+o24Dm9m9xMFro+PzBX+WCzuu/pQyar1C+xaCiQE yzvwLpLactNqZjLVFbeOV1/zlB/ZEA4LzkntxFbtUKM1Dl14uaUWfhrh1Me5CD1K pnPJDn/gp5XlGCTnrybjd+PBKDbIolUTZ5aUGJG6a5jMk4RYHuo3jZCcOXSQd8GY oMgqlE/9I0twPib4PJfknmzFLI+RQwqYGUE+KloA582JZKls6MuxHzj3g0dBZdA= =lOti -----END PGP SIGNATURE----- --s1CPwgdnXocqkPJhelIKRQoKIq1ttU2TU-- From nobody Tue Jan 23 13:47:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1FC12D834 for ; Tue, 23 Jan 2018 13:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ByYkr6B2xcze for ; Tue, 23 Jan 2018 13:47:03 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 89F66127735 for ; Tue, 23 Jan 2018 13:47:03 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id 196so2752748iti.5 for ; Tue, 23 Jan 2018 13:47:03 -0800 (PST) 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=NnRJT2zHyApTfDz2RVEd5/OsgO5St3QRvDPS3VEqwCo=; b=MrQjT+6nUiZnvHSShWbb5adVs+Sp9F/P+mLUziXrP+DHkNn9qoGVwcKTu8GzVU4bj0 Bu4BIFzGosKLgM0v2Qo3Ui5p2mOTu02rAd2D+5y9T0pVXiIdJ+VXQnny/sxemCjBt00p dZHoI3oRItzQycpJZXeaXABmGRVzzHrUpcscVdmPHKCdFdswVlz70GoGWAk+gdrEzWBO amEtYSNulOndSATbT6yMNUCgYIVbX1PaabWTuaAiC7ZKZdPe+WMdHwhRrmjGRsZyFGHZ s6ret9zMru1tGguUGhVhFxTvvUMxJSWPUeWNgVtZxbj0AMq7HfhHotZWqas5zPxS8WqD eSOw== 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=NnRJT2zHyApTfDz2RVEd5/OsgO5St3QRvDPS3VEqwCo=; b=f42ju9fM9LpbfOaazRLmGFXgU3f/B1vyiCx+ueCGdNmknUpGUDsFMIdiNAp6f+B6ak fxOEU8LdWXUVjvLpTEevAprTk1R2FRC9iAwjqDQ5zJ6VpT7Wq+1xMaos93+BKV1pVgTJ stLGpbyq49RJSi8oUVeQigbr88YM/PR5Y9TS7bGB7CzX6ZOdgHxc5SDqFChopwb4oGyA GyEmSeczOhcU2gTXYhO7sF42G9+fEajblI9QtuFmXfZO+FOqVXta2BDxGYZpzBbNfkOR B6/Rhr4JZTDYr0ZhizKx07MwLG/J/eu76OVWjactD47V4hO5L0f8ONkewWaX2EgmNvA6 0BdA== X-Gm-Message-State: AKwxyteFfgmf/U6YXGavQevS4OBV9T95VWUnko2xmekGJxJbHOU1Bowf mu4OYFCKAe8LqyhUch36YekedT+mvvOVuoMpBwzcrg== X-Google-Smtp-Source: AH8x2253X5xT9zimej6DXWnDmFeb9Zi+iT/GevNqVzjiaO3getTOJRwl7C/Vxa39uMGo9diUxz775tyyKCnf3Oi56Mw= X-Received: by 10.36.88.83 with SMTP id f80mr6153936itb.66.1516744022716; Tue, 23 Jan 2018 13:47:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 23 Jan 2018 13:46:41 -0800 (PST) In-Reply-To: References: <20180123063052.GA25014@ubuntu-dmitri> From: Ian Swett Date: Tue, 23 Jan 2018 16:46:41 -0500 Message-ID: Subject: Re: So how critical is header compression? To: Mike Bishop Cc: Dmitri Tikhonov , Martin Thomson , IETF QUIC WG , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="001a1144bf22b1096a0563787c18" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 21:47:05 -0000 --001a1144bf22b1096a0563787c18 Content-Type: text/plain; charset="UTF-8" I would agree with Mike's understanding. On Tue, Jan 23, 2018 at 6:14 AM, Mike Bishop wrote: > I thought the last one was pretty clearly answered as well: The transport > doesn't trust that the application will read. If HTTP fails to read in > certain cases, that's exactly what flow control is for. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Dmitri Tikhonov > Sent: Tuesday, January 23, 2018 5:31 PM > To: Martin Thomson > Cc: IETF QUIC WG ; Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> > Subject: Re: So how critical is header compression? > > On Tue, Jan 23, 2018 at 04:43:44PM +1100, Martin Thomson wrote: > > This is probably a moot point given the decision today. I think that > > we have a plan. > > The Working Group decided only two of the three questions that were to be > posed, as the last slide never quite made it onto the main screen. The > questions were: > > 1. Allow or disallow blocking? > 2. Configurable (or negotiable) blocking or not blocking? > 3. Delayed reading from transport OK? > > In regards to 1 and 2 the Working Group responded with "allow" and > "yes: make this into a knob." > > The answer to the last question, however, has important implications. > I think we should revisit this issue: that is, the Working Group should > decide explicitly whether not reading from stream is appropriate. Now is > the time to think about corner cases. > > - Dmitri. > > --001a1144bf22b1096a0563787c18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I would agree with Mike's understanding.

    On Tue, Jan 23, 2018 at 6= :14 AM, Mike Bishop <mbishop@evequefou.be> wrote:
    I thought the last one was pretty clearly answer= ed as well:=C2=A0 The transport doesn't trust that the application will= read.=C2=A0 If HTTP fails to read in certain cases, that's exactly wha= t flow control is for.

    -----Original Message-----
    From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Dmitri Tikhonov
    Sent: Tuesday, January 23, 2018 5:31 PM
    To: Martin Thomson <martin.t= homson@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>= ; Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
    Subject: Re: So how critical is header compression?

    On Tue, Jan 23, 2018 at 04:43:44PM +1100, Martin Thomson wrote:
    > This is probably a moot point given the decision today.=C2=A0 I think = that
    > we have a plan.

    The Working Group decided only two of the three questions that were to be p= osed, as the last slide never quite made it onto the main screen.=C2=A0 The= questions were:

    =C2=A0 =C2=A0 1. Allow or disallow blocking?
    =C2=A0 =C2=A0 2. Configurable (or negotiable) blocking or not blocking?
    =C2=A0 =C2=A0 3. Delayed reading from transport OK?

    In regards to 1 and 2 the Working Group responded with "allow" an= d
    "yes: make this into a knob."

    The answer to the last question, however, has important implications.
    I think we should revisit this issue: that is, the Working Group should dec= ide explicitly whether not reading from stream is appropriate.=C2=A0 Now is= the time to think about corner cases.

    =C2=A0 - Dmitri.


    --001a1144bf22b1096a0563787c18-- From nobody Tue Jan 23 13:51:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA54E12D84C for ; Tue, 23 Jan 2018 13:51:09 -0800 (PST) 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 1e0yJuV-H8dZ for ; Tue, 23 Jan 2018 13:51:08 -0800 (PST) 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 3635B12D84A for ; Tue, 23 Jan 2018 13:51:07 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ee6Sz-0002R5-R5 for quic@ietf.org; Tue, 23 Jan 2018 22:50:54 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ee6St-0003id-4T for quic@ietf.org; Tue, 23 Jan 2018 16:50:47 -0500 Received: (qmail 985 invoked from network); 23 Jan 2018 21:50:46 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Jan 2018 21:50:45 -0000 To: "Brian Trammell (IETF)" , "Lubashev, Igor" References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> Cc: QUIC WG From: Christian Huitema Message-ID: <0a25a0ec-e2af-2e49-2d8f-41b014568cac@huitema.net> Date: Tue, 23 Jan 2018 11:50:33 -1000 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: <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8qrxSmadVTt4aMNP0eDPSS0HHwxXnakoW" Subject: Re: what was yesterday's packet number decision? X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qkgyOyT6L6eLLfqJ/DcHMAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsW88PHLDhEgBjub+qD/Sb8B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIKcwsOsYjBjCZN249H7KzSqpR+WsWEoFdiO1WLSqm BEA/tx0nltDLnzGb0iBoOffGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIHm SsOpnpkP1h+zL+fOVPFV+IHvBpJ29PdJVTcXuw1cpGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 21:51:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8qrxSmadVTt4aMNP0eDPSS0HHwxXnakoW Content-Type: multipart/mixed; boundary="saF6soG72m8Ck1aMjI80bIXTAMW2ghO3p"; protected-headers="v1" From: Christian Huitema To: "Brian Trammell (IETF)" , "Lubashev, Igor" Cc: QUIC WG Message-ID: <0a25a0ec-e2af-2e49-2d8f-41b014568cac@huitema.net> Subject: Re: what was yesterday's packet number decision? References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> In-Reply-To: <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> --saF6soG72m8Ck1aMjI80bIXTAMW2ghO3p Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/23/2018 11:42 AM, Christian Huitema wrote: > Encrypting the packet sequence number also has the nice property of > ensuring that non invariant bits cannot be easily guessed by > middle-boxes. So, it prevent ossification, and will allow us to later > switch to for example var length encoding. By the way, the have the same problem with the first octet. We may want to encrypt the non invariant bits, in order to prevent ossification. But we dedided to treat that separately from packet sequence number encryptio= n. -- Christian Huitema --saF6soG72m8Ck1aMjI80bIXTAMW2ghO3p-- --8qrxSmadVTt4aMNP0eDPSS0HHwxXnakoW 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 iQEcBAEBCAAGBQJaZ64yAAoJELba05IUOHVQyZcH/j3O77vn1TVIHyZ9YRaYQK9w +fnNSa8dyKcBvzTO/aqP0/kkDRDQ2/w16yH4j2axSga33REkGy6LamuNydifD5IB lgQZzZnxs3wM2Nt1fpp7S6loLRvDi57XQos0um90pbDNUPh4pc85TuIBr4droBBa OvGvOFPQdLdYgrEERthVZ5ibv2KmntP7jxr9Z82rgqFpmUYsVjPxH+mhhtD/VNhA pxWYg6IPOpNzdJMyBdtrpm65+CNPguJRJ2Lbsq6XOQiA9rqmrjGBiZa27iwZLHNY /fbj67nyzXw2vSW3XRm7dilmTDKluIWKFNdef9Lsl1lLIbSw25IkeQhmdOCD2Kc= =HY74 -----END PGP SIGNATURE----- --8qrxSmadVTt4aMNP0eDPSS0HHwxXnakoW-- From nobody Tue Jan 23 14:08:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4CFA12D854 for ; Tue, 23 Jan 2018 14:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 OvQf1aoNpt_m for ; Tue, 23 Jan 2018 14:08:09 -0800 (PST) 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 5367B12D850 for ; Tue, 23 Jan 2018 14:08:09 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NM6mlL016149; Tue, 23 Jan 2018 22:08:02 GMT 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=HAKWFrEwP77jf2AjMVnQ0MxTKgfcs40Z6sG7RvUKKAE=; b=a9kz/3vj6j5LPLg6NWQRL/HRlBnqio1dLpijkYmveAzjayOdgn1H6g8Pf/tqZAueEH0W naRCerukFsZsAeE9lN2d115uggQQwivulFT5fNGMYUaBciC6OOEdjewyF46C5MDj+hlN nThJrgeUJ/z2Sr1HFDTWGeJTrP5yQUATJ5X4OaOQe0qt1F/kU6sxfUO4c7VBQ0930TGQ YE8tL3vTPDVlyWW2peH25MbvLI5trcjOIJotQ2sQGV6cjPkplYy3hWYPde2T2X/PWLS3 mLpCxDBX5Qc32mKYDWXBIn30vAni2SBpoXGy9Kydsn6mYIrgSURb6auks/Oe8gkmuCeA 0g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgwrj1m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 22:08:02 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0NM6Exp021072; Tue, 23 Jan 2018 17:08:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ek5g0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 17:08:01 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 Jan 2018 17:08:00 -0500 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; Tue, 23 Jan 2018 17:08:00 -0500 From: "Lubashev, Igor" To: Roberto Peon , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: RE: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYA= Date: Tue, 23 Jan 2018 22:07:59 +0000 Message-ID: <5086f27b81f74a1cad90555d25c227b3@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.38.42] Content-Type: multipart/alternative; boundary="_000_5086f27b81f74a1cad90555d25c227b3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230286 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230286 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 22:08:11 -0000 --_000_5086f27b81f74a1cad90555d25c227b3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgVGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3VsZCBuZWVkIHRvIGJlIGV4cHJlc3NlZCBh cyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMgdGhlIHJhY2VzIGFuZCBhbGxvd3MgdGhl IG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0byB3b3JrIHByb3Blcmx5KS4gSSBzdXNwZWN0IHRo aXMgaXMgd2hhdCB5b3UgbWVhbiBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNClllcywgdGhlIHN0cmVh bS1kYXRhLWNyZWRpdCBpbiB0aGlzIHByb3Bvc2FsIGlzIGV4cHJlc3NlZCBpbiBldmVyLWluY3Jl YXNpbmcgb2Zmc2V0cy4NCg0KDQogICogICBPdGhlcndpc2UsIGxvb2tzIGdvb2QuIFRoaXMgd291 bGQgZmFsbCB1bmRlciB0aGUg4oCYYWxsb3cgbW9yZSBidWZmZXJpbmcgYXQgdGhlIGFwcGxpY2F0 aW9u4oCZIGJ1bGxldCBNYXJ0aW4gaGFkLCBidXQgSSBiZWxpZXZlIHRoYXQgaXMgYSByZWFzb25h YmxlIHRoaW5nIHRvIGRvIGlmIGl0IGlzIGNvbnN0cmFpbmVkIGFuZCBkaXJlY3RlZCBieSB0aGUg YXBwbGljYXRpb24gKHdoaWNoIGNvdWxkIGRlY2lkZSB0byBjYW5jZWwgYSBzdHJlYW0gdG9vKS4N CiAgKiAgIFNpbmNlIGZsb3cgY29udHJvbCBpcyBlMmUsIHRoaXMgZG9lc27igJl0IGltcGFjdCBt ZW1vcnkgYXQgYSBwcm94eS4NCg0KRXhhY3RseQ0KDQoNCiAgKiAgIFdoYXQgdGhpcyBkb2VzbuKA mXQgc29sdmUgaXMgdGhlIGRldGVjdGlvbiBwcm9ibGVtLg0KDQpJZiB5b3UgbG9vayBhdCBteSBm b2xsb3ctdXAgcHJvcG9zYWwgKHdoaWNoIGlzIGVmZmVjdGl2ZWx5IGNoYW5naW5nIHRoZSBtZWFu aW5nIG9mIG1heF9zdHJlYW1fZGF0YSB0byBtZWFuIHN0cmVhbV9kYXRhX2NyZWRpdCksIHlvdSBt YXkgbm90IG5lZWQgdG8gaGF2ZSByb2J1c3QgZGVhZGxvY2sgZGV0ZWN0aW9uLCBiZWNhdXNlIGRl YWRsb2NrcyBkdWUgdG8gdHJhbnNwb3J0IGNhbm5vdCBoYXBwZW4uICBUaGUgb25seSBkZWFkbG9j a3MgcG9zc2libGUgd2l0aCB0aGUgZm9sbG93LXVwIHNjaGVtZSBhcmUgZGVhZGxvY2tzIGR1ZSB0 byB0aGUgYXBwbGljYXRpb27igJlzIGNpcmN1bGFyIGRlcGVuZGVuY3ksIG5vdCBzZW5kZXLigJlz IGNob2ljZSBvZiB3aGljaCBzdHJlYW0gdG8gc2VuZCBmaXJzdA0KDQotPVINCg0KDQpGcm9tOiBR VUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+ IG9uIGJlaGFsZiBvZiAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0 bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEphbnVhcnkgMjMsIDIwMTgg YXQgMjo1MCBQTQ0KVG86ICJxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPiIgPHF1 aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PiwgImlnb3Jsb3JkQGFsdW0ubWl0LmVk dTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1PiIgPGlnb3Jsb3JkQGFsdW0ubWl0LmVkdTxt YWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1Pj4NClN1YmplY3Q6IERlYWRsb2NrIGF2b2lkYW5j ZSBwcm9wb3NhbA0KDQpUaGUgcHJvYmxlbSB3aXRoIGRlYWRsb2NraW5nIFFVSUMgc3RyZWFtcyBp cyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc2VuZGVyIChvciBwcm94eSkgd2lsbCDigJx1c2Ug dXDigJ0gY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgY3JlZGl0cyBvbiBsb3dlci1wcmlvcml0eSBz dHJlYW1zLCBibG9ja2luZyB0aGUgcmVjZWl2ZXIgZnJvbSBtYWtpbmcgZm9yd2FyZCBwcm9ncmVz cyB3aXRoIGFueSBzdHJlYW1zLiAgVGhlIHJlY2VpdmVyIGhhcyBubyBtZWNoYW5pc20gdG8gZGly ZWN0L2ZvcmNlIHRoZSBzZW5kZXIgdG8gc2VuZCBvbiBwcmVmZXJyZWQgc3RyZWFtcy4NCg0KSSB3 b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBjb25jZXB0IG9mIOKAnHN0cmVhbSBkYXRhIGNyZWRpdOKA nSDigJMgdGhlIGNvbmNlcHQgb2YgZXh0cmEgZmxvdyBjb250cm9sIGNyZWRpdHMgdGhhdCBjYW4g b25seSBiZSB1c2VkIGJ5IGEgc3BlY2lmaWMgc3RyZWFtLiAgQSBTVFJFQU1fREFUQV9DUkVESVQg ZnJhbWUgd291bGQgdXBkYXRlIHN1Y2ggY3JlZGl0cyAoc2VlIGJlbG93KS4gIERhdGEgc2VudCBv biBhIHN0cmVhbSB3aWxsIGNvbnN1bWUgaXRzIG93biBjcmVkaXRzIGFzIG11Y2ggYXMgaXQgY2Fu IGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVwZGF0ZWQgYnkgTUFYX0RBVEEpIGZvciB0aGUgcmVz dCBvZiB0aGUgZGF0YS4NCg0KVGhlIHVwZGF0ZWQgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgYWNj b3VudGluZzoNCg0K4oCcDQpGb3IgZWFjaCBzdHJlYW0sIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVk aXRz4oCdIGlzIOKAnE1BWCh0aGVfbGFyZ2VzdF9yZWNlaXZlZF9vZmZzZXQgLSBzdHJlYW1fZGF0 YV9jcmVkaXRzLCAwKeKAnS4NCg0KVGhlIHN1bSBvZiDigJx1c2VkIGNvbm5lY3Rpb24gY3JlZGl0 c+KAnSBvbiBhbGwgc3RyZWFtcyAtDQppbmNsdWRpbmcgc3RyZWFtcyBpbiB0ZXJtaW5hbCBzdGF0 ZXMsIGJ1dCBleGNsdWRpbmcgc3RyZWFtIDAgLSBNVVNUIE5PVCBleGNlZWQNCnRoZSB2YWx1ZSBh ZHZlcnRpc2VkIGJ5IGEgcmVjZWl2ZXIgKGkuZS4gTUFYX0RBVEEpLiAgQW4gZW5kcG9pbnQgTVVT VCB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uDQp3aXRoIGEgUVVJQ19GTE9XX0NPTlRST0xfUkVDRUlW RURfVE9PX01VQ0hfREFUQSBlcnJvciBpZiBpdCB1c2VkIG1vcmUgY29ubmVjdGlvbiBjcmVkaXRz DQp0aGFuIHRoZSBtYXhpbXVtIGRhdGEgdmFsdWUgdGhhdCBpdCBoYXMgc2VudCwgdW5sZXNzIHRo aXMgaXMgYSByZXN1bHQgb2YgYQ0KY2hhbmdlIGluIHRoZSBpbml0aWFsIGxpbWl0cyAoc2VlIHt7 emVyb3J0dC1wYXJhbWV0ZXJzfX0pLg0K4oCcDQoNClRoZSByZWNlaXZlciB3aWxsIGJlIGFibGUg dG8gZ3JhbnQgZGVkaWNhdGVkIGNyZWRpdHMgdG8gdGhlIGhpZ2gtcHJpb3JpdHkgc3RyZWFtIHcv byByZXF1aXJpbmcgdGhlIHNlbmRlciBvciB0aGUgaW50ZXJtZWRpYXJ5IHRvIGtub3cgYW55dGhp bmcgYWJvdXQgdGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2wgYW5kIHdpdGhvdXQgd29ycnlp bmcgdGhhdCB0aGUgc2VuZGVyL2ludGVybWVkaWFyeSB3aWxsIOKAnHNxdWFuZGVy4oCdIHRoZSBj cmVkaXRzIG9uIHVuaW1wb3J0YW50IHN0cmVhbXMuDQoNCg0KPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K U1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lLg0KDQpUaGUgZnJhbWUgdXBkYXRlcyBEYXRhIENyZWRp dCBmb3IgYSBzdHJlYW0uDQoNCn5+fg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAg ICAgICAgICAgICAgICAgIFN0cmVhbSBJRCAoaSkgICAgICAgICAgICAgICAgICAgICAgICAuLi4N CistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAgRGF0YSBDcmVkaXQgKGkpICAgICAg ICAgICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0Kfn5+DQoNClRoZSBmaWVsZHMgaW4gdGhl IFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSBhcmUgYXMgZm9sbG93czoNCg0KU3RyZWFtIElEOg0K DQo6IFRoZSBzdHJlYW0gSUQgb2YgdGhlIHN0cmVhbSB0aGF0IGlzIGFmZmVjdGVkIGVuY29kZWQg YXMgYSB2YXJpYWJsZS1sZW5ndGgNCiAgaW50ZWdlci4NCg0KRGF0YSBDcmVkaXQ6DQoNCjogQSB2 YXJpYWJsZS1sZW5ndGggaW50ZWdlciBpbmRpY2F0aW5nIHRoZSBuZXcgdG90YWwgZGF0YSBjcmVk aXQgZm9yIHRoZSBzdHJlYW0uDQoNCkZvciBlYWNoIHN0cmVhbSBEYXRhIENyZWRpdCBzdGFydHMg d2l0aCAwLiAgVGhlIHNlbmRlciBjYW4gb25seSBpbmNyZWFzZSBEYXRhIENyZWRpdCBpbiBzdWJz ZXF1ZW50IFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMgZm9yIHRoZSBzYW1lIHN0cmVhbSwgYnV0 IGxvc3MgYW5kIHJlb3JkZXJpbmcgY2FuIGNhdXNlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMg dG8gYmUgcmVjZWl2ZWQgb3V0IG9mIG9yZGVyLiAgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyB0 aGF0IGRvIG5vdCBhZHZhbmNlIERhdGEgQ3JlZGl0IGZvciB0aGUgc3RyZWFtIE1VU1QgYmUgaWdu b3JlZC4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQpDb21tZW50cz8NCg0KDQogICogICBJZ29y DQo= --_000_5086f27b81f74a1cad90555d25c227b3usma1exdag1mb5msgcorpak_ 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 b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEwMjMzNTcz OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NzcxODE2 MDQwIC0xNjgxNzI1MDA0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTUzNTg1MTg2 MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTg4OTg0MDk1NDt9DQpAbGlzdCBsMTpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjE5NTgyMjA5MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi0zMTUzMzM4MTYgMjU3NDg2MjQyIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMjps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMiBsZXZlbDEgbGZvNCI+VGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3VsZCBuZWVk IHRvIGJlIGV4cHJlc3NlZCBhcyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMgdGhlIHJh Y2VzIGFuZCBhbGxvd3MgdGhlIG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0byB3b3JrIHByb3Bl cmx5KS4gSSBzdXNwZWN0IHRoaXMgaXMgd2hhdCB5b3UNCiBtZWFuIGluIHRoZSBmaXJzdCBwbGFj ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGUgc3RyZWFtLWRhdGEtY3Jl ZGl0IGluIHRoaXMgcHJvcG9zYWwgaXMgZXhwcmVzc2VkIGluIGV2ZXItaW5jcmVhc2luZyBvZmZz ZXRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNCI+T3RoZXJ3aXNlLCBsb29rcyBnb29kLiBUaGlzIHdvdWxkIGZhbGwgdW5kZXIg dGhlIOKAmGFsbG93IG1vcmUgYnVmZmVyaW5nIGF0IHRoZSBhcHBsaWNhdGlvbuKAmSBidWxsZXQg TWFydGluIGhhZCwgYnV0IEkgYmVsaWV2ZSB0aGF0IGlzIGEgcmVhc29uYWJsZSB0aGluZyB0byBk byBpZiBpdCBpcyBjb25zdHJhaW5lZCBhbmQNCiBkaXJlY3RlZCBieSB0aGUgYXBwbGljYXRpb24g KHdoaWNoIGNvdWxkIGRlY2lkZSB0byBjYW5jZWwgYSBzdHJlYW0gdG9vKS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwyIGxldmVsMSBsZm80Ij5TaW5jZSBmbG93IGNvbnRyb2wgaXMgZTJlLCB0aGlzIGRv ZXNu4oCZdCBpbXBhY3QgbWVtb3J5IGF0IGEgcHJveHkuPG86cD48L286cD48L2xpPjwvdWw+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkV4YWN0bHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+ DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDIgbGV2ZWwxIGxmbzQiPldoYXQgdGhpcyBkb2VzbuKAmXQgc29sdmUgaXMgdGhlIGRl dGVjdGlvbiBwcm9ibGVtLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgbG9v ayBhdCBteSBmb2xsb3ctdXAgcHJvcG9zYWwgKHdoaWNoIGlzIGVmZmVjdGl2ZWx5IGNoYW5naW5n IHRoZSBtZWFuaW5nIG9mIG1heF9zdHJlYW1fZGF0YSB0byBtZWFuIHN0cmVhbV9kYXRhX2NyZWRp dCksIHlvdSBtYXkgbm90IG5lZWQgdG8gaGF2ZSByb2J1c3QgZGVhZGxvY2sgZGV0ZWN0aW9uLCBi ZWNhdXNlIGRlYWRsb2NrcyBkdWUgdG8gdHJhbnNwb3J0IGNhbm5vdCBoYXBwZW4uJm5ic3A7IFRo ZSBvbmx5DQogZGVhZGxvY2tzIHBvc3NpYmxlIHdpdGggdGhlIGZvbGxvdy11cCBzY2hlbWUgYXJl IGRlYWRsb2NrcyBkdWUgdG8gdGhlIGFwcGxpY2F0aW9u4oCZcyBjaXJjdWxhciBkZXBlbmRlbmN5 LCBub3Qgc2VuZGVy4oCZcyBjaG9pY2Ugb2Ygd2hpY2ggc3RyZWFtIHRvIHNlbmQgZmlyc3Q8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi09UjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0Ozxh IGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDI6NTAg UE08YnI+DQo8Yj5UbzogPC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5x dWljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmci PnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlnb3Jsb3JkQGFs dW0ubWl0LmVkdSI+aWdvcmxvcmRAYWx1bS5taXQuZWR1PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdSI+aWdvcmxvcmRAYWx1bS5taXQuZWR1PC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+RGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bvc2FsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9i bGVtIHdpdGggZGVhZGxvY2tpbmcgUVVJQyBzdHJlYW1zIGlzIHRoZSBwb3NzaWJpbGl0eSB0aGF0 IHRoZSBzZW5kZXIgKG9yIHByb3h5KSB3aWxsIOKAnHVzZSB1cOKAnSBjb25uZWN0aW9uIGZsb3cg Y29udHJvbCBjcmVkaXRzIG9uIGxvd2VyLXByaW9yaXR5IHN0cmVhbXMsIGJsb2NraW5nIHRoZSBy ZWNlaXZlciBmcm9tIG1ha2luZyBmb3J3YXJkIHByb2dyZXNzIHdpdGggYW55IHN0cmVhbXMuJm5i c3A7IFRoZSByZWNlaXZlcg0KIGhhcyBubyBtZWNoYW5pc20gdG8gZGlyZWN0L2ZvcmNlIHRoZSBz ZW5kZXIgdG8gc2VuZCBvbiBwcmVmZXJyZWQgc3RyZWFtcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBjb25jZXB0IG9mIOKAnHN0cmVhbSBkYXRhIGNy ZWRpdOKAnSDigJMgdGhlIGNvbmNlcHQgb2YgZXh0cmEgZmxvdyBjb250cm9sIGNyZWRpdHMgdGhh dCBjYW4gb25seSBiZSB1c2VkIGJ5IGEgc3BlY2lmaWMgc3RyZWFtLiZuYnNwOyBBIFNUUkVBTV9E QVRBX0NSRURJVCBmcmFtZSB3b3VsZCB1cGRhdGUgc3VjaCBjcmVkaXRzIChzZWUgYmVsb3cpLiZu YnNwOyBEYXRhIHNlbnQgb24gYSBzdHJlYW0NCiB3aWxsIGNvbnN1bWUgaXRzIG93biBjcmVkaXRz IGFzIG11Y2ggYXMgaXQgY2FuIGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVwZGF0ZWQgYnkgTUFY X0RBVEEpIGZvciB0aGUgcmVzdCBvZiB0aGUgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHVwZGF0ZWQgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgYWNjb3VudGluZzombmJzcDsgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIGVhY2ggc3RyZWFtLCDigJx1c2VkIGNvbm5lY3Rpb24gY3JlZGl0c+KAnSBpcyDi gJxNQVgodGhlX2xhcmdlc3RfcmVjZWl2ZWRfb2Zmc2V0IC0gc3RyZWFtX2RhdGFfY3JlZGl0cywg MCnigJ0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzdW0gb2Yg4oCcdXNlZCBjb25uZWN0 aW9uIGNyZWRpdHPigJ0gb24gYWxsIHN0cmVhbXMgLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aW5jbHVkaW5nIHN0cmVhbXMgaW4gdGVybWluYWwgc3RhdGVzLCBidXQgZXhj bHVkaW5nIHN0cmVhbSAwIC0gTVVTVCBOT1QgZXhjZWVkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj50aGUgdmFsdWUgYWR2ZXJ0aXNlZCBieSBhIHJlY2VpdmVyIChpLmUuIE1B WF9EQVRBKS4mbmJzcDsgQW4gZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoIGEgUVVJQ19GTE9XX0NPTlRS T0xfUkVDRUlWRURfVE9PX01VQ0hfREFUQSBlcnJvciBpZiBpdCB1c2VkIG1vcmUgY29ubmVjdGlv biBjcmVkaXRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuIHRoZSBt YXhpbXVtIGRhdGEgdmFsdWUgdGhhdCBpdCBoYXMgc2VudCwgdW5sZXNzIHRoaXMgaXMgYSByZXN1 bHQgb2YgYTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hhbmdlIGluIHRo ZSBpbml0aWFsIGxpbWl0cyAoc2VlIHt7emVyb3J0dC1wYXJhbWV0ZXJzfX0pLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSByZWNlaXZlciB3aWxsIGJlIGFibGUgdG8gZ3JhbnQgZGVkaWNhdGVkIGNyZWRpdHMgdG8gdGhl IGhpZ2gtcHJpb3JpdHkgc3RyZWFtIHcvbyByZXF1aXJpbmcgdGhlIHNlbmRlciBvciB0aGUgaW50 ZXJtZWRpYXJ5IHRvIGtub3cgYW55dGhpbmcgYWJvdXQgdGhlIHNlbWFudGljcyBvZiB0aGUgcHJv dG9jb2wgYW5kIHdpdGhvdXQgd29ycnlpbmcgdGhhdCB0aGUgc2VuZGVyL2ludGVybWVkaWFyeSB3 aWxsIOKAnHNxdWFuZGVy4oCdDQogdGhlIGNyZWRpdHMgb24gdW5pbXBvcnRhbnQgc3RyZWFtcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TVFJF QU1fREFUQV9DUkVESVQgZnJhbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmcmFtZSB1 cGRhdGVzIERhdGEgQ3JlZGl0IGZvciBhIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ fn5+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj58Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN0cmVhbSBJRCAoaSkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRhIENyZWRpdCAoaSkmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+fn5+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmaWVsZHMgaW4gdGhlIFNUUkVBTV9E QVRBX0NSRURJVCBmcmFtZSBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U3RyZWFtIElEOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj46IFRoZSBzdHJlYW0gSUQgb2YgdGhl IHN0cmVhbSB0aGF0IGlzIGFmZmVjdGVkIGVuY29kZWQgYXMgYSB2YXJpYWJsZS1sZW5ndGg8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbnRlZ2VyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5EYXRhIENyZWRpdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OiBB IHZhcmlhYmxlLWxlbmd0aCBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIG5ldyB0b3RhbCBkYXRhIGNy ZWRpdCBmb3IgdGhlIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGVhY2ggc3Ry ZWFtIERhdGEgQ3JlZGl0IHN0YXJ0cyB3aXRoIDAuJm5ic3A7IFRoZSBzZW5kZXIgY2FuIG9ubHkg aW5jcmVhc2UgRGF0YSBDcmVkaXQgaW4gc3Vic2VxdWVudCBTVFJFQU1fREFUQV9DUkVESVQgZnJh bWVzIGZvciB0aGUgc2FtZSBzdHJlYW0sIGJ1dCBsb3NzIGFuZCByZW9yZGVyaW5nIGNhbiBjYXVz ZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIHRvIGJlIHJlY2VpdmVkIG91dCBvZiBvcmRlci4m bmJzcDsNCiBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIHRoYXQgZG8gbm90IGFkdmFuY2UgRGF0 YSBDcmVkaXQgZm9yIHRoZSBzdHJlYW0gTVVTVCBiZSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5086f27b81f74a1cad90555d25c227b3usma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 14:59:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407D212D883 for ; Tue, 23 Jan 2018 14:59:23 -0800 (PST) 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 27UqzPUr_Y0i for ; Tue, 23 Jan 2018 14:59:21 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 8DB6912D876 for ; Tue, 23 Jan 2018 14:59:21 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id p83so838822yba.4 for ; Tue, 23 Jan 2018 14:59:21 -0800 (PST) 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=Doilp76oef++LznwnJHbQd7nmuJw1iBC17BC/ERQZk4=; b=oaikkZ0GeNFbQsJqEisUdGO7gXiiHsg3PDzhHQ3ZQkddHJs7KGMxKfJL6n1c+Cw7ay zd5aUE7o+73EWSN7W10LXvCIlgvRZ4GH/n78QQDXArgX76uKMVV6oNcP+yByN3YcZjDc Iw7vU5Yj1EIlKR7jGB2aOfvGmPBOxT8+DbxtX7pzIfYRscP9SMXUXXFr/9pqzRNZgL1d fD7C+H16JUWIIikPP5wh9rzmAUvS4d0sQOgOEtdja2NF2rBl8pblLlsxR2CPqeIsZFwr ylf78TudZuuRQFt7zbesdqa45VkG4DitNRaDzuOJVnxHunDGn8WChcZGI0ZRXSGjoOHx hUJQ== 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=Doilp76oef++LznwnJHbQd7nmuJw1iBC17BC/ERQZk4=; b=dF0H2z0WPKb8wqzb/UOlfpwhJM8UvdUmfwKTDk2Qi01JiCEKG42DfpsMi95hybPyzD uyDw4uQbQPgVRIqTMMoFimnPgMUUAykPHEdW/D7H6MEYlkKCcv80EWicWth3DGwrzhqT NXKho5aXEhPDzA+7Pz6cm+Cj+4d1LPBywsUnTQVRaYKbHOyZqfWVsLXUbvCecXFber/7 uzzjVP+Bz1RzM+NJQhy8OIvsw0w8R5OzriX4oAa8PtPkDxGpMsegCs2FNpSQiB2FvWZx +qQ6/qceDNntQjHhsQsktUspxuJd9AXDVKQlGqY/7h3mgdfXO7iWfA7KMoOZ+93FC36d 0kyw== X-Gm-Message-State: AKwxytdPXQQe1CP/59xWHXcjMQaztzPWvJryUJuHqhER6UBbX/M4Es8q 916kAP6zUmzhn4SX41oT139IDZMDf9Ow5C/HOKA= X-Google-Smtp-Source: AH8x224qNLykwhYceWmhHZrfqhZe9g30fjSCNK76z2+I3GObiNp2x2VAjcfm8pkHNkp/jMhtJ/zDLE7I+HKoIacoHEc= X-Received: by 10.37.133.69 with SMTP id f5mr4096769ybn.54.1516748360562; Tue, 23 Jan 2018 14:59:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Tue, 23 Jan 2018 14:59:19 -0800 (PST) Received: by 10.37.20.4 with HTTP; Tue, 23 Jan 2018 14:59:19 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 23 Jan 2018 16:59:19 -0600 Message-ID: Subject: Re: So how critical is header compression? To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08250e883ebcc90563797f35" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 22:59:23 -0000 --089e08250e883ebcc90563797f35 Content-Type: text/plain; charset="UTF-8" Hi, Martin, On Jan 22, 2018 23:43, "Martin Thomson" wrote: Buck tells me that header compression is critical: they can't deploy QUIC without it and that 30% (what we get now) is still completely unacceptable. That doesn't answer the question I asked, but it does answer what my next question would have been ;-) Thanks for reading my mind! Spencer This is probably a moot point given the decision today. I think that we have a plan. On Tue, Jan 23, 2018 at 3:32 PM, Spencer Dawkins at IETF wrote: > If I understood correctly (and this is my most accessible remote meeting > ever, so I have hopes), there was a tension in today's meeting between not > wanting to make a premature choice on header compression, and not wanting > to have header compression make meeting the current milestone dates in > QUICv1 harder than that needs to be. > > Was that about right? > > Spencer --089e08250e883ebcc90563797f35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi, Martin,

    On Jan 22, 2018 23:43, "Martin Thomson" <= martin.thomson@gmail.com>= ; wrote:
    Buck tells me tha= t header compression is critical: they can't deploy
    QUIC without it and that 30% (what we get now) is still completely
    unacceptable.

    That doesn't answer the question I asked, but it doe= s answer what my next question would have been ;-)
    <= br>
    Thanks for reading my mind!

    Spencer

    This is probably a moot point given the decision today.= =C2=A0 I think that
    we have a plan.

    On Tue, Jan 23, 2018 at 3:32 PM, Spencer Dawkins at IETF
    <spencerdawkins.ietf@gm= ail.com> wrote:
    > If I understood correctly (and this is my most accessible remote meeti= ng
    > ever, so I have hopes), there was a tension in today's meeting bet= ween not
    > wanting to make a premature choice on header compression,=C2=A0 and no= t wanting
    > to have header compression make meeting the current milestone dates in=
    > QUICv1 harder than that needs to be.
    >
    > Was that about right?
    >
    > Spencer

    --089e08250e883ebcc90563797f35-- From nobody Tue Jan 23 15:12:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983D712D941 for ; Tue, 23 Jan 2018 15:12:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.281 X-Spam-Level: ** X-Spam-Status: No, score=2.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KRoSG8lX; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=AfyHSecf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9lIlBdDqboYZ for ; Tue, 23 Jan 2018 15:12:52 -0800 (PST) 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 2B4B712D88E for ; Tue, 23 Jan 2018 15:12:52 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NMtMwC032159; Tue, 23 Jan 2018 14:56:19 -0800 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=hbJuwCUZU6RvG8gayVLrFGgFxuuT+OQ0MJMXBHqBvOo=; b=KRoSG8lXraRF6P+fM23NLgMQqtG9Vd+wCnsU1T1yuGNhfTpB7o+2ZbLAeyCD3HnttKrg d3iuFx1c/ouceORl3jWgkEUrQeTcjfJBOVH2IKaRl1t3sAb5j1mv5Sh86VyQGRsB0Xcr EHhhlwebsb6HZEi4TPN6mg8nBjOdD8LXZOY= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fpb9krn3q-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 14:56:19 -0800 Received: from NAM02-CY1-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.361.1; Tue, 23 Jan 2018 17:56:17 -0500 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=hbJuwCUZU6RvG8gayVLrFGgFxuuT+OQ0MJMXBHqBvOo=; b=AfyHSecf9EXH7BEDMhzEL4ejULln5zsaeMGrKGfgJd2Kh6BLeRBBZbqjl24jTPXOkrQbGGOUx0CnCOfMd91yIJJ7+KTW12RLy2mzZZlTiJuC3WG0UF1wGBTmbqjWkKSSt5iyj3K8hz67JdJwwnyDoZNGNvnYf+8bAJ1553sRxa4= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.18; Tue, 23 Jan 2018 22:56:15 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Tue, 23 Jan 2018 22:56:15 +0000 From: Roberto Peon To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Re: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAAZnH4gACbQhIA= Date: Tue, 23 Jan 2018 22:56:15 +0000 Message-ID: References: <432ca45e129d488a859a3c0123ad8571@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <432ca45e129d488a859a3c0123ad8571@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2183; 7:MmD1IBIYMyJ6NsKMvfuHsZxoMJlDgiT9J+Iq+GqQRzQ9NyxKpBr/gOkdN0ZOuzZv2cSc8IDYDFiBZ3JDO+D3VEVLSVh8YO2x0vYsds6y7HzUthFsho7PtTgCIlQztgzhqYutIddFHGXrT6STHfe4SBjrS1h1K9DnTyrg6pkgfCrP2B4HMWIDeqlwowgfuU6uPhzXsMtEjsFuwWNv2qHiCAb49KxFwCq6xkhslWk1mA7DLd5r0Brcra7KwzEOCnPH; 20:El24w1lacqR4CCKwBXTu0Rr1xvdzj4YYVCb28gNQQvKajir5+3HpOuLM67PHEc5BjIREVeVrbc7R8rzeL4X2t7C+ZYYqEgFr9twf63HD95Tg/5OeDmb8Qyr+FR0OrWAkwEBOc8BwI9dlPTjAhg6c+H5WYBBouEaTWPHstpBC4Wc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1f88fa37-4ea9-4e09-650f-08d562b481f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2183; x-ms-traffictypediagnostic: DM5PR1501MB2183: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231023)(11241501184)(2400081)(944501161)(3002001)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR1501MB2183; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2183; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(376002)(346002)(39860400002)(366004)(189003)(199004)(106356001)(86362001)(5660300001)(26005)(97736004)(5250100002)(54896002)(2950100002)(83716003)(7736002)(6306002)(6246003)(3280700002)(6512007)(2900100001)(25786009)(102836004)(7116003)(2201001)(14454004)(76176011)(53546011)(59450400001)(6506007)(66066001)(478600001)(53936002)(2171002)(316002)(33656002)(36756003)(229853002)(551984002)(8936002)(3480700004)(99286004)(6116002)(110136005)(81156014)(81166006)(3660700001)(68736007)(6486002)(561944003)(82746002)(8676002)(2501003)(2906002)(6436002)(3846002)(105586002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2183; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: sCLCaV7AdSPcv88OImS7RCRHtyOtTWkEtIcv7P+Xlb57uaqOB8v/q69SpOliq8oURKZuPYZgbG39owD21Sb/aw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BAA95A8BDF644F96B114D7F57EB0B7FEfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1f88fa37-4ea9-4e09-650f-08d562b481f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 22:56:15.5103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2183 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 23:12:54 -0000 --_000_BAA95A8BDF644F96B114D7F57EB0B7FEfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBuZWVkIG5vdCBiZSBwcm90b2NvbC12aXNpYmxlIHNvIGxvbmcgYXMgdGhlIGZsb3ctY29u dHJvbC1vdmVycmlkZS9zdHJlYW0tZGF0YS1jcmVkaXQgZXhpc3Rz4oCUaW5zdGVhZCwgdGhpcyBp cyBhbiBpbXBsZW1lbnRhdGlvbiBzdHJhdGVneS4NCi09Ug0KDQoNCkZyb206IFFVSUMgPHF1aWMt Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mICJMdWJhc2hldiwgSWdvciIgPGlsdWJhc2hl QGFrYW1haS5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTggYXQgNDoyOCBB TQ0KVG86ICJMdWJhc2hldiwgSWdvciIgPGlsdWJhc2hlQGFrYW1haS5jb20+LCAicXVpY0BpZXRm Lm9yZyIgPHF1aWNAaWV0Zi5vcmc+LCAiaWdvcmxvcmRAYWx1bS5taXQuZWR1IiA8aWdvcmxvcmRA YWx1bS5taXQuZWR1Pg0KU3ViamVjdDogUkU6IERlYWRsb2NrIGF2b2lkYW5jZSBwcm9wb3NhbA0K DQpJIHRoaW5rIG9uZSBjYW4gdGFrZSB0aGlzIGlkZWEgb25lIHN0ZXAgZnVydGhlci4NCg0KUmln aHQgbm93LCBmbG93IGNvbnRyb2wgb24gYSBzdHJlYW0gaXMgbGltaXRpbmcgc3RyZWFtX2RhdGFf b2Zmc2V0IHRvDQogIE1JTihzdHJlYW1fbWF4X2RhdGEsIGNvbm5lY3Rpb25fbWF4X2RhdGEgLSBT VU0oc3RyZWFtX2RhdGFfb2Zmc2V0KSkNCg0KVGhlIG5ldyBhbHRlcm5hdGl2ZSB3b3VsZCBiZSBs aW1pdGluZyBzdHJlYW1fZGF0YV9vZmZzZXQgdG8NCiAgTUFYKHN0cmVhbV9tYXhfZGF0YSwgY29u bmVjdGlvbl9tYXhfZGF0YSAtIFNVTShzdHJlYW1fZGF0YV9vZmZzZXQpKQ0KDQoNCkEgc2ltcGxl IHdheSB0aGlzIHdvdWxkIHdvcmsgaXMgdGhhdCB0aGUgcmVjZWl2ZXIgd291bGQgZGVzaWduYXRl LCBzYXksIDc1JSBvZiBjb25uZWN0aW9uIGJ1ZmZlciBzcGFjZSB0byB0aGUg4oCcY29tbW9u4oCd IGNvbm5lY3Rpb24gcG9vbCAoYW5kIHRyeSB0byBrZWVwIGl0IGF0IHRoYXQgbGV2ZWwgdmlhIE1B WF9EQVRBIGZyYW1lcykgYW5kIDI1JSBvZiB0aGUgYnVmZmVyIHNwYWNlIOKAkyB0byBwZXItc3Ry ZWFtcyBidWZmZXJzLiAgVGhhdCB3YXksIG5vIHN0cmVhbSBjYW4gYmUgc3RhcnZlZCBqdXN0IGJl Y2F1c2UgdGhlIHNlbmRlciBoYXMgY2hvc2VuIHRvIHNlbmQgZGF0YSBvbiBzb21lIG90aGVyIHN0 cmVhbSBlYXJsaWVyLiAgSW4gdGhpcyBzY2hlbWUsIHRoZSB0b3RhbF9idWZmZXJfc3BhY2UsIHBl cl9zdHJlYW1fYnVmZmVyX3NpemUsIG1heF9jb25jdXJyZW50X3N0cmVhbXMgY2FuIGRldGVybWlu ZSBjb21tbl9idWZmZXJfc2l6ZS4gICBBbiBhbHRlcm5hdGl2ZSB3YXkgdG8gbWFuYWdlIHNwYWNl IHdvdWxkIGJlIHJlc2VydmluZyBzb21lIHBlci1zdHJlYW0gYnVmZmVycyBvbmx5IGZvciDigJxo aWdoLXByaW9yaXR54oCdIHN0cmVhbXMgdGhhdCBjYW5ub3QgYmUgYmxvY2tlZCDigJMgdGhlIHNj aGVtZSB0byB1c2UgY291bGQgYmUgYW4gYXBwbGljYXRpb27igJlzIGRlY2lzaW9uLg0KDQoNCiAg KiAgIElnb3INCg0KRnJvbTogTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWku Y29tXQ0KU2VudDogTW9uZGF5LCBKYW51YXJ5IDIyLCAyMDE4IDEwOjUwIFBNDQpUbzogcXVpY0Bp ZXRmLm9yZzsgaWdvcmxvcmRAYWx1bS5taXQuZWR1DQpTdWJqZWN0OiBEZWFkbG9jayBhdm9pZGFu Y2UgcHJvcG9zYWwNCg0KVGhlIHByb2JsZW0gd2l0aCBkZWFkbG9ja2luZyBRVUlDIHN0cmVhbXMg aXMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIHNlbmRlciAob3IgcHJveHkpIHdpbGwg4oCcdXNl IHVw4oCdIGNvbm5lY3Rpb24gZmxvdyBjb250cm9sIGNyZWRpdHMgb24gbG93ZXItcHJpb3JpdHkg c3RyZWFtcywgYmxvY2tpbmcgdGhlIHJlY2VpdmVyIGZyb20gbWFraW5nIGZvcndhcmQgcHJvZ3Jl c3Mgd2l0aCBhbnkgc3RyZWFtcy4gIFRoZSByZWNlaXZlciBoYXMgbm8gbWVjaGFuaXNtIHRvIGRp cmVjdC9mb3JjZSB0aGUgc2VuZGVyIHRvIHNlbmQgb24gcHJlZmVycmVkIHN0cmVhbXMuDQoNCkkg d291bGQgbGlrZSB0byBwcm9wb3NlIGEgY29uY2VwdCBvZiDigJxzdHJlYW0gZGF0YSBjcmVkaXTi gJ0g4oCTIHRoZSBjb25jZXB0IG9mIGV4dHJhIGZsb3cgY29udHJvbCBjcmVkaXRzIHRoYXQgY2Fu IG9ubHkgYmUgdXNlZCBieSBhIHNwZWNpZmljIHN0cmVhbS4gIEEgU1RSRUFNX0RBVEFfQ1JFRElU IGZyYW1lIHdvdWxkIHVwZGF0ZSBzdWNoIGNyZWRpdHMgKHNlZSBiZWxvdykuICBEYXRhIHNlbnQg b24gYSBzdHJlYW0gd2lsbCBjb25zdW1lIGl0cyBvd24gY3JlZGl0cyBhcyBtdWNoIGFzIGl0IGNh biBhbmQgY29ubmVjdGlvbiBjcmVkaXRzICh1cGRhdGVkIGJ5IE1BWF9EQVRBKSBmb3IgdGhlIHJl c3Qgb2YgdGhlIGRhdGEuDQoNClRoZSB1cGRhdGVkIGNvbm5lY3Rpb24gZmxvdyBjb250cm9sIGFj Y291bnRpbmc6DQoNCuKAnA0KRm9yIGVhY2ggc3RyZWFtLCDigJx1c2VkIGNvbm5lY3Rpb24gY3Jl ZGl0c+KAnSBpcyDigJxNQVgodGhlX2xhcmdlc3RfcmVjZWl2ZWRfb2Zmc2V0IC0gc3RyZWFtX2Rh dGFfY3JlZGl0cywgMCnigJ0uDQoNClRoZSBzdW0gb2Yg4oCcdXNlZCBjb25uZWN0aW9uIGNyZWRp dHPigJ0gb24gYWxsIHN0cmVhbXMgLQ0KaW5jbHVkaW5nIHN0cmVhbXMgaW4gdGVybWluYWwgc3Rh dGVzLCBidXQgZXhjbHVkaW5nIHN0cmVhbSAwIC0gTVVTVCBOT1QgZXhjZWVkDQp0aGUgdmFsdWUg YWR2ZXJ0aXNlZCBieSBhIHJlY2VpdmVyIChpLmUuIE1BWF9EQVRBKS4gIEFuIGVuZHBvaW50IE1V U1QgdGVybWluYXRlIGEgY29ubmVjdGlvbg0Kd2l0aCBhIFFVSUNfRkxPV19DT05UUk9MX1JFQ0VJ VkVEX1RPT19NVUNIX0RBVEEgZXJyb3IgaWYgaXQgdXNlZCBtb3JlIGNvbm5lY3Rpb24gY3JlZGl0 cw0KdGhhbiB0aGUgbWF4aW11bSBkYXRhIHZhbHVlIHRoYXQgaXQgaGFzIHNlbnQsIHVubGVzcyB0 aGlzIGlzIGEgcmVzdWx0IG9mIGENCmNoYW5nZSBpbiB0aGUgaW5pdGlhbCBsaW1pdHMgKHNlZSB7 e3plcm9ydHQtcGFyYW1ldGVyc319KS4NCuKAnA0KDQpUaGUgcmVjZWl2ZXIgd2lsbCBiZSBhYmxl IHRvIGdyYW50IGRlZGljYXRlZCBjcmVkaXRzIHRvIHRoZSBoaWdoLXByaW9yaXR5IHN0cmVhbSB3 L28gcmVxdWlyaW5nIHRoZSBzZW5kZXIgb3IgdGhlIGludGVybWVkaWFyeSB0byBrbm93IGFueXRo aW5nIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sIGFuZCB3aXRob3V0IHdvcnJ5 aW5nIHRoYXQgdGhlIHNlbmRlci9pbnRlcm1lZGlhcnkgd2lsbCDigJxzcXVhbmRlcuKAnSB0aGUg Y3JlZGl0cyBvbiB1bmltcG9ydGFudCBzdHJlYW1zLg0KDQoNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN ClNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZS4NCg0KVGhlIGZyYW1lIHVwZGF0ZXMgRGF0YSBDcmVk aXQgZm9yIGEgc3RyZWFtLg0KDQp+fn4NCjAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAg ICAgICAgICAgICAgICAgICBTdHJlYW0gSUQgKGkpICAgICAgICAgICAgICAgICAgICAgICAgLi4u DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgIERhdGEgQ3JlZGl0IChpKSAgICAg ICAgICAgICAgICAgICAgICAgIC4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCn5+fg0KDQpUaGUgZmllbGRzIGluIHRo ZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgYXJlIGFzIGZvbGxvd3M6DQoNClN0cmVhbSBJRDoN Cg0KOiBUaGUgc3RyZWFtIElEIG9mIHRoZSBzdHJlYW0gdGhhdCBpcyBhZmZlY3RlZCBlbmNvZGVk IGFzIGEgdmFyaWFibGUtbGVuZ3RoDQogIGludGVnZXIuDQoNCkRhdGEgQ3JlZGl0Og0KDQo6IEEg dmFyaWFibGUtbGVuZ3RoIGludGVnZXIgaW5kaWNhdGluZyB0aGUgbmV3IHRvdGFsIGRhdGEgY3Jl ZGl0IGZvciB0aGUgc3RyZWFtLg0KDQpGb3IgZWFjaCBzdHJlYW0gRGF0YSBDcmVkaXQgc3RhcnRz IHdpdGggMC4gIFRoZSBzZW5kZXIgY2FuIG9ubHkgaW5jcmVhc2UgRGF0YSBDcmVkaXQgaW4gc3Vi c2VxdWVudCBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIGZvciB0aGUgc2FtZSBzdHJlYW0sIGJ1 dCBsb3NzIGFuZCByZW9yZGVyaW5nIGNhbiBjYXVzZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVz IHRvIGJlIHJlY2VpdmVkIG91dCBvZiBvcmRlci4gIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMg dGhhdCBkbyBub3QgYWR2YW5jZSBEYXRhIENyZWRpdCBmb3IgdGhlIHN0cmVhbSBNVVNUIGJlIGln bm9yZWQuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KQ29tbWVudHM/DQoNCg0KICAqICAgSWdv cg0KDQo= --_000_BAA95A8BDF644F96B114D7F57EB0B7FEfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <062F16B46A5738439CE6DF3330C24C5E@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo0Mjc4OTI2MDY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi04MTE5ODk4NjA7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMTAy MzM1NzM5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3 NzE4MTYwNDAgLTE2ODE3MjUwMDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJy aTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTps ZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LHNlcmlmO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3Qg bDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0K CXttc28tbGlzdC1pZDoxMzc4NDI3NzU2Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNjQwNjgz MzkyO30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTU1NzY2NzA0ODsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3NDk2MzA2ODIgMTc1 NzU3NTMzOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxp c3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0 RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGlzIG5lZWQgbm90IGJlIHByb3RvY29sLXZpc2libGUgc28gbG9uZyBhcyB0aGUgZmxvdy1jb250 cm9sLW92ZXJyaWRlL3N0cmVhbS1kYXRhLWNyZWRpdCBleGlzdHPigJRpbnN0ZWFkLCB0aGlzIGlz IGFuIGltcGxlbWVudGF0aW9uIHN0cmF0ZWd5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5RVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVv dDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IGF0IDQ6MjggQU08YnI+DQo8 Yj5UbzogPC9iPiZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNoZUBha2FtYWku Y29tJmd0OywgJnF1b3Q7cXVpY0BpZXRmLm9yZyZxdW90OyAmbHQ7cXVpY0BpZXRmLm9yZyZndDss ICZxdW90O2lnb3Jsb3JkQGFsdW0ubWl0LmVkdSZxdW90OyAmbHQ7aWdvcmxvcmRAYWx1bS5taXQu ZWR1Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogRGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bv c2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgdGhpbmsgb25lIGNhbiB0YWtlIHRoaXMgaWRlYSBvbmUgc3RlcCBmdXJ0aGVyLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SaWdodCBub3csIGZsb3cgY29udHJvbCBvbiBhIHN0cmVhbSBpcyBs aW1pdGluZyBzdHJlYW1fZGF0YV9vZmZzZXQgdG88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyBNSU4oc3RyZWFtX21heF9kYXRhLCBjb25uZWN0aW9uX21heF9kYXRh IC0gU1VNKHN0cmVhbV9kYXRhX29mZnNldCkpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBu ZXcgYWx0ZXJuYXRpdmUgd291bGQgYmUgbGltaXRpbmcgc3RyZWFtX2RhdGFfb2Zmc2V0IHRvPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgTUFYKHN0cmVhbV9tYXhf ZGF0YSwgY29ubmVjdGlvbl9tYXhfZGF0YSAtIFNVTShzdHJlYW1fZGF0YV9vZmZzZXQpKTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgc2ltcGxlIHdheSB0aGlzIHdvdWxkIHdvcmsgaXMgdGhhdCB0aGUgcmVjZWl2ZXIg d291bGQgZGVzaWduYXRlLCBzYXksIDc1JSBvZiBjb25uZWN0aW9uIGJ1ZmZlciBzcGFjZSB0byB0 aGUg4oCcY29tbW9u4oCdIGNvbm5lY3Rpb24gcG9vbCAoYW5kIHRyeSB0byBrZWVwIGl0IGF0IHRo YXQgbGV2ZWwgdmlhIE1BWF9EQVRBIGZyYW1lcykgYW5kIDI1JSBvZiB0aGUgYnVmZmVyIHNwYWNl IOKAkyB0byBwZXItc3RyZWFtcyBidWZmZXJzLiZuYnNwOw0KIFRoYXQgd2F5LCBubyBzdHJlYW0g Y2FuIGJlIHN0YXJ2ZWQganVzdCBiZWNhdXNlIHRoZSBzZW5kZXIgaGFzIGNob3NlbiB0byBzZW5k IGRhdGEgb24gc29tZSBvdGhlciBzdHJlYW0gZWFybGllci4mbmJzcDsgSW4gdGhpcyBzY2hlbWUs IHRoZSB0b3RhbF9idWZmZXJfc3BhY2UsIHBlcl9zdHJlYW1fYnVmZmVyX3NpemUsIG1heF9jb25j dXJyZW50X3N0cmVhbXMgY2FuIGRldGVybWluZSBjb21tbl9idWZmZXJfc2l6ZS4mbmJzcDsmbmJz cDsgQW4gYWx0ZXJuYXRpdmUgd2F5IHRvDQogbWFuYWdlIHNwYWNlIHdvdWxkIGJlIHJlc2Vydmlu ZyBzb21lIHBlci1zdHJlYW0gYnVmZmVycyBvbmx5IGZvciDigJxoaWdoLXByaW9yaXR54oCdIHN0 cmVhbXMgdGhhdCBjYW5ub3QgYmUgYmxvY2tlZCDigJMgdGhlIHNjaGVtZSB0byB1c2UgY291bGQg YmUgYW4gYXBwbGljYXRpb27igJlzIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm8zIj5JZ29yPG86cD48L286cD48L2xpPjwvdWw+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g THViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXSA8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBKYW51YXJ5IDIyLCAyMDE4IDEwOjUwIFBNPGJyPg0KPGI+VG86PC9iPiBx dWljQGlldGYub3JnOyBpZ29ybG9yZEBhbHVtLm1pdC5lZHU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g RGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bvc2FsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgcHJvYmxlbSB3aXRoIGRlYWRsb2NraW5nIFFVSUMgc3RyZWFtcyBpcyB0 aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc2VuZGVyIChvciBwcm94eSkgd2lsbCDigJx1c2UgdXDi gJ0gY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgY3JlZGl0cyBvbiBsb3dlci1wcmlvcml0eSBzdHJl YW1zLCBibG9ja2luZyB0aGUgcmVjZWl2ZXIgZnJvbSBtYWtpbmcgZm9yd2FyZCBwcm9ncmVzcyB3 aXRoIGFueSBzdHJlYW1zLiZuYnNwOyBUaGUgcmVjZWl2ZXINCiBoYXMgbm8gbWVjaGFuaXNtIHRv IGRpcmVjdC9mb3JjZSB0aGUgc2VuZGVyIHRvIHNlbmQgb24gcHJlZmVycmVkIHN0cmVhbXMuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0byBwcm9wb3NlIGEgY29uY2VwdCBv ZiDigJxzdHJlYW0gZGF0YSBjcmVkaXTigJ0g4oCTIHRoZSBjb25jZXB0IG9mIGV4dHJhIGZsb3cg Y29udHJvbCBjcmVkaXRzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBieSBhIHNwZWNpZmljIHN0cmVh bS4mbmJzcDsgQSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgd291bGQgdXBkYXRlIHN1Y2ggY3Jl ZGl0cyAoc2VlIGJlbG93KS4mbmJzcDsgRGF0YSBzZW50IG9uIGEgc3RyZWFtDQogd2lsbCBjb25z dW1lIGl0cyBvd24gY3JlZGl0cyBhcyBtdWNoIGFzIGl0IGNhbiBhbmQgY29ubmVjdGlvbiBjcmVk aXRzICh1cGRhdGVkIGJ5IE1BWF9EQVRBKSBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRhdGEuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1cGRhdGVkIGNvbm5lY3Rpb24gZmxvdyBjb250cm9sIGFj Y291bnRpbmc6Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBlYWNoIHN0cmVhbSwg4oCcdXNlZCBjb25uZWN0 aW9uIGNyZWRpdHPigJ0gaXMg4oCcTUFYKHRoZV9sYXJnZXN0X3JlY2VpdmVkX29mZnNldCAtIHN0 cmVhbV9kYXRhX2NyZWRpdHMsIDAp4oCdLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3Vt IG9mIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIG9uIGFsbCBzdHJlYW1zIC08bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluY2x1ZGluZyBzdHJlYW1zIGluIHRlcm1p bmFsIHN0YXRlcywgYnV0IGV4Y2x1ZGluZyBzdHJlYW0gMCAtIE1VU1QgTk9UIGV4Y2VlZDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIHZhbHVlIGFkdmVydGlzZWQgYnkg YSByZWNlaXZlciAoaS5lLiBNQVhfREFUQSkuJm5ic3A7IEFuIGVuZHBvaW50IE1VU1QgdGVybWlu YXRlIGEgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0 aCBhIFFVSUNfRkxPV19DT05UUk9MX1JFQ0VJVkVEX1RPT19NVUNIX0RBVEEgZXJyb3IgaWYgaXQg dXNlZCBtb3JlIGNvbm5lY3Rpb24gY3JlZGl0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dGhhbiB0aGUgbWF4aW11bSBkYXRhIHZhbHVlIHRoYXQgaXQgaGFzIHNlbnQsIHVu bGVzcyB0aGlzIGlzIGEgcmVzdWx0IG9mIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNoYW5nZSBpbiB0aGUgaW5pdGlhbCBsaW1pdHMgKHNlZSB7e3plcm9ydHQtcGFyYW1l dGVyc319KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVjZWl2ZXIgd2lsbCBiZSBhYmxlIHRvIGdyYW50IGRlZGlj YXRlZCBjcmVkaXRzIHRvIHRoZSBoaWdoLXByaW9yaXR5IHN0cmVhbSB3L28gcmVxdWlyaW5nIHRo ZSBzZW5kZXIgb3IgdGhlIGludGVybWVkaWFyeSB0byBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBz ZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sIGFuZCB3aXRob3V0IHdvcnJ5aW5nIHRoYXQgdGhlIHNl bmRlci9pbnRlcm1lZGlhcnkgd2lsbCDigJxzcXVhbmRlcuKAnQ0KIHRoZSBjcmVkaXRzIG9uIHVu aW1wb3J0YW50IHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+U1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGUgZnJhbWUgdXBkYXRlcyBEYXRhIENyZWRpdCBmb3IgYSBzdHJlYW0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPn5+fjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAx Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDImbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTdHJlYW0g SUQgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGF0YSBDcmVk aXQgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPn5+fjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmll bGRzIGluIHRoZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgYXJlIGFzIGZvbGxvd3M6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlN0cmVhbSBJRDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OiBU aGUgc3RyZWFtIElEIG9mIHRoZSBzdHJlYW0gdGhhdCBpcyBhZmZlY3RlZCBlbmNvZGVkIGFzIGEg dmFyaWFibGUtbGVuZ3RoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgaW50ZWdlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGF0YSBDcmVkaXQ6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjogQSB2YXJpYWJsZS1sZW5ndGggaW50ZWdlciBpbmRpY2F0aW5nIHRo ZSBuZXcgdG90YWwgZGF0YSBjcmVkaXQgZm9yIHRoZSBzdHJlYW0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciBlYWNoIHN0cmVhbSBEYXRhIENyZWRpdCBzdGFydHMgd2l0aCAwLiZuYnNwOyBU aGUgc2VuZGVyIGNhbiBvbmx5IGluY3JlYXNlIERhdGEgQ3JlZGl0IGluIHN1YnNlcXVlbnQgU1RS RUFNX0RBVEFfQ1JFRElUIGZyYW1lcyBmb3IgdGhlIHNhbWUgc3RyZWFtLCBidXQgbG9zcyBhbmQg cmVvcmRlcmluZyBjYW4gY2F1c2UgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyB0byBiZSByZWNl aXZlZCBvdXQgb2Ygb3JkZXIuJm5ic3A7DQogU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyB0aGF0 IGRvIG5vdCBhZHZhbmNlIERhdGEgQ3JlZGl0IGZvciB0aGUgc3RyZWFtIE1VU1QgYmUgaWdub3Jl ZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D b21tZW50cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZl bDEgbGZvNiI+SWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BAA95A8BDF644F96B114D7F57EB0B7FEfbcom_-- From nobody Tue Jan 23 15:31:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0D412D872 for ; Tue, 23 Jan 2018 15:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6abvU9Q3AmW for ; Tue, 23 Jan 2018 15:30:54 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3826A12D93E for ; Tue, 23 Jan 2018 15:30:54 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A2FC7340EDD; Wed, 24 Jan 2018 00:30:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.24713); Wed, 24 Jan 2018 00:30:52 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 24 Jan 2018 00:30:52 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43083534; Wed, 24 Jan 2018 00:30:52 +0100 From: "Brian Trammell (IETF)" Message-Id: <0E3192F8-F2B2-42BD-947D-DCD9F359139A@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_9C3517CC-FF92-4BE0-93FD-368D2142FDF1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: what was yesterday's packet number decision? Date: Wed, 24 Jan 2018 00:30:51 +0100 In-Reply-To: <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> Cc: "Lubashev, Igor" , QUIC WG To: Christian Huitema References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> 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, 23 Jan 2018 23:31:06 -0000 --Apple-Mail=_9C3517CC-FF92-4BE0-93FD-368D2142FDF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, all, > On 23 Jan 2018, at 22:42, Christian Huitema = wrote: >=20 > On 1/23/2018 6:12 AM, Brian Trammell (IETF) wrote: >>> On 23 Jan 2018, at 16:18, Lubashev, Igor = wrote: >>>=20 >>>> (b) because packet number monotonicity increases flow linkability = over migration events that the sender does not know about, and we would = like to avoid these. >>> Would not the Connection ID give it away in these cases anyway? = Cases when the sender does know about migration events may fare better, = if the sender has received NEW_CONNECTION_ID in advance of the migration = event. >> Yeah, that's part of why I'm confused by the notes. >>=20 >> I think the underlying requirement here is to give an endpoint = (defined either as "the sender of a direction of a QUIC flow" or more = explicitly as "the client") some measure of control over how linkable = its packets are. Not using CID at all, and obfuscating the packet = sequence, increases the complexity of flow linkage during involuntary = migration. >>=20 >> (I say "increases the complexity" as opposed to "reduces linkability" = because, as a measurement geek, I'm deeply pessimistic about the ability = to eliminate linkability of packets sent by the same sender. After you = have added a runtime requirement to keep some amount of per-flow state = in order to link packets to a flow, any additional complexity in packet = number obfuscation only serves to increase the amount of work to design = an algorithm for linking packets, i.e., it increases the number of = masters' and/or doctoral degrees awarded to people who work on solving = the problem of linking QUIC flows.)\ >=20 > In addition to linkability, there is an AEAD issue. We MUST guarantee > that the same packet sequence number will not be used twice with the > same key. One class of solution is to use different encryption keys = per > connection ID. We looked at that, and the sense of the room was that = it > was very complex. Yeah, it seems so. > But if we use the same encryption context across > multiple connection ID, the simplest way to guarantee that packet > sequence numbers don't repeat on multiple connection is to use a = "global > sequence". And if you do that, you have a really big issue with > linkability, and the easiest way to solve that is to encrypt the = packet > sequence number. Yep... most of my questions at this point are on the specifics on how = this is supposed to work, so I'll wait for a PR before asking them. > Encrypting the packet sequence number also has the nice property of > ensuring that non invariant bits cannot be easily guessed by > middle-boxes. So, it prevent ossification, and will allow us to later > switch to for example var length encoding. > Another nice property of encrypted sequence numbers is that they can > start at zero, which reduces the size of ACK packets. We already have that property with the secret-offset PR, but yeah, it's = definitely worth trying to keep that property no matter what we do. > We may want to have a discussion about exposing a 1, 2 or 3 bit = sequence > number in clear text, so intermediaries can observe it and deduce = issues > like losses or reordering. But we should be deliberate about that, and > follow pretty much the same process as for reserving the spin bit. I will note that if we varint the packet number, or if encryption makes = it fixed-length (either of which would appear to be true), we can claw = back the type bits in the short header, and can stick the subsequence = number there, i.e.: +-+-+-+-+-+-+-+-+ |0|C|K|S| SSN | +-+-+-+-+-+-+-+-+ unless we want to grab one of those bits for some other purpose. I = suspect that four bits of subsequence are more useful than three bits, = but that's just intuition; data about common loss and reordering = patterns seen in large HTTP installations would be useful here. I'll reserve comment on process for later, but I will note that = encrypted packet numbers significantly change the current information = content of the wire image, while encrypted packet numbers + subsequence = numbers represent a less significant change. Cheers, Brian --Apple-Mail=_9C3517CC-FF92-4BE0-93FD-368D2142FDF1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpnxasACgkQihK3vwvq RqPboRAAkOrRn5JA+JdJHdp649FKXNj3B/RUY7S45olfOm70+tLQwUeJ3iq8kobC 8Aw+xb8rJKNRwQostFdRmF7y+3BQco0b0YD106eq08w3R956GyIplEN02g7Dg/2a 3fhTTlfd4esxLEwCu3+7saHYolDhnryiWDGhCdeANY6p8ye6TDh78PwScn3g7DjD +XqjG/wYDQ502ANPpAJaBQk0wPj8QZjYcDLDTr5MPBxMqD0iKQ0JnrB6bnTKQP5S StahB4SJrK4vJ7I6ZXWyPiD28Coh3xQltdKCKiOycTHiDN0/WRBr74adM8ofMIm2 e8X2Jul3981QpVGkxWSDERhCw+ax/IKOgDF802I6WVO2hhqD3t1+tHP+v1C4wvzn qs5Jcn8HVrEiitwhgvHOXhrkrMvkLxUMSHgMdaCLop9YeDGzhkSU6AKxt1o6lZpM JZX+inHP13FFWjHG2urbac0NBwHK0nQqwokkeXuWc9p1xK5v55vSt2MUUOWS8toL aIzE62SG9lshA0OXUjr77u1A+/rCTto3wy6NN0VjcvQQIA+D6cAUW8YdZ8v6kyHj uJ8/D4FK4fL+1rBqwhpRfx6Vv0LlcesVUnIzlgaKDMbpgHb1vMvZRTE/Cs733CyV sktlV1UT9d/hdP1grk+1kJLT0UMkVw7oRnErYcOskQ6PcIFx/pc= =MWd0 -----END PGP SIGNATURE----- --Apple-Mail=_9C3517CC-FF92-4BE0-93FD-368D2142FDF1-- From nobody Tue Jan 23 15:36:39 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D4D12D942 for ; Tue, 23 Jan 2018 15:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.281 X-Spam-Level: ** X-Spam-Status: No, score=2.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=E47tSNdc; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=H+AcvfbA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWinQ9NBRUGc for ; Tue, 23 Jan 2018 15:36:36 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D338012D940 for ; Tue, 23 Jan 2018 15:36:35 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0NNYDXV006754; Tue, 23 Jan 2018 15:36:31 -0800 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=PejSenjH05fTHzx/2Np+8L9mTjWF5D5j1rA9gk0xGZA=; b=E47tSNdcwIWUKeU5wGbIaHYu2nNFLg80n9I71lQqIFvX9WR7ZnsaZt+SErdPx74mpRDW pM6RT+ySizCqVme9JXMZ1d0G25d/rZ3VM5dAbR9wdA3NGABKuRyE+6nVrDP83ThmJxEv ULHP5N0mlBjxPSEpbcT8VnwZ4B2cLWL2kMs= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2fpbq88gkx-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 15:36:31 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.20) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 15:33:55 -0800 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=PejSenjH05fTHzx/2Np+8L9mTjWF5D5j1rA9gk0xGZA=; b=H+AcvfbAQuA8zGsMtSmYLRqLBpclpfIbrtU2J3dXN3QJ+2WtpThuUEUcX1vXsW119jCY8EGYMq6k62LqTS4UvBCdVlRogxbnIU1ExuX2a0RJxiYh0u+BhKroGDvLNxl74dLvd1eH3MSd+huQC01Y1pVMsz0oQec9w6l1OQM+LGM= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2184.namprd15.prod.outlook.com (52.132.131.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.18; Tue, 23 Jan 2018 23:33:53 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Tue, 23 Jan 2018 23:33:53 +0000 From: Roberto Peon To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Re: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgA== Date: Tue, 23 Jan 2018 23:33:53 +0000 Message-ID: References: <5086f27b81f74a1cad90555d25c227b3@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <5086f27b81f74a1cad90555d25c227b3@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2184; 7:FX7J+IxnAa394JvKjsPe27b5gzUTCN261cQSa+hApEsxPhNS2uRHEeNnkMBASppoLHyjHhnGY5lefd2VgXeezO2xZvGXsjx0TSh265evUogtgvNBepB1D3vL8+o4fEUR5tPTI+RtabEdqceWykCUQTh4eXNeRdpb1ocLHY4GnCiYNhUbzmMZG3MpslEeujyX0XAihTd8vgOAmkbFesH96JzsEBMRDYL9FuKkTT7vUMsJvJ4C2oQnpI/bu1XG+D8o; 20:lAJ7VpXzqpN+eUtR2DbOKDcHolWL8psTfhkWkLoLQjvocP9+y3DJ9nuKgtR08eDehfUTUnFLqTNEmq7NQh0nd+KGQnzb1ipyeHzaXLL+bwqLQG956mV7gQutoo1l+hh/pux8NP6rvL6E6IqA+OHjRV1b8glkh+4EzoO2YyKDHmg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: da0bafb0-ca81-43a0-09a8-08d562b9c3f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2184; x-ms-traffictypediagnostic: DM5PR1501MB2184: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(60795455431006)(67672495146484)(21748063052155)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231023)(11241501184)(2400081)(944501161)(93006095)(93001095)(6041288)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR1501MB2184; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2184; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(396003)(39860400002)(346002)(39380400002)(199004)(189003)(7736002)(82746002)(2501003)(236005)(54896002)(105586002)(5250100002)(97736004)(6436002)(6512007)(5660300001)(81166006)(81156014)(3660700001)(8936002)(86362001)(68736007)(8676002)(551984002)(7116003)(6486002)(2950100002)(2201001)(2171002)(99286004)(110136005)(53936002)(3480700004)(2900100001)(106356001)(6306002)(561944003)(33656002)(66066001)(102836004)(53546011)(59450400001)(478600001)(36756003)(76176011)(6506007)(14454004)(6346003)(26005)(25786009)(3280700002)(3846002)(6116002)(2906002)(229853002)(316002)(6246003)(83716003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2184; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VeI2GrLGE2LT1uRlfpnm4+u9A6IdjC4E382HxTGBvILDeijdJwnCPiGZJTynR9m+LRQf9r+QqnKhaotWzUZITA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_ECB18E070D3144ACB8EB8DD8707E2FF2fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: da0bafb0-ca81-43a0-09a8-08d562b9c3f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2018 23:33:53.7943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2184 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 23:36:38 -0000 --_000_ECB18E070D3144ACB8EB8DD8707E2FF2fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgbXVzdCBhc3N1bWUgdGhhdCBhbnkgZmluaXRlIGJ1ZmZlciBjYW4gYmUgY29uc3VtZWQuIFRo dXMsIGFueSBwYXJ0aXRpb25pbmcgb2YgdGhlIGF2YWlsYWJsZSBtZW1vcnkgd2hpY2ggaXMgZmlu aXRlIGNhbm5vdCBwcmV2ZW50IHRoaXMgZnJvbSBvY2N1cnJpbmcuIFdoZW4gaXQgb2NjdXJzLCBp dCBtYXkgaW5kdWNlIGluZGVmaW5pdGUgaGVhZC1vZi1saW5lLWJsb2NraW5nIG9uIGFsbCBmbG93 LWNvbnRyb2xsZWQgdXBzdHJlYW0gbm9kZXMgaW4gdGhlIHRvcG9sb2d5Lg0KDQpJbiBvdGhlciB3 b3JkcywgdGhlIHByb2JsZW0gaXMgbm90IHByZXZlbnRhYmxlIHdpdGggYW55IG1lY2hhbmlzbSB3 ZSBpbnRyb2R1Y2Ugd2l0aGluIHRoZSBwcm90b2NvbC4gQXQgYmVzdCB3ZSBjYW4gbWFrZSBpdCBk ZXRlY3RhYmxlIGFuZCBwcm92aWRlIG1lY2hhbmlzbXMgdG8gbGltaXQgdGhlIGRhbWFnZSB3aGVu IGl0IGhhcHBlbnMuDQoNClRoZSBzdHJlYW0tZGF0YS1jcmVkaXQgc3R1ZmYgaXMgYSBnb29kIG1l Y2hhbmlzbSB0byBsaW1pdCB0aGUgZGFtYWdlIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciBmaW5p dGUgbWVtb3J5IHVzZSwgYnV0IGl0IGlzIHVzZWZ1bCBvbmx5IHdoZW4vaWYgYW4gYXBwbGljYXRp b24ga25vd3MgdGhhdCBzb21lIGFjdGlvbiBpcyByZXF1aXJlZC4NCg0KVGhlcmUgYXJlIGFsdGVy bmF0ZSBtZWNoYW5pc21zIHRoYXQgd291bGQgYWxzbyBiZSB1c2VmdWw6IGNhbmNlbGxpbmcgYSBz dHJlYW0sIGZvciBpbnN0YW5jZS4NCi09Ug0KcC5zLiB0aGUgcmVhbCBwcm9ibGVtIGlzIHRoYXQg d2XigJl2ZSBkZWxlZ2F0ZWQgdGhlIG93bmVyc2hpcCBvZiB0aGUgZGF0YSB0byB0aGUgaW50ZXJt ZWRpYXJ5IGJ5IGFsbG93aW5nIHRoZSBzZW5kZXIgdG8gZmx1c2ggaXRzIGJ5dGVzIHVwb24gcmVj ZWl2aW5nIHAycCBhY2tzLiBUaGUgYmVzdCBzb2x1dGlvbiBoZXJlIHdvdWxkIGJlIGUyZSBhY2tz ICh3aGV0aGVyIGFwcGxpY2F0aW9uLWxheWVyIG9yIHRyYW5zcG9ydCBvciBib3RoKS4NCg0KRnJv bTogIkx1YmFzaGV2LCBJZ29yIiA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkRhdGU6IFdlZG5lc2Rh eSwgSmFudWFyeSAyNCwgMjAxOCBhdCA5OjA4IEFNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBm Yi5jb20+LCAicXVpY0BpZXRmLm9yZyIgPHF1aWNAaWV0Zi5vcmc+LCAiaWdvcmxvcmRAYWx1bS5t aXQuZWR1IiA8aWdvcmxvcmRAYWx1bS5taXQuZWR1Pg0KU3ViamVjdDogUkU6IERlYWRsb2NrIGF2 b2lkYW5jZSBwcm9wb3NhbA0KDQoNCiAgKiAgIFRoZSBzdHJlYW0tZGF0YS1jcmVkaXQgd291bGQg bmVlZCB0byBiZSBleHByZXNzZWQgYXMgYSBzdHJlYW0gb2Zmc2V0ICh0aGlzIHJlc29sdmVzIHRo ZSByYWNlcyBhbmQgYWxsb3dzIHRoZSBtYXRoIHlvdSBoYXZlIGRvd24gdGhlcmUgdG8gd29yayBw cm9wZXJseSkuIEkgc3VzcGVjdCB0aGlzIGlzIHdoYXQgeW91IG1lYW4gaW4gdGhlIGZpcnN0IHBs YWNlLg0KDQpZZXMsIHRoZSBzdHJlYW0tZGF0YS1jcmVkaXQgaW4gdGhpcyBwcm9wb3NhbCBpcyBl eHByZXNzZWQgaW4gZXZlci1pbmNyZWFzaW5nIG9mZnNldHMuDQoNCg0KICAqICAgT3RoZXJ3aXNl LCBsb29rcyBnb29kLiBUaGlzIHdvdWxkIGZhbGwgdW5kZXIgdGhlIOKAmGFsbG93IG1vcmUgYnVm ZmVyaW5nIGF0IHRoZSBhcHBsaWNhdGlvbuKAmSBidWxsZXQgTWFydGluIGhhZCwgYnV0IEkgYmVs aWV2ZSB0aGF0IGlzIGEgcmVhc29uYWJsZSB0aGluZyB0byBkbyBpZiBpdCBpcyBjb25zdHJhaW5l ZCBhbmQgZGlyZWN0ZWQgYnkgdGhlIGFwcGxpY2F0aW9uICh3aGljaCBjb3VsZCBkZWNpZGUgdG8g Y2FuY2VsIGEgc3RyZWFtIHRvbykuDQogICogICBTaW5jZSBmbG93IGNvbnRyb2wgaXMgZTJlLCB0 aGlzIGRvZXNu4oCZdCBpbXBhY3QgbWVtb3J5IGF0IGEgcHJveHkuDQoNCkV4YWN0bHkNCg0KDQog ICogICBXaGF0IHRoaXMgZG9lc27igJl0IHNvbHZlIGlzIHRoZSBkZXRlY3Rpb24gcHJvYmxlbS4N Cg0KSWYgeW91IGxvb2sgYXQgbXkgZm9sbG93LXVwIHByb3Bvc2FsICh3aGljaCBpcyBlZmZlY3Rp dmVseSBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBtYXhfc3RyZWFtX2RhdGEgdG8gbWVhbiBzdHJl YW1fZGF0YV9jcmVkaXQpLCB5b3UgbWF5IG5vdCBuZWVkIHRvIGhhdmUgcm9idXN0IGRlYWRsb2Nr IGRldGVjdGlvbiwgYmVjYXVzZSBkZWFkbG9ja3MgZHVlIHRvIHRyYW5zcG9ydCBjYW5ub3QgaGFw cGVuLiAgVGhlIG9ubHkgZGVhZGxvY2tzIHBvc3NpYmxlIHdpdGggdGhlIGZvbGxvdy11cCBzY2hl bWUgYXJlIGRlYWRsb2NrcyBkdWUgdG8gdGhlIGFwcGxpY2F0aW9u4oCZcyBjaXJjdWxhciBkZXBl bmRlbmN5LCBub3Qgc2VuZGVy4oCZcyBjaG9pY2Ugb2Ygd2hpY2ggc3RyZWFtIHRvIHNlbmQgZmly c3QNCg0KLT1SDQoNCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkx1YmFzaGV2LCBJZ29yIiA8aWx1 YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+DQpEYXRlOiBUdWVz ZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDI6NTAgUE0NClRvOiAicXVpY0BpZXRmLm9yZzxtYWls dG86cXVpY0BpZXRmLm9yZz4iIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4s ICJpZ29ybG9yZEBhbHVtLm1pdC5lZHU8bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4iIDxp Z29ybG9yZEBhbHVtLm1pdC5lZHU8bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4+DQpTdWJq ZWN0OiBEZWFkbG9jayBhdm9pZGFuY2UgcHJvcG9zYWwNCg0KVGhlIHByb2JsZW0gd2l0aCBkZWFk bG9ja2luZyBRVUlDIHN0cmVhbXMgaXMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIHNlbmRlciAo b3IgcHJveHkpIHdpbGwg4oCcdXNlIHVw4oCdIGNvbm5lY3Rpb24gZmxvdyBjb250cm9sIGNyZWRp dHMgb24gbG93ZXItcHJpb3JpdHkgc3RyZWFtcywgYmxvY2tpbmcgdGhlIHJlY2VpdmVyIGZyb20g bWFraW5nIGZvcndhcmQgcHJvZ3Jlc3Mgd2l0aCBhbnkgc3RyZWFtcy4gIFRoZSByZWNlaXZlciBo YXMgbm8gbWVjaGFuaXNtIHRvIGRpcmVjdC9mb3JjZSB0aGUgc2VuZGVyIHRvIHNlbmQgb24gcHJl ZmVycmVkIHN0cmVhbXMuDQoNCkkgd291bGQgbGlrZSB0byBwcm9wb3NlIGEgY29uY2VwdCBvZiDi gJxzdHJlYW0gZGF0YSBjcmVkaXTigJ0g4oCTIHRoZSBjb25jZXB0IG9mIGV4dHJhIGZsb3cgY29u dHJvbCBjcmVkaXRzIHRoYXQgY2FuIG9ubHkgYmUgdXNlZCBieSBhIHNwZWNpZmljIHN0cmVhbS4g IEEgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lIHdvdWxkIHVwZGF0ZSBzdWNoIGNyZWRpdHMgKHNl ZSBiZWxvdykuICBEYXRhIHNlbnQgb24gYSBzdHJlYW0gd2lsbCBjb25zdW1lIGl0cyBvd24gY3Jl ZGl0cyBhcyBtdWNoIGFzIGl0IGNhbiBhbmQgY29ubmVjdGlvbiBjcmVkaXRzICh1cGRhdGVkIGJ5 IE1BWF9EQVRBKSBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRhdGEuDQoNClRoZSB1cGRhdGVkIGNvbm5l Y3Rpb24gZmxvdyBjb250cm9sIGFjY291bnRpbmc6DQoNCuKAnA0KRm9yIGVhY2ggc3RyZWFtLCDi gJx1c2VkIGNvbm5lY3Rpb24gY3JlZGl0c+KAnSBpcyDigJxNQVgodGhlX2xhcmdlc3RfcmVjZWl2 ZWRfb2Zmc2V0IC0gc3RyZWFtX2RhdGFfY3JlZGl0cywgMCnigJ0uDQoNClRoZSBzdW0gb2Yg4oCc dXNlZCBjb25uZWN0aW9uIGNyZWRpdHPigJ0gb24gYWxsIHN0cmVhbXMgLQ0KaW5jbHVkaW5nIHN0 cmVhbXMgaW4gdGVybWluYWwgc3RhdGVzLCBidXQgZXhjbHVkaW5nIHN0cmVhbSAwIC0gTVVTVCBO T1QgZXhjZWVkDQp0aGUgdmFsdWUgYWR2ZXJ0aXNlZCBieSBhIHJlY2VpdmVyIChpLmUuIE1BWF9E QVRBKS4gIEFuIGVuZHBvaW50IE1VU1QgdGVybWluYXRlIGEgY29ubmVjdGlvbg0Kd2l0aCBhIFFV SUNfRkxPV19DT05UUk9MX1JFQ0VJVkVEX1RPT19NVUNIX0RBVEEgZXJyb3IgaWYgaXQgdXNlZCBt b3JlIGNvbm5lY3Rpb24gY3JlZGl0cw0KdGhhbiB0aGUgbWF4aW11bSBkYXRhIHZhbHVlIHRoYXQg aXQgaGFzIHNlbnQsIHVubGVzcyB0aGlzIGlzIGEgcmVzdWx0IG9mIGENCmNoYW5nZSBpbiB0aGUg aW5pdGlhbCBsaW1pdHMgKHNlZSB7e3plcm9ydHQtcGFyYW1ldGVyc319KS4NCuKAnA0KDQpUaGUg cmVjZWl2ZXIgd2lsbCBiZSBhYmxlIHRvIGdyYW50IGRlZGljYXRlZCBjcmVkaXRzIHRvIHRoZSBo aWdoLXByaW9yaXR5IHN0cmVhbSB3L28gcmVxdWlyaW5nIHRoZSBzZW5kZXIgb3IgdGhlIGludGVy bWVkaWFyeSB0byBrbm93IGFueXRoaW5nIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHByb3Rv Y29sIGFuZCB3aXRob3V0IHdvcnJ5aW5nIHRoYXQgdGhlIHNlbmRlci9pbnRlcm1lZGlhcnkgd2ls bCDigJxzcXVhbmRlcuKAnSB0aGUgY3JlZGl0cyBvbiB1bmltcG9ydGFudCBzdHJlYW1zLg0KDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQoNClNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZS4NCg0KVGhlIGZy YW1lIHVwZGF0ZXMgRGF0YSBDcmVkaXQgZm9yIGEgc3RyZWFtLg0KDQp+fn4NCjAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCjAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MQ0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCnwgICAgICAgICAgICAgICAgICAgICAgICBTdHJlYW0gSUQgKGkpICAgICAg ICAgICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAg IERhdGEgQ3JlZGl0IChpKSAgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCn5+ fg0KDQpUaGUgZmllbGRzIGluIHRoZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgYXJlIGFzIGZv bGxvd3M6DQoNClN0cmVhbSBJRDoNCg0KOiBUaGUgc3RyZWFtIElEIG9mIHRoZSBzdHJlYW0gdGhh dCBpcyBhZmZlY3RlZCBlbmNvZGVkIGFzIGEgdmFyaWFibGUtbGVuZ3RoDQogIGludGVnZXIuDQoN CkRhdGEgQ3JlZGl0Og0KDQo6IEEgdmFyaWFibGUtbGVuZ3RoIGludGVnZXIgaW5kaWNhdGluZyB0 aGUgbmV3IHRvdGFsIGRhdGEgY3JlZGl0IGZvciB0aGUgc3RyZWFtLg0KDQpGb3IgZWFjaCBzdHJl YW0gRGF0YSBDcmVkaXQgc3RhcnRzIHdpdGggMC4gIFRoZSBzZW5kZXIgY2FuIG9ubHkgaW5jcmVh c2UgRGF0YSBDcmVkaXQgaW4gc3Vic2VxdWVudCBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIGZv ciB0aGUgc2FtZSBzdHJlYW0sIGJ1dCBsb3NzIGFuZCByZW9yZGVyaW5nIGNhbiBjYXVzZSBTVFJF QU1fREFUQV9DUkVESVQgZnJhbWVzIHRvIGJlIHJlY2VpdmVkIG91dCBvZiBvcmRlci4gIFNUUkVB TV9EQVRBX0NSRURJVCBmcmFtZXMgdGhhdCBkbyBub3QgYWR2YW5jZSBEYXRhIENyZWRpdCBmb3Ig dGhlIHN0cmVhbSBNVVNUIGJlIGlnbm9yZWQuDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KQ29t bWVudHM/DQoNCg0KICAqICAgSWdvcg0K --_000_ECB18E070D3144ACB8EB8DD8707E2FF2fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <01189FF1AF3AB543BFFD5CE01E001AB8@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3Jh cGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHls ZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1h cmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCglj b2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjYzMDg2MzI1OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUw NTAyNTEwMjt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEwMzEyMjI3Njc7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNTA0NTYyMDA2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7 bXNvLWxpc3QtaWQ6MTEwMjMzNTczOTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6NzcxODE2MDQwIC0xNjgxNzI1MDA0IDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZv bnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci LHNlcmlmO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3Qg bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTYwNzYxODg2NzsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTE1Mjg5MzY2MjY7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDox OTU4MjIwOTE2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMzE1MzMzODE2IDI1NzQ4NjI0MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNDpsZXZlbDEN Cgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBs NDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0Omxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MjAy ODIxMDg0NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjE0NjcxNzUzODt9DQpAbGlzdCBsNTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBtdXN0IGFzc3VtZSB0aGF0IGFueSBmaW5pdGUgYnVmZmVy IGNhbiBiZSBjb25zdW1lZC4gVGh1cywgYW55IHBhcnRpdGlvbmluZyBvZiB0aGUgYXZhaWxhYmxl IG1lbW9yeSB3aGljaCBpcyBmaW5pdGUgY2Fubm90IHByZXZlbnQgdGhpcyBmcm9tIG9jY3Vycmlu Zy4gV2hlbiBpdCBvY2N1cnMsIGl0IG1heSBpbmR1Y2UgaW5kZWZpbml0ZSBoZWFkLW9mLWxpbmUt YmxvY2tpbmcgb24gYWxsIGZsb3ctY29udHJvbGxlZA0KIHVwc3RyZWFtIG5vZGVzIGluIHRoZSB0 b3BvbG9neS4gPGJyPg0KPGJyPg0KSW4gb3RoZXIgd29yZHMsIHRoZSBwcm9ibGVtIGlzIG5vdCBw cmV2ZW50YWJsZSB3aXRoIGFueSBtZWNoYW5pc20gd2UgaW50cm9kdWNlIHdpdGhpbiB0aGUgcHJv dG9jb2wuIEF0IGJlc3Qgd2UgY2FuIG1ha2UgaXQgZGV0ZWN0YWJsZSBhbmQgcHJvdmlkZSBtZWNo YW5pc21zIHRvIGxpbWl0IHRoZSBkYW1hZ2Ugd2hlbiBpdCBoYXBwZW5zLjxicj4NCjxicj4NClRo ZSBzdHJlYW0tZGF0YS1jcmVkaXQgc3R1ZmYgaXMgYSBnb29kIG1lY2hhbmlzbSB0byBsaW1pdCB0 aGUgZGFtYWdlIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciBmaW5pdGUgbWVtb3J5IHVzZSwgYnV0 IGl0IGlzIHVzZWZ1bCBvbmx5IHdoZW4vaWYgYW4gYXBwbGljYXRpb24ga25vd3MgdGhhdCBzb21l IGFjdGlvbiBpcyByZXF1aXJlZC48YnI+DQo8YnI+DQpUaGVyZSBhcmUgYWx0ZXJuYXRlIG1lY2hh bmlzbXMgdGhhdCB3b3VsZCBhbHNvIGJlIHVzZWZ1bDogY2FuY2VsbGluZyBhIHN0cmVhbSwgZm9y IGluc3RhbmNlLjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cC5zLiB0aGUgcmVhbCBwcm9ibGVtIGlzIHRoYXQgd2XigJl2ZSBkZWxlZ2F0ZWQgdGhlIG93bmVy c2hpcCBvZiB0aGUgZGF0YSB0byB0aGUgaW50ZXJtZWRpYXJ5IGJ5IGFsbG93aW5nIHRoZSBzZW5k ZXIgdG8gZmx1c2ggaXRzIGJ5dGVzIHVwb24gcmVjZWl2aW5nIHAycCBhY2tzLiBUaGUgYmVzdCBz b2x1dGlvbiBoZXJlIHdvdWxkIGJlIGUyZSBhY2tzICh3aGV0aGVyIGFwcGxpY2F0aW9uLWxheWVy IG9yIHRyYW5zcG9ydA0KIG9yIGJvdGgpLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPiZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDtpbHViYXNoZUBha2Ft YWkuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTgg YXQgOTowOCBBTTxicj4NCjxiPlRvOiA8L2I+Um9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20m Z3Q7LCAmcXVvdDtxdWljQGlldGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0OywgJnF1 b3Q7aWdvcmxvcmRAYWx1bS5taXQuZWR1JnF1b3Q7ICZsdDtpZ29ybG9yZEBhbHVtLm1pdC5lZHUm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBEZWFkbG9jayBhdm9pZGFuY2UgcHJvcG9zYWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsNCBsZXZlbDEgbGZvMyI+VGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3Vs ZCBuZWVkIHRvIGJlIGV4cHJlc3NlZCBhcyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMg dGhlIHJhY2VzIGFuZCBhbGxvd3MgdGhlIG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0byB3b3Jr IHByb3Blcmx5KS4gSSBzdXNwZWN0IHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBpbg0KIHRoZSBmaXJz dCBwbGFjZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB0aGUgc3RyZWFtLWRh dGEtY3JlZGl0IGluIHRoaXMgcHJvcG9zYWwgaXMgZXhwcmVzc2VkIGluIGV2ZXItaW5jcmVhc2lu ZyBvZmZzZXRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw0IGxl dmVsMSBsZm8zIj5PdGhlcndpc2UsIGxvb2tzIGdvb2QuIFRoaXMgd291bGQgZmFsbCB1bmRlciB0 aGUg4oCYYWxsb3cgbW9yZSBidWZmZXJpbmcgYXQgdGhlIGFwcGxpY2F0aW9u4oCZIGJ1bGxldCBN YXJ0aW4gaGFkLCBidXQgSSBiZWxpZXZlIHRoYXQgaXMgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRv IGlmIGl0IGlzIGNvbnN0cmFpbmVkIGFuZCBkaXJlY3RlZA0KIGJ5IHRoZSBhcHBsaWNhdGlvbiAo d2hpY2ggY291bGQgZGVjaWRlIHRvIGNhbmNlbCBhIHN0cmVhbSB0b28pLjxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps NCBsZXZlbDEgbGZvMyI+U2luY2UgZmxvdyBjb250cm9sIGlzIGUyZSwgdGhpcyBkb2VzbuKAmXQg aW1wYWN0IG1lbW9yeSBhdCBhIHByb3h5LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5F eGFjdGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwx IGxmbzMiPldoYXQgdGhpcyBkb2VzbuKAmXQgc29sdmUgaXMgdGhlIGRldGVjdGlvbiBwcm9ibGVt LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgbG9vayBhdCBteSBmb2xsb3ct dXAgcHJvcG9zYWwgKHdoaWNoIGlzIGVmZmVjdGl2ZWx5IGNoYW5naW5nIHRoZSBtZWFuaW5nIG9m IG1heF9zdHJlYW1fZGF0YSB0byBtZWFuIHN0cmVhbV9kYXRhX2NyZWRpdCksIHlvdSBtYXkgbm90 IG5lZWQgdG8gaGF2ZSByb2J1c3QgZGVhZGxvY2sgZGV0ZWN0aW9uLCBiZWNhdXNlIGRlYWRsb2Nr cyBkdWUgdG8gdHJhbnNwb3J0IGNhbm5vdCBoYXBwZW4uJm5ic3A7IFRoZSBvbmx5DQogZGVhZGxv Y2tzIHBvc3NpYmxlIHdpdGggdGhlIGZvbGxvdy11cCBzY2hlbWUgYXJlIGRlYWRsb2NrcyBkdWUg dG8gdGhlIGFwcGxpY2F0aW9u4oCZcyBjaXJjdWxhciBkZXBlbmRlbmN5LCBub3Qgc2VuZGVy4oCZ cyBjaG9pY2Ugb2Ygd2hpY2ggc3RyZWFtIHRvIHNlbmQgZmlyc3Q8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJl aGFsZiBvZiAmcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5UdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IGF0IDI6NTAgUE08YnI+DQo8Yj5Ubzog PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9h PiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdSI+aWdv cmxvcmRAYWx1bS5taXQuZWR1PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnb3Jsb3Jk QGFsdW0ubWl0LmVkdSI+aWdvcmxvcmRAYWx1bS5taXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OiA8L2I+RGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bvc2FsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcm9ibGVtIHdpdGggZGVhZGxv Y2tpbmcgUVVJQyBzdHJlYW1zIGlzIHRoZSBwb3NzaWJpbGl0eSB0aGF0IHRoZSBzZW5kZXIgKG9y IHByb3h5KSB3aWxsIOKAnHVzZSB1cOKAnSBjb25uZWN0aW9uIGZsb3cgY29udHJvbCBjcmVkaXRz IG9uIGxvd2VyLXByaW9yaXR5IHN0cmVhbXMsIGJsb2NraW5nIHRoZSByZWNlaXZlciBmcm9tIG1h a2luZyBmb3J3YXJkIHByb2dyZXNzIHdpdGggYW55IHN0cmVhbXMuJm5ic3A7IFRoZSByZWNlaXZl cg0KIGhhcyBubyBtZWNoYW5pc20gdG8gZGlyZWN0L2ZvcmNlIHRoZSBzZW5kZXIgdG8gc2VuZCBv biBwcmVmZXJyZWQgc3RyZWFtcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtl IHRvIHByb3Bvc2UgYSBjb25jZXB0IG9mIOKAnHN0cmVhbSBkYXRhIGNyZWRpdOKAnSDigJMgdGhl IGNvbmNlcHQgb2YgZXh0cmEgZmxvdyBjb250cm9sIGNyZWRpdHMgdGhhdCBjYW4gb25seSBiZSB1 c2VkIGJ5IGEgc3BlY2lmaWMgc3RyZWFtLiZuYnNwOyBBIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFt ZSB3b3VsZCB1cGRhdGUgc3VjaCBjcmVkaXRzIChzZWUgYmVsb3cpLiZuYnNwOyBEYXRhIHNlbnQg b24gYSBzdHJlYW0NCiB3aWxsIGNvbnN1bWUgaXRzIG93biBjcmVkaXRzIGFzIG11Y2ggYXMgaXQg Y2FuIGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVwZGF0ZWQgYnkgTUFYX0RBVEEpIGZvciB0aGUg cmVzdCBvZiB0aGUgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHVwZGF0ZWQgY29u bmVjdGlvbiBmbG93IGNvbnRyb2wgYWNjb3VudGluZzombmJzcDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGVhY2gg c3RyZWFtLCDigJx1c2VkIGNvbm5lY3Rpb24gY3JlZGl0c+KAnSBpcyDigJxNQVgodGhlX2xhcmdl c3RfcmVjZWl2ZWRfb2Zmc2V0IC0gc3RyZWFtX2RhdGFfY3JlZGl0cywgMCnigJ0uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBzdW0gb2Yg4oCcdXNlZCBjb25uZWN0aW9uIGNyZWRpdHPigJ0g b24gYWxsIHN0cmVhbXMgLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5j bHVkaW5nIHN0cmVhbXMgaW4gdGVybWluYWwgc3RhdGVzLCBidXQgZXhjbHVkaW5nIHN0cmVhbSAw IC0gTVVTVCBOT1QgZXhjZWVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGUgdmFsdWUgYWR2ZXJ0aXNlZCBieSBhIHJlY2VpdmVyIChpLmUuIE1BWF9EQVRBKS4mbmJzcDsg QW4gZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj53aXRoIGEgUVVJQ19GTE9XX0NPTlRST0xfUkVDRUlWRURfVE9P X01VQ0hfREFUQSBlcnJvciBpZiBpdCB1c2VkIG1vcmUgY29ubmVjdGlvbiBjcmVkaXRzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGFuIHRoZSBtYXhpbXVtIGRhdGEgdmFs dWUgdGhhdCBpdCBoYXMgc2VudCwgdW5sZXNzIHRoaXMgaXMgYSByZXN1bHQgb2YgYTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y2hhbmdlIGluIHRoZSBpbml0aWFsIGxpbWl0 cyAoc2VlIHt7emVyb3J0dC1wYXJhbWV0ZXJzfX0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSByZWNlaXZlciB3aWxs IGJlIGFibGUgdG8gZ3JhbnQgZGVkaWNhdGVkIGNyZWRpdHMgdG8gdGhlIGhpZ2gtcHJpb3JpdHkg c3RyZWFtIHcvbyByZXF1aXJpbmcgdGhlIHNlbmRlciBvciB0aGUgaW50ZXJtZWRpYXJ5IHRvIGtu b3cgYW55dGhpbmcgYWJvdXQgdGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2wgYW5kIHdpdGhv dXQgd29ycnlpbmcgdGhhdCB0aGUgc2VuZGVyL2ludGVybWVkaWFyeSB3aWxsIOKAnHNxdWFuZGVy 4oCdDQogdGhlIGNyZWRpdHMgb24gdW5pbXBvcnRhbnQgc3RyZWFtcy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TVFJFQU1fREFUQV9DUkVESVQg ZnJhbWUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmcmFtZSB1cGRhdGVzIERhdGEgQ3Jl ZGl0IGZvciBhIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fn5+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj58Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFN0cmVhbSBJRCAoaSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBEYXRhIENyZWRpdCAoaSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fn5+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBmaWVsZHMgaW4gdGhlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFt ZSBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3RyZWFtIElEOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj46IFRoZSBzdHJlYW0gSUQgb2YgdGhlIHN0cmVhbSB0aGF0IGlz IGFmZmVjdGVkIGVuY29kZWQgYXMgYSB2YXJpYWJsZS1sZW5ndGg8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbnRlZ2VyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EYXRhIENyZWRpdDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+OiBBIHZhcmlhYmxlLWxlbmd0 aCBpbnRlZ2VyIGluZGljYXRpbmcgdGhlIG5ldyB0b3RhbCBkYXRhIGNyZWRpdCBmb3IgdGhlIHN0 cmVhbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGVhY2ggc3RyZWFtIERhdGEgQ3JlZGl0 IHN0YXJ0cyB3aXRoIDAuJm5ic3A7IFRoZSBzZW5kZXIgY2FuIG9ubHkgaW5jcmVhc2UgRGF0YSBD cmVkaXQgaW4gc3Vic2VxdWVudCBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWVzIGZvciB0aGUgc2Ft ZSBzdHJlYW0sIGJ1dCBsb3NzIGFuZCByZW9yZGVyaW5nIGNhbiBjYXVzZSBTVFJFQU1fREFUQV9D UkVESVQgZnJhbWVzIHRvIGJlIHJlY2VpdmVkIG91dCBvZiBvcmRlci4mbmJzcDsNCiBTVFJFQU1f REFUQV9DUkVESVQgZnJhbWVzIHRoYXQgZG8gbm90IGFkdmFuY2UgRGF0YSBDcmVkaXQgZm9yIHRo ZSBzdHJlYW0gTVVTVCBiZSBpZ25vcmVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbW1lbnRzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm84Ij5JZ29yPG86cD48L286cD48L2xpPjwvdWw+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ECB18E070D3144ACB8EB8DD8707E2FF2fbcom_-- From nobody Tue Jan 23 15:51:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF2A12D893 for ; Tue, 23 Jan 2018 15:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 LcVAM7xgN6eY for ; Tue, 23 Jan 2018 15:51:33 -0800 (PST) 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 5EB5E12D876 for ; Tue, 23 Jan 2018 15:51:33 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NNksJp019929; Tue, 23 Jan 2018 23:51:25 GMT 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=iBrTAhs4/WwxqmFFnY9TAJaH8XXYWBv1a2mwd5GY10c=; b=Rn810qpyvTEXpxHMLCskG7LAdRQ+0tsA89lOchCz7A/tdmPCOT+Xefo8FGXXL/HPNCad g0jQhM3dyCZb+f5G4l7VtKsa7unvSXmXOoLnx0OgOpL7sxd8huh7JnKK63NCW105q+Gt ylnZqwJhFGy3R57yD7YxUuRpJKrnOgeMoLMIEzpGQKkuR5ZvhGrW1U/kIwRuaUjbMp5c vEEbynS/rWrQthgQ1rktRRg71FwJ1bEOqS013p7dc5cfu8zRmdaJgJ0EBfWwPgV5711o DFIcWkpZin+7CqGcimkRytZdr1piiZXigZ4POi7XHxtVC028wdUlARCjA+5ubQ3YpcvR 4w== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgwrw85-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 23:51:25 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0NNpIgf031416; Tue, 23 Jan 2018 18:51:24 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200hjfu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 18:51:24 -0500 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; Tue, 23 Jan 2018 18:51:23 -0500 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; Tue, 23 Jan 2018 18:51:22 -0500 From: "Lubashev, Igor" To: Roberto Peon , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: RE: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgIAAtfbg Date: Tue, 23 Jan 2018 23:51:22 +0000 Message-ID: References: <5086f27b81f74a1cad90555d25c227b3@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.38.42] Content-Type: multipart/alternative; boundary="_000_b3f1ddd3678c49fea41c3082e3113f91usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230305 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230304 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Jan 2018 23:51:36 -0000 --_000_b3f1ddd3678c49fea41c3082e3113f91usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgeW91IGhhdmUgZmluaXRlIGJ1ZmZlciBtZW1vcnkgQU5EIGFsbG93IGFsbCBvZiB0aGF0IGJ1 ZmZlciBtZW1vcnkgdG8gYmUgdXNlZCBmb3IgYW55IHN0cmVhbSwgeW91IGNhbm5vdCBhdm9pZCBk ZWFkbG9ja3MuICBIb3dldmVyLCBpZiB5b3UgZGVkaWNhdGUgc29tZSBidWZmZXIgbWVtb3J5IHRv IGVhY2ggc3RyZWFtIChkb2VzIG5vdCBuZWVkIHRvIGJlIG11Y2gg4oCTIGp1c3QgbmVlZHMgdG8g YmUgZW5vdWdoIGZvciBvbmUg4oCcbWVzc2FnZeKAnSksIHlvdSBjYW4gYWx3YXlzIG1ha2UgcHJv Z3Jlc3Mgb24geW91ciBoaWdoZXN0LXByaW9yaXR5IHN0cmVhbS4NCg0KVGhlIHRyYWRlLW9mZiBp cyB0aGF0IHNvbWUgbWVtb3J5IG1heSBlbmQgdXAgdW51c2VkIChtZW1vcnkgZGVkaWNhdGVkIHRv IHN0cmVhbXMgdGhhdCBkbyBub3QgaGF2ZSBhbnl0aGluZyB0byBzZW5kKS4NCg0KSWYgeW91IHdh bnQgdG8gaW5jcmVhc2UgeW91ciBtZW1vcnkgdXRpbGl6YXRpb24gZXZlbiBmdXJ0aGVyLCB5b3Ug bWF5IGVuZCB1cCBkb2luZyBibG9ja2VkLXN0cmVhbSBkZXRlY3Rpb24gKHJlc3BvbmRpbmcgdG8g U1RSRUFNX0JMT0NLRUQgZnJhbWVzKSBhbmQgZ2l2ZSBleHRyYSBtZW1vcnkgdG8gdGhvc2Ugc3Ry ZWFtcyDigJxqdXN0LWluLXRpbWXigJ0uDQoNCi0gSWdvcg0KDQpGcm9tOiBSb2JlcnRvIFBlb24g W21haWx0bzpmZW5peEBmYi5jb21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IDY6 MzQgUE0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IHF1aWNAaWV0 Zi5vcmc7IGlnb3Jsb3JkQGFsdW0ubWl0LmVkdQ0KU3ViamVjdDogUmU6IERlYWRsb2NrIGF2b2lk YW5jZSBwcm9wb3NhbA0KDQpXZSBtdXN0IGFzc3VtZSB0aGF0IGFueSBmaW5pdGUgYnVmZmVyIGNh biBiZSBjb25zdW1lZC4gVGh1cywgYW55IHBhcnRpdGlvbmluZyBvZiB0aGUgYXZhaWxhYmxlIG1l bW9yeSB3aGljaCBpcyBmaW5pdGUgY2Fubm90IHByZXZlbnQgdGhpcyBmcm9tIG9jY3VycmluZy4g V2hlbiBpdCBvY2N1cnMsIGl0IG1heSBpbmR1Y2UgaW5kZWZpbml0ZSBoZWFkLW9mLWxpbmUtYmxv Y2tpbmcgb24gYWxsIGZsb3ctY29udHJvbGxlZCB1cHN0cmVhbSBub2RlcyBpbiB0aGUgdG9wb2xv Z3kuDQoNCkluIG90aGVyIHdvcmRzLCB0aGUgcHJvYmxlbSBpcyBub3QgcHJldmVudGFibGUgd2l0 aCBhbnkgbWVjaGFuaXNtIHdlIGludHJvZHVjZSB3aXRoaW4gdGhlIHByb3RvY29sLiBBdCBiZXN0 IHdlIGNhbiBtYWtlIGl0IGRldGVjdGFibGUgYW5kIHByb3ZpZGUgbWVjaGFuaXNtcyB0byBsaW1p dCB0aGUgZGFtYWdlIHdoZW4gaXQgaGFwcGVucy4NCg0KVGhlIHN0cmVhbS1kYXRhLWNyZWRpdCBz dHVmZiBpcyBhIGdvb2QgbWVjaGFuaXNtIHRvIGxpbWl0IHRoZSBkYW1hZ2Ugd2hpbGUgc3RpbGwg YWxsb3dpbmcgZm9yIGZpbml0ZSBtZW1vcnkgdXNlLCBidXQgaXQgaXMgdXNlZnVsIG9ubHkgd2hl bi9pZiBhbiBhcHBsaWNhdGlvbiBrbm93cyB0aGF0IHNvbWUgYWN0aW9uIGlzIHJlcXVpcmVkLg0K DQpUaGVyZSBhcmUgYWx0ZXJuYXRlIG1lY2hhbmlzbXMgdGhhdCB3b3VsZCBhbHNvIGJlIHVzZWZ1 bDogY2FuY2VsbGluZyBhIHN0cmVhbSwgZm9yIGluc3RhbmNlLg0KLT1SDQpwLnMuIHRoZSByZWFs IHByb2JsZW0gaXMgdGhhdCB3ZeKAmXZlIGRlbGVnYXRlZCB0aGUgb3duZXJzaGlwIG9mIHRoZSBk YXRhIHRvIHRoZSBpbnRlcm1lZGlhcnkgYnkgYWxsb3dpbmcgdGhlIHNlbmRlciB0byBmbHVzaCBp dHMgYnl0ZXMgdXBvbiByZWNlaXZpbmcgcDJwIGFja3MuIFRoZSBiZXN0IHNvbHV0aW9uIGhlcmUg d291bGQgYmUgZTJlIGFja3MgKHdoZXRoZXIgYXBwbGljYXRpb24tbGF5ZXIgb3IgdHJhbnNwb3J0 IG9yIGJvdGgpLg0KDQpGcm9tOiAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZUBha2FtYWkuY29t PG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAy NCwgMjAxOCBhdCA5OjA4IEFNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRv OmZlbml4QGZiLmNvbT4+LCAicXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4iIDxx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4sICJpZ29ybG9yZEBhbHVtLm1pdC5l ZHU8bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4iIDxpZ29ybG9yZEBhbHVtLm1pdC5lZHU8 bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4+DQpTdWJqZWN0OiBSRTogRGVhZGxvY2sgYXZv aWRhbmNlIHByb3Bvc2FsDQoNCg0KICAqICAgVGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3VsZCBu ZWVkIHRvIGJlIGV4cHJlc3NlZCBhcyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMgdGhl IHJhY2VzIGFuZCBhbGxvd3MgdGhlIG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0byB3b3JrIHBy b3Blcmx5KS4gSSBzdXNwZWN0IHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBpbiB0aGUgZmlyc3QgcGxh Y2UuDQoNClllcywgdGhlIHN0cmVhbS1kYXRhLWNyZWRpdCBpbiB0aGlzIHByb3Bvc2FsIGlzIGV4 cHJlc3NlZCBpbiBldmVyLWluY3JlYXNpbmcgb2Zmc2V0cy4NCg0KDQogICogICBPdGhlcndpc2Us IGxvb2tzIGdvb2QuIFRoaXMgd291bGQgZmFsbCB1bmRlciB0aGUg4oCYYWxsb3cgbW9yZSBidWZm ZXJpbmcgYXQgdGhlIGFwcGxpY2F0aW9u4oCZIGJ1bGxldCBNYXJ0aW4gaGFkLCBidXQgSSBiZWxp ZXZlIHRoYXQgaXMgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRvIGlmIGl0IGlzIGNvbnN0cmFpbmVk IGFuZCBkaXJlY3RlZCBieSB0aGUgYXBwbGljYXRpb24gKHdoaWNoIGNvdWxkIGRlY2lkZSB0byBj YW5jZWwgYSBzdHJlYW0gdG9vKS4NCiAgKiAgIFNpbmNlIGZsb3cgY29udHJvbCBpcyBlMmUsIHRo aXMgZG9lc27igJl0IGltcGFjdCBtZW1vcnkgYXQgYSBwcm94eS4NCg0KRXhhY3RseQ0KDQoNCiAg KiAgIFdoYXQgdGhpcyBkb2VzbuKAmXQgc29sdmUgaXMgdGhlIGRldGVjdGlvbiBwcm9ibGVtLg0K DQpJZiB5b3UgbG9vayBhdCBteSBmb2xsb3ctdXAgcHJvcG9zYWwgKHdoaWNoIGlzIGVmZmVjdGl2 ZWx5IGNoYW5naW5nIHRoZSBtZWFuaW5nIG9mIG1heF9zdHJlYW1fZGF0YSB0byBtZWFuIHN0cmVh bV9kYXRhX2NyZWRpdCksIHlvdSBtYXkgbm90IG5lZWQgdG8gaGF2ZSByb2J1c3QgZGVhZGxvY2sg ZGV0ZWN0aW9uLCBiZWNhdXNlIGRlYWRsb2NrcyBkdWUgdG8gdHJhbnNwb3J0IGNhbm5vdCBoYXBw ZW4uICBUaGUgb25seSBkZWFkbG9ja3MgcG9zc2libGUgd2l0aCB0aGUgZm9sbG93LXVwIHNjaGVt ZSBhcmUgZGVhZGxvY2tzIGR1ZSB0byB0aGUgYXBwbGljYXRpb27igJlzIGNpcmN1bGFyIGRlcGVu ZGVuY3ksIG5vdCBzZW5kZXLigJlzIGNob2ljZSBvZiB3aGljaCBzdHJlYW0gdG8gc2VuZCBmaXJz dA0KDQotPVINCg0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiTHViYXNoZXYsIElnb3IiIDxpbHVi YXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkRhdGU6IFR1ZXNk YXksIEphbnVhcnkgMjMsIDIwMTggYXQgMjo1MCBQTQ0KVG86ICJxdWljQGlldGYub3JnPG1haWx0 bzpxdWljQGlldGYub3JnPiIgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Piwg Imlnb3Jsb3JkQGFsdW0ubWl0LmVkdTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1PiIgPGln b3Jsb3JkQGFsdW0ubWl0LmVkdTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1Pj4NClN1Ympl Y3Q6IERlYWRsb2NrIGF2b2lkYW5jZSBwcm9wb3NhbA0KDQpUaGUgcHJvYmxlbSB3aXRoIGRlYWRs b2NraW5nIFFVSUMgc3RyZWFtcyBpcyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc2VuZGVyIChv ciBwcm94eSkgd2lsbCDigJx1c2UgdXDigJ0gY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgY3JlZGl0 cyBvbiBsb3dlci1wcmlvcml0eSBzdHJlYW1zLCBibG9ja2luZyB0aGUgcmVjZWl2ZXIgZnJvbSBt YWtpbmcgZm9yd2FyZCBwcm9ncmVzcyB3aXRoIGFueSBzdHJlYW1zLiAgVGhlIHJlY2VpdmVyIGhh cyBubyBtZWNoYW5pc20gdG8gZGlyZWN0L2ZvcmNlIHRoZSBzZW5kZXIgdG8gc2VuZCBvbiBwcmVm ZXJyZWQgc3RyZWFtcy4NCg0KSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBjb25jZXB0IG9mIOKA nHN0cmVhbSBkYXRhIGNyZWRpdOKAnSDigJMgdGhlIGNvbmNlcHQgb2YgZXh0cmEgZmxvdyBjb250 cm9sIGNyZWRpdHMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGJ5IGEgc3BlY2lmaWMgc3RyZWFtLiAg QSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgd291bGQgdXBkYXRlIHN1Y2ggY3JlZGl0cyAoc2Vl IGJlbG93KS4gIERhdGEgc2VudCBvbiBhIHN0cmVhbSB3aWxsIGNvbnN1bWUgaXRzIG93biBjcmVk aXRzIGFzIG11Y2ggYXMgaXQgY2FuIGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVwZGF0ZWQgYnkg TUFYX0RBVEEpIGZvciB0aGUgcmVzdCBvZiB0aGUgZGF0YS4NCg0KVGhlIHVwZGF0ZWQgY29ubmVj dGlvbiBmbG93IGNvbnRyb2wgYWNjb3VudGluZzoNCg0K4oCcDQpGb3IgZWFjaCBzdHJlYW0sIOKA nHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIGlzIOKAnE1BWCh0aGVfbGFyZ2VzdF9yZWNlaXZl ZF9vZmZzZXQgLSBzdHJlYW1fZGF0YV9jcmVkaXRzLCAwKeKAnS4NCg0KVGhlIHN1bSBvZiDigJx1 c2VkIGNvbm5lY3Rpb24gY3JlZGl0c+KAnSBvbiBhbGwgc3RyZWFtcyAtDQppbmNsdWRpbmcgc3Ry ZWFtcyBpbiB0ZXJtaW5hbCBzdGF0ZXMsIGJ1dCBleGNsdWRpbmcgc3RyZWFtIDAgLSBNVVNUIE5P VCBleGNlZWQNCnRoZSB2YWx1ZSBhZHZlcnRpc2VkIGJ5IGEgcmVjZWl2ZXIgKGkuZS4gTUFYX0RB VEEpLiAgQW4gZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uDQp3aXRoIGEgUVVJ Q19GTE9XX0NPTlRST0xfUkVDRUlWRURfVE9PX01VQ0hfREFUQSBlcnJvciBpZiBpdCB1c2VkIG1v cmUgY29ubmVjdGlvbiBjcmVkaXRzDQp0aGFuIHRoZSBtYXhpbXVtIGRhdGEgdmFsdWUgdGhhdCBp dCBoYXMgc2VudCwgdW5sZXNzIHRoaXMgaXMgYSByZXN1bHQgb2YgYQ0KY2hhbmdlIGluIHRoZSBp bml0aWFsIGxpbWl0cyAoc2VlIHt7emVyb3J0dC1wYXJhbWV0ZXJzfX0pLg0K4oCcDQoNClRoZSBy ZWNlaXZlciB3aWxsIGJlIGFibGUgdG8gZ3JhbnQgZGVkaWNhdGVkIGNyZWRpdHMgdG8gdGhlIGhp Z2gtcHJpb3JpdHkgc3RyZWFtIHcvbyByZXF1aXJpbmcgdGhlIHNlbmRlciBvciB0aGUgaW50ZXJt ZWRpYXJ5IHRvIGtub3cgYW55dGhpbmcgYWJvdXQgdGhlIHNlbWFudGljcyBvZiB0aGUgcHJvdG9j b2wgYW5kIHdpdGhvdXQgd29ycnlpbmcgdGhhdCB0aGUgc2VuZGVyL2ludGVybWVkaWFyeSB3aWxs IOKAnHNxdWFuZGVy4oCdIHRoZSBjcmVkaXRzIG9uIHVuaW1wb3J0YW50IHN0cmVhbXMuDQoNCg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0NCg0KU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lLg0KDQpUaGUgZnJh bWUgdXBkYXRlcyBEYXRhIENyZWRpdCBmb3IgYSBzdHJlYW0uDQoNCn5+fg0KMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgIFN0cmVhbSBJRCAoaSkgICAgICAg ICAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAg RGF0YSBDcmVkaXQgKGkpICAgICAgICAgICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0Kfn5+ DQoNClRoZSBmaWVsZHMgaW4gdGhlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSBhcmUgYXMgZm9s bG93czoNCg0KU3RyZWFtIElEOg0KDQo6IFRoZSBzdHJlYW0gSUQgb2YgdGhlIHN0cmVhbSB0aGF0 IGlzIGFmZmVjdGVkIGVuY29kZWQgYXMgYSB2YXJpYWJsZS1sZW5ndGgNCiAgaW50ZWdlci4NCg0K RGF0YSBDcmVkaXQ6DQoNCjogQSB2YXJpYWJsZS1sZW5ndGggaW50ZWdlciBpbmRpY2F0aW5nIHRo ZSBuZXcgdG90YWwgZGF0YSBjcmVkaXQgZm9yIHRoZSBzdHJlYW0uDQoNCkZvciBlYWNoIHN0cmVh bSBEYXRhIENyZWRpdCBzdGFydHMgd2l0aCAwLiAgVGhlIHNlbmRlciBjYW4gb25seSBpbmNyZWFz ZSBEYXRhIENyZWRpdCBpbiBzdWJzZXF1ZW50IFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMgZm9y IHRoZSBzYW1lIHN0cmVhbSwgYnV0IGxvc3MgYW5kIHJlb3JkZXJpbmcgY2FuIGNhdXNlIFNUUkVB TV9EQVRBX0NSRURJVCBmcmFtZXMgdG8gYmUgcmVjZWl2ZWQgb3V0IG9mIG9yZGVyLiAgU1RSRUFN X0RBVEFfQ1JFRElUIGZyYW1lcyB0aGF0IGRvIG5vdCBhZHZhbmNlIERhdGEgQ3JlZGl0IGZvciB0 aGUgc3RyZWFtIE1VU1QgYmUgaWdub3JlZC4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQpDb21t ZW50cz8NCg0KDQogICogICBJZ29yDQo= --_000_b3f1ddd3678c49fea41c3082e3113f91usma1exdag1mb5msgcorpak_ 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 b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTAyMzM1NzM5Ow0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NzE4MTYwNDAgLTE2ODE3MjUwMDQgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMTE3MDE5MzgwOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxNzU4ODgwMDU0O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTUyOTg3 MzU3NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYzNDI0NjQ2MDt9DQpAbGlzdCBsMjpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzDQoJe21zby1saXN0LWlkOjE5NTgyMjA5MTY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMTUzMzM4MTYgMjU3NDg2MjQyIDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4Njkz O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBs MzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNA0KCXttc28tbGlzdC1pZDoy MDA4NTEwOTEyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1ODk4MzkzNDQ7fQ0KQGxpc3QgbDQ6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNQ0KCXttc28tbGlzdC1pZDoyMDM5MjM2Nzc4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMzMxODE3MzE0O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGhhdmUgZmluaXRlIGJ1 ZmZlciBtZW1vcnkgQU5EIGFsbG93IGFsbCBvZiB0aGF0IGJ1ZmZlciBtZW1vcnkgdG8gYmUgdXNl ZCBmb3IgYW55IHN0cmVhbSwgeW91IGNhbm5vdCBhdm9pZCBkZWFkbG9ja3MuJm5ic3A7IEhvd2V2 ZXIsIGlmIHlvdSBkZWRpY2F0ZSBzb21lIGJ1ZmZlciBtZW1vcnkgdG8gZWFjaCBzdHJlYW0gKGRv ZXMgbm90IG5lZWQgdG8gYmUgbXVjaCDigJMganVzdCBuZWVkcyB0byBiZSBlbm91Z2gNCiBmb3Ig b25lIOKAnG1lc3NhZ2XigJ0pLCB5b3UgY2FuIGFsd2F5cyBtYWtlIHByb2dyZXNzIG9uIHlvdXIg aGlnaGVzdC1wcmlvcml0eSBzdHJlYW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0cmFk ZS1vZmYgaXMgdGhhdCBzb21lIG1lbW9yeSBtYXkgZW5kIHVwIHVudXNlZCAobWVtb3J5IGRlZGlj YXRlZCB0byBzdHJlYW1zIHRoYXQgZG8gbm90IGhhdmUgYW55dGhpbmcgdG8gc2VuZCkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSB3YW50IHRvIGluY3JlYXNlIHlvdXIgbWVtb3J5IHV0 aWxpemF0aW9uIGV2ZW4gZnVydGhlciwgeW91IG1heSBlbmQgdXAgZG9pbmcgYmxvY2tlZC1zdHJl YW0gZGV0ZWN0aW9uIChyZXNwb25kaW5nIHRvIFNUUkVBTV9CTE9DS0VEIGZyYW1lcykgYW5kIGdp dmUgZXh0cmEgbWVtb3J5IHRvIHRob3NlIHN0cmVhbXMg4oCcanVzdC1pbi10aW1l4oCdLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElnb3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBSb2JlcnRvIFBlb24gW21h aWx0bzpmZW5peEBmYi5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDIz LCAyMDE4IDY6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNo ZUBha2FtYWkuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzsgaWdvcmxvcmRAYWx1bS5taXQuZWR1PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBEZWFkbG9jayBhdm9pZGFuY2UgcHJvcG9zYWw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIG11c3QgYXNzdW1lIHRoYXQgYW55 IGZpbml0ZSBidWZmZXIgY2FuIGJlIGNvbnN1bWVkLiBUaHVzLCBhbnkgcGFydGl0aW9uaW5nIG9m IHRoZSBhdmFpbGFibGUgbWVtb3J5IHdoaWNoIGlzIGZpbml0ZSBjYW5ub3QgcHJldmVudCB0aGlz IGZyb20gb2NjdXJyaW5nLiBXaGVuIGl0IG9jY3VycywgaXQgbWF5IGluZHVjZSBpbmRlZmluaXRl IGhlYWQtb2YtbGluZS1ibG9ja2luZyBvbiBhbGwgZmxvdy1jb250cm9sbGVkDQogdXBzdHJlYW0g bm9kZXMgaW4gdGhlIHRvcG9sb2d5LiA8YnI+DQo8YnI+DQpJbiBvdGhlciB3b3JkcywgdGhlIHBy b2JsZW0gaXMgbm90IHByZXZlbnRhYmxlIHdpdGggYW55IG1lY2hhbmlzbSB3ZSBpbnRyb2R1Y2Ug d2l0aGluIHRoZSBwcm90b2NvbC4gQXQgYmVzdCB3ZSBjYW4gbWFrZSBpdCBkZXRlY3RhYmxlIGFu ZCBwcm92aWRlIG1lY2hhbmlzbXMgdG8gbGltaXQgdGhlIGRhbWFnZSB3aGVuIGl0IGhhcHBlbnMu PGJyPg0KPGJyPg0KVGhlIHN0cmVhbS1kYXRhLWNyZWRpdCBzdHVmZiBpcyBhIGdvb2QgbWVjaGFu aXNtIHRvIGxpbWl0IHRoZSBkYW1hZ2Ugd2hpbGUgc3RpbGwgYWxsb3dpbmcgZm9yIGZpbml0ZSBt ZW1vcnkgdXNlLCBidXQgaXQgaXMgdXNlZnVsIG9ubHkgd2hlbi9pZiBhbiBhcHBsaWNhdGlvbiBr bm93cyB0aGF0IHNvbWUgYWN0aW9uIGlzIHJlcXVpcmVkLjxicj4NCjxicj4NClRoZXJlIGFyZSBh bHRlcm5hdGUgbWVjaGFuaXNtcyB0aGF0IHdvdWxkIGFsc28gYmUgdXNlZnVsOiBjYW5jZWxsaW5n IGEgc3RyZWFtLCBmb3IgaW5zdGFuY2UuPGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5wLnMuIHRoZSByZWFsIHByb2JsZW0gaXMgdGhhdCB3ZeKAmXZlIGRlbGVn YXRlZCB0aGUgb3duZXJzaGlwIG9mIHRoZSBkYXRhIHRvIHRoZSBpbnRlcm1lZGlhcnkgYnkgYWxs b3dpbmcgdGhlIHNlbmRlciB0byBmbHVzaCBpdHMgYnl0ZXMgdXBvbiByZWNlaXZpbmcgcDJwIGFj a3MuIFRoZSBiZXN0IHNvbHV0aW9uIGhlcmUgd291bGQgYmUgZTJlIGFja3MgKHdoZXRoZXIgYXBw bGljYXRpb24tbGF5ZXIgb3IgdHJhbnNwb3J0DQogb3IgYm90aCkuIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+JnF1b3Q7THViYXNoZXYsIElnb3ImcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29t PC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IGF0 IDk6MDggQU08YnI+DQo8Yj5UbzogPC9iPlJvYmVydG8gUGVvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmZlbml4QGZiLmNvbSI+ZmVuaXhAZmIuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdSI+aWdvcmxvcmRAYWx1bS5taXQuZWR1PC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdSI+aWdvcmxvcmRA YWx1bS5taXQuZWR1PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IERlYWRsb2NrIGF2 b2lkYW5jZSBwcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPlRoZSBzdHJlYW0tZGF0YS1jcmVkaXQgd291 bGQgbmVlZCB0byBiZSBleHByZXNzZWQgYXMgYSBzdHJlYW0gb2Zmc2V0ICh0aGlzIHJlc29sdmVz IHRoZSByYWNlcyBhbmQgYWxsb3dzIHRoZSBtYXRoIHlvdSBoYXZlIGRvd24gdGhlcmUgdG8gd29y ayBwcm9wZXJseSkuIEkgc3VzcGVjdCB0aGlzIGlzIHdoYXQgeW91IG1lYW4gaW4gdGhlIGZpcnN0 IHBsYWNlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRoZSBzdHJlYW0tZGF0 YS1jcmVkaXQgaW4gdGhpcyBwcm9wb3NhbCBpcyBleHByZXNzZWQgaW4gZXZlci1pbmNyZWFzaW5n IG9mZnNldHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+T3RoZXJ3 aXNlLCBsb29rcyBnb29kLiBUaGlzIHdvdWxkIGZhbGwgdW5kZXIgdGhlIOKAmGFsbG93IG1vcmUg YnVmZmVyaW5nIGF0IHRoZSBhcHBsaWNhdGlvbuKAmSBidWxsZXQgTWFydGluIGhhZCwgYnV0IEkg YmVsaWV2ZSB0aGF0IGlzIGEgcmVhc29uYWJsZSB0aGluZyB0byBkbyBpZiBpdCBpcyBjb25zdHJh aW5lZCBhbmQgZGlyZWN0ZWQgYnkgdGhlIGFwcGxpY2F0aW9uDQogKHdoaWNoIGNvdWxkIGRlY2lk ZSB0byBjYW5jZWwgYSBzdHJlYW0gdG9vKS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+U2luY2UgZmxvdyBjb250cm9s IGlzIGUyZSwgdGhpcyBkb2VzbuKAmXQgaW1wYWN0IG1lbW9yeSBhdCBhIHByb3h5LjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FeGFjdGx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDps MyBsZXZlbDEgbGZvMyI+V2hhdCB0aGlzIGRvZXNu4oCZdCBzb2x2ZSBpcyB0aGUgZGV0ZWN0aW9u IHByb2JsZW0uPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBsb29rIGF0IG15 IGZvbGxvdy11cCBwcm9wb3NhbCAod2hpY2ggaXMgZWZmZWN0aXZlbHkgY2hhbmdpbmcgdGhlIG1l YW5pbmcgb2YgbWF4X3N0cmVhbV9kYXRhIHRvIG1lYW4gc3RyZWFtX2RhdGFfY3JlZGl0KSwgeW91 IG1heSBub3QgbmVlZCB0byBoYXZlIHJvYnVzdCBkZWFkbG9jayBkZXRlY3Rpb24sIGJlY2F1c2Ug ZGVhZGxvY2tzIGR1ZSB0byB0cmFuc3BvcnQgY2Fubm90IGhhcHBlbi4mbmJzcDsgVGhlIG9ubHkN CiBkZWFkbG9ja3MgcG9zc2libGUgd2l0aCB0aGUgZm9sbG93LXVwIHNjaGVtZSBhcmUgZGVhZGxv Y2tzIGR1ZSB0byB0aGUgYXBwbGljYXRpb27igJlzIGNpcmN1bGFyIGRlcGVuZGVuY3ksIG5vdCBz ZW5kZXLigJlzIGNob2ljZSBvZiB3aGljaCBzdHJlYW0gdG8gc2VuZCBmaXJzdDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLT1SPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDsgb24gYmVoYWxmIG9mICZxdW90O0x1YmFzaGV2LCBJZ29yJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIEphbnVhcnkgMjMsIDIwMTggYXQgMjo1MCBQTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0Bp ZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQu ZWR1Ij5pZ29ybG9yZEBhbHVtLm1pdC5lZHU8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86 aWdvcmxvcmRAYWx1bS5taXQuZWR1Ij5pZ29ybG9yZEBhbHVtLm1pdC5lZHU8L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6IDwvYj5EZWFkbG9jayBhdm9pZGFuY2UgcHJvcG9zYWw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHByb2JsZW0gd2l0 aCBkZWFkbG9ja2luZyBRVUlDIHN0cmVhbXMgaXMgdGhlIHBvc3NpYmlsaXR5IHRoYXQgdGhlIHNl bmRlciAob3IgcHJveHkpIHdpbGwg4oCcdXNlIHVw4oCdIGNvbm5lY3Rpb24gZmxvdyBjb250cm9s IGNyZWRpdHMgb24gbG93ZXItcHJpb3JpdHkgc3RyZWFtcywgYmxvY2tpbmcgdGhlIHJlY2VpdmVy IGZyb20gbWFraW5nIGZvcndhcmQgcHJvZ3Jlc3Mgd2l0aCBhbnkgc3RyZWFtcy4mbmJzcDsgVGhl IHJlY2VpdmVyDQogaGFzIG5vIG1lY2hhbmlzbSB0byBkaXJlY3QvZm9yY2UgdGhlIHNlbmRlciB0 byBzZW5kIG9uIHByZWZlcnJlZCBzdHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdv dWxkIGxpa2UgdG8gcHJvcG9zZSBhIGNvbmNlcHQgb2Yg4oCcc3RyZWFtIGRhdGEgY3JlZGl04oCd IOKAkyB0aGUgY29uY2VwdCBvZiBleHRyYSBmbG93IGNvbnRyb2wgY3JlZGl0cyB0aGF0IGNhbiBv bmx5IGJlIHVzZWQgYnkgYSBzcGVjaWZpYyBzdHJlYW0uJm5ic3A7IEEgU1RSRUFNX0RBVEFfQ1JF RElUIGZyYW1lIHdvdWxkIHVwZGF0ZSBzdWNoIGNyZWRpdHMgKHNlZSBiZWxvdykuJm5ic3A7IERh dGEgc2VudCBvbiBhIHN0cmVhbQ0KIHdpbGwgY29uc3VtZSBpdHMgb3duIGNyZWRpdHMgYXMgbXVj aCBhcyBpdCBjYW4gYW5kIGNvbm5lY3Rpb24gY3JlZGl0cyAodXBkYXRlZCBieSBNQVhfREFUQSkg Zm9yIHRoZSByZXN0IG9mIHRoZSBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdXBk YXRlZCBjb25uZWN0aW9uIGZsb3cgY29udHJvbCBhY2NvdW50aW5nOiZuYnNwOyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3IgZWFjaCBzdHJlYW0sIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIGlzIOKAnE1BWCh0 aGVfbGFyZ2VzdF9yZWNlaXZlZF9vZmZzZXQgLSBzdHJlYW1fZGF0YV9jcmVkaXRzLCAwKeKAnS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHN1bSBvZiDigJx1c2VkIGNvbm5lY3Rpb24gY3Jl ZGl0c+KAnSBvbiBhbGwgc3RyZWFtcyAtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5pbmNsdWRpbmcgc3RyZWFtcyBpbiB0ZXJtaW5hbCBzdGF0ZXMsIGJ1dCBleGNsdWRpbmcg c3RyZWFtIDAgLSBNVVNUIE5PVCBleGNlZWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRoZSB2YWx1ZSBhZHZlcnRpc2VkIGJ5IGEgcmVjZWl2ZXIgKGkuZS4gTUFYX0RBVEEp LiZuYnNwOyBBbiBlbmRwb2ludCBNVVNUIHRlcm1pbmF0ZSBhIGNvbm5lY3Rpb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndpdGggYSBRVUlDX0ZMT1dfQ09OVFJPTF9SRUNF SVZFRF9UT09fTVVDSF9EQVRBIGVycm9yIGlmIGl0IHVzZWQgbW9yZSBjb25uZWN0aW9uIGNyZWRp dHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW4gdGhlIG1heGltdW0g ZGF0YSB2YWx1ZSB0aGF0IGl0IGhhcyBzZW50LCB1bmxlc3MgdGhpcyBpcyBhIHJlc3VsdCBvZiBh PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jaGFuZ2UgaW4gdGhlIGluaXRp YWwgbGltaXRzIChzZWUge3t6ZXJvcnR0LXBhcmFtZXRlcnN9fSkuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj7igJw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHJlY2Vp dmVyIHdpbGwgYmUgYWJsZSB0byBncmFudCBkZWRpY2F0ZWQgY3JlZGl0cyB0byB0aGUgaGlnaC1w cmlvcml0eSBzdHJlYW0gdy9vIHJlcXVpcmluZyB0aGUgc2VuZGVyIG9yIHRoZSBpbnRlcm1lZGlh cnkgdG8ga25vdyBhbnl0aGluZyBhYm91dCB0aGUgc2VtYW50aWNzIG9mIHRoZSBwcm90b2NvbCBh bmQgd2l0aG91dCB3b3JyeWluZyB0aGF0IHRoZSBzZW5kZXIvaW50ZXJtZWRpYXJ5IHdpbGwg4oCc c3F1YW5kZXLigJ0NCiB0aGUgY3JlZGl0cyBvbiB1bmltcG9ydGFudCBzdHJlYW1zLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNUUkVBTV9EQVRB X0NSRURJVCBmcmFtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZyYW1lIHVwZGF0ZXMg RGF0YSBDcmVkaXQgZm9yIGEgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+fn48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnwm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU3RyZWFtIElEIChpKSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGEgQ3JlZGl0IChpKSZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+fn48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZpZWxkcyBpbiB0aGUgU1RSRUFNX0RBVEFfQ1JF RElUIGZyYW1lIGFyZSBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdHJlYW0g SUQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjogVGhlIHN0cmVhbSBJRCBvZiB0aGUgc3RyZWFt IHRoYXQgaXMgYWZmZWN0ZWQgZW5jb2RlZCBhcyBhIHZhcmlhYmxlLWxlbmd0aDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGludGVnZXIuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRhdGEgQ3JlZGl0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj46IEEgdmFyaWFi bGUtbGVuZ3RoIGludGVnZXIgaW5kaWNhdGluZyB0aGUgbmV3IHRvdGFsIGRhdGEgY3JlZGl0IGZv ciB0aGUgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZWFjaCBzdHJlYW0gRGF0 YSBDcmVkaXQgc3RhcnRzIHdpdGggMC4mbmJzcDsgVGhlIHNlbmRlciBjYW4gb25seSBpbmNyZWFz ZSBEYXRhIENyZWRpdCBpbiBzdWJzZXF1ZW50IFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMgZm9y IHRoZSBzYW1lIHN0cmVhbSwgYnV0IGxvc3MgYW5kIHJlb3JkZXJpbmcgY2FuIGNhdXNlIFNUUkVB TV9EQVRBX0NSRURJVCBmcmFtZXMgdG8gYmUgcmVjZWl2ZWQgb3V0IG9mIG9yZGVyLiZuYnNwOw0K IFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMgdGhhdCBkbyBub3QgYWR2YW5jZSBEYXRhIENyZWRp dCBmb3IgdGhlIHN0cmVhbSBNVVNUIGJlIGlnbm9yZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudHM/PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsMCBsZXZlbDEgbGZvOCI+SWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_b3f1ddd3678c49fea41c3082e3113f91usma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 16:00:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F9312D94B for ; Tue, 23 Jan 2018 16:00:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.301 X-Spam-Level: ** X-Spam-Status: No, score=2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 wEc_uB1wyuk0 for ; Tue, 23 Jan 2018 16:00:22 -0800 (PST) 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 3B4B612D890 for ; Tue, 23 Jan 2018 16:00:22 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0NNueeU027507; Wed, 24 Jan 2018 00:00:17 GMT 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=XNq8fqN7iEcL9VVl6k0SWmcD9oYdsQ2/wRsYcqZLiZg=; b=THrYRLaTgsm1LcrnA8xqsXxYLVhTThbgWn1vj493sAxZ768vCp+2Rlwi3a6sJ+4FfeBC l+cfDHBTb2GA/VZOcQZkpXf7uPQvsMYNoDd0OS2s5YUm7pQDqpBSiobiG9/S3EoeFuzg j18rbqMA05aNtHfxOCeI/128rePp2No23JjP0DjxDhemDdZeIkuOM80PfA14T3e/uBp9 BP+v2xEyNMmKgovEtD12OKmzB/EMV3avwPjy+Rtqp+7hL8sw+IRf0kLNyWK/EZtI8vw9 kySgNJCAPTPUSsuHBq6JrPizyXWHVmqEm2JXQWOwucc/AR3XZIY1UOmxsTqiUSqXvXmZ vQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgwrx21-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 00:00:16 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0NNpGEr000391; Tue, 23 Jan 2018 19:00:16 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ekdj7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 19:00:15 -0500 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; Tue, 23 Jan 2018 19:00:15 -0500 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; Tue, 23 Jan 2018 19:00:15 -0500 From: "Lubashev, Igor" To: "Lubashev, Igor" , Roberto Peon , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: RE: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgIAAtfbggAFoUYA= Date: Wed, 24 Jan 2018 00:00:14 +0000 Message-ID: <342bb1fcee94445ca714a71f1b3e01fd@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5086f27b81f74a1cad90555d25c227b3@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.38.42] Content-Type: multipart/alternative; boundary="_000_342bb1fcee94445ca714a71f1b3e01fdusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230305 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_08:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801230306 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 00:00:25 -0000 --_000_342bb1fcee94445ca714a71f1b3e01fdusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2UgbXVzdCBhc3N1bWUgdGhhdCBhbnkgZmluaXRlIGJ1ZmZlciBjYW4gYmUgY29uc3Vt ZWQuIFRodXMsIGFueSBwYXJ0aXRpb25pbmcgb2YgdGhlIGF2YWlsYWJsZSBtZW1vcnkgd2hpY2gg aXMgZmluaXRlIGNhbm5vdCBwcmV2ZW50IHRoaXMgZnJvbSBvY2N1cnJpbmcuIFdoZW4gaXQgb2Nj dXJzLCBpdCBtYXkgaW5kdWNlIGluZGVmaW5pdGUgaGVhZC1vZi1saW5lLWJsb2NraW5nIG9uIGFs bCBmbG93LWNvbnRyb2xsZWQgdXBzdHJlYW0gbm9kZXMgaW4gdGhlIHRvcG9sb2d5Lg0KDQpUbyBi ZSBtb3JlIHNwZWNpZmljLCDigJxpdCBtYXkgaW5kdWNlIGluZGVmaW5pdGUgaGVhZC1vZi1saW5l LWJsb2NraW5nIG9uIGFsbCBmbG93LWNvbnRyb2xsZWQgdXBzdHJlYW0gbm9kZXMgaW4gdGhlIHRv cG9sb2d54oCdIGlzIGluY29ycmVjdC4gIOKAnEluZGVmaW5pdGXigJ0gYmxvY2tpbmcgbWVhbnMg ZGVhZGxvY2suICBIT0wgYmxvY2tpbmcg4oCTIHBvc3NpYmxlOyBkZWFkbG9jayDigJMgbm8uDQoN CkEgZGVhZGxvY2sgaXMgd2hlbiBOTyBzdHJlYW0gY2FuIG1ha2UgYW55IHByb2dyZXNzIHdpdGhv dXQga2lsbGluZyBzb21lIHN0cmVhbS4gIElmIGVhY2ggc3RyZWFtIGhhcyDigJxkZWRpY2F0ZWTi gJ0gbWVtb3J5IGJ1ZmZlciAob3IgdGhlIGNsaWVudCBpcyB3aWxsaW5nIHRvIGRlZGljYXRlIGEg bWVtb3J5IGJ1ZmZlciB0byB0aGUgaGlnaGVzdC1wcmlvcml0eSBibG9ja2VkIHN0cmVhbSksIHRo ZSBoaWdoZXN0LXByaW9yaXR5IHN0cmVhbSB3aWxsIG5vdCBibG9jayDigJMgdGhlIHJlY2VpdmVy IHdpbGwgY29uc3VtZSBpdCwgZnJlZSB0aGF0IHN0cmVhbS1wcml2YXRlIGJ1ZmZlciwgYW5kIHNl bmRlciB3aWxsIHNlbmQgbW9yZSBkYXRhIHRvIHRoYXQgc3RyZWFtLg0KDQoNCiAgKiAgIElnb3IN Cg0KDQoNCkZyb206IEx1YmFzaGV2LCBJZ29yIFttYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMjMsIDIwMTggNjo1MSBQTQ0KVG86IFJvYmVydG8gUGVv biA8ZmVuaXhAZmIuY29tPjsgcXVpY0BpZXRmLm9yZzsgaWdvcmxvcmRAYWx1bS5taXQuZWR1DQpT dWJqZWN0OiBSRTogRGVhZGxvY2sgYXZvaWRhbmNlIHByb3Bvc2FsDQoNCklmIHlvdSBoYXZlIGZp bml0ZSBidWZmZXIgbWVtb3J5IEFORCBhbGxvdyBhbGwgb2YgdGhhdCBidWZmZXIgbWVtb3J5IHRv IGJlIHVzZWQgZm9yIGFueSBzdHJlYW0sIHlvdSBjYW5ub3QgYXZvaWQgZGVhZGxvY2tzLiAgSG93 ZXZlciwgaWYgeW91IGRlZGljYXRlIHNvbWUgYnVmZmVyIG1lbW9yeSB0byBlYWNoIHN0cmVhbSAo ZG9lcyBub3QgbmVlZCB0byBiZSBtdWNoIOKAkyBqdXN0IG5lZWRzIHRvIGJlIGVub3VnaCBmb3Ig b25lIOKAnG1lc3NhZ2XigJ0pLCB5b3UgY2FuIGFsd2F5cyBtYWtlIHByb2dyZXNzIG9uIHlvdXIg aGlnaGVzdC1wcmlvcml0eSBzdHJlYW0uDQoNClRoZSB0cmFkZS1vZmYgaXMgdGhhdCBzb21lIG1l bW9yeSBtYXkgZW5kIHVwIHVudXNlZCAobWVtb3J5IGRlZGljYXRlZCB0byBzdHJlYW1zIHRoYXQg ZG8gbm90IGhhdmUgYW55dGhpbmcgdG8gc2VuZCkuDQoNCklmIHlvdSB3YW50IHRvIGluY3JlYXNl IHlvdXIgbWVtb3J5IHV0aWxpemF0aW9uIGV2ZW4gZnVydGhlciwgeW91IG1heSBlbmQgdXAgZG9p bmcgYmxvY2tlZC1zdHJlYW0gZGV0ZWN0aW9uIChyZXNwb25kaW5nIHRvIFNUUkVBTV9CTE9DS0VE IGZyYW1lcykgYW5kIGdpdmUgZXh0cmEgbWVtb3J5IHRvIHRob3NlIHN0cmVhbXMg4oCcanVzdC1p bi10aW1l4oCdLg0KDQotIElnb3INCg0KRnJvbTogUm9iZXJ0byBQZW9uIFttYWlsdG86ZmVuaXhA ZmIuY29tXQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyMywgMjAxOCA2OjM0IFBNDQpUbzogTHVi YXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20+PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz47IGlnb3Jsb3JkQGFsdW0u bWl0LmVkdTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1Pg0KU3ViamVjdDogUmU6IERlYWRs b2NrIGF2b2lkYW5jZSBwcm9wb3NhbA0KDQpXZSBtdXN0IGFzc3VtZSB0aGF0IGFueSBmaW5pdGUg YnVmZmVyIGNhbiBiZSBjb25zdW1lZC4gVGh1cywgYW55IHBhcnRpdGlvbmluZyBvZiB0aGUgYXZh aWxhYmxlIG1lbW9yeSB3aGljaCBpcyBmaW5pdGUgY2Fubm90IHByZXZlbnQgdGhpcyBmcm9tIG9j Y3VycmluZy4gV2hlbiBpdCBvY2N1cnMsIGl0IG1heSBpbmR1Y2UgaW5kZWZpbml0ZSBoZWFkLW9m LWxpbmUtYmxvY2tpbmcgb24gYWxsIGZsb3ctY29udHJvbGxlZCB1cHN0cmVhbSBub2RlcyBpbiB0 aGUgdG9wb2xvZ3kuDQoNCkluIG90aGVyIHdvcmRzLCB0aGUgcHJvYmxlbSBpcyBub3QgcHJldmVu dGFibGUgd2l0aCBhbnkgbWVjaGFuaXNtIHdlIGludHJvZHVjZSB3aXRoaW4gdGhlIHByb3RvY29s LiBBdCBiZXN0IHdlIGNhbiBtYWtlIGl0IGRldGVjdGFibGUgYW5kIHByb3ZpZGUgbWVjaGFuaXNt cyB0byBsaW1pdCB0aGUgZGFtYWdlIHdoZW4gaXQgaGFwcGVucy4NCg0KVGhlIHN0cmVhbS1kYXRh LWNyZWRpdCBzdHVmZiBpcyBhIGdvb2QgbWVjaGFuaXNtIHRvIGxpbWl0IHRoZSBkYW1hZ2Ugd2hp bGUgc3RpbGwgYWxsb3dpbmcgZm9yIGZpbml0ZSBtZW1vcnkgdXNlLCBidXQgaXQgaXMgdXNlZnVs IG9ubHkgd2hlbi9pZiBhbiBhcHBsaWNhdGlvbiBrbm93cyB0aGF0IHNvbWUgYWN0aW9uIGlzIHJl cXVpcmVkLg0KDQpUaGVyZSBhcmUgYWx0ZXJuYXRlIG1lY2hhbmlzbXMgdGhhdCB3b3VsZCBhbHNv IGJlIHVzZWZ1bDogY2FuY2VsbGluZyBhIHN0cmVhbSwgZm9yIGluc3RhbmNlLg0KLT1SDQpwLnMu IHRoZSByZWFsIHByb2JsZW0gaXMgdGhhdCB3ZeKAmXZlIGRlbGVnYXRlZCB0aGUgb3duZXJzaGlw IG9mIHRoZSBkYXRhIHRvIHRoZSBpbnRlcm1lZGlhcnkgYnkgYWxsb3dpbmcgdGhlIHNlbmRlciB0 byBmbHVzaCBpdHMgYnl0ZXMgdXBvbiByZWNlaXZpbmcgcDJwIGFja3MuIFRoZSBiZXN0IHNvbHV0 aW9uIGhlcmUgd291bGQgYmUgZTJlIGFja3MgKHdoZXRoZXIgYXBwbGljYXRpb24tbGF5ZXIgb3Ig dHJhbnNwb3J0IG9yIGJvdGgpLg0KDQpGcm9tOiAiTHViYXNoZXYsIElnb3IiIDxpbHViYXNoZUBh a2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwg SmFudWFyeSAyNCwgMjAxOCBhdCA5OjA4IEFNDQpUbzogUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5j b208bWFpbHRvOmZlbml4QGZiLmNvbT4+LCAicXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRm Lm9yZz4iIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4sICJpZ29ybG9yZEBh bHVtLm1pdC5lZHU8bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4iIDxpZ29ybG9yZEBhbHVt Lm1pdC5lZHU8bWFpbHRvOmlnb3Jsb3JkQGFsdW0ubWl0LmVkdT4+DQpTdWJqZWN0OiBSRTogRGVh ZGxvY2sgYXZvaWRhbmNlIHByb3Bvc2FsDQoNCg0KICAqICAgVGhlIHN0cmVhbS1kYXRhLWNyZWRp dCB3b3VsZCBuZWVkIHRvIGJlIGV4cHJlc3NlZCBhcyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVz b2x2ZXMgdGhlIHJhY2VzIGFuZCBhbGxvd3MgdGhlIG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0 byB3b3JrIHByb3Blcmx5KS4gSSBzdXNwZWN0IHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBpbiB0aGUg Zmlyc3QgcGxhY2UuDQoNClllcywgdGhlIHN0cmVhbS1kYXRhLWNyZWRpdCBpbiB0aGlzIHByb3Bv c2FsIGlzIGV4cHJlc3NlZCBpbiBldmVyLWluY3JlYXNpbmcgb2Zmc2V0cy4NCg0KDQogICogICBP dGhlcndpc2UsIGxvb2tzIGdvb2QuIFRoaXMgd291bGQgZmFsbCB1bmRlciB0aGUg4oCYYWxsb3cg bW9yZSBidWZmZXJpbmcgYXQgdGhlIGFwcGxpY2F0aW9u4oCZIGJ1bGxldCBNYXJ0aW4gaGFkLCBi dXQgSSBiZWxpZXZlIHRoYXQgaXMgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRvIGlmIGl0IGlzIGNv bnN0cmFpbmVkIGFuZCBkaXJlY3RlZCBieSB0aGUgYXBwbGljYXRpb24gKHdoaWNoIGNvdWxkIGRl Y2lkZSB0byBjYW5jZWwgYSBzdHJlYW0gdG9vKS4NCiAgKiAgIFNpbmNlIGZsb3cgY29udHJvbCBp cyBlMmUsIHRoaXMgZG9lc27igJl0IGltcGFjdCBtZW1vcnkgYXQgYSBwcm94eS4NCg0KRXhhY3Rs eQ0KDQoNCiAgKiAgIFdoYXQgdGhpcyBkb2VzbuKAmXQgc29sdmUgaXMgdGhlIGRldGVjdGlvbiBw cm9ibGVtLg0KDQpJZiB5b3UgbG9vayBhdCBteSBmb2xsb3ctdXAgcHJvcG9zYWwgKHdoaWNoIGlz IGVmZmVjdGl2ZWx5IGNoYW5naW5nIHRoZSBtZWFuaW5nIG9mIG1heF9zdHJlYW1fZGF0YSB0byBt ZWFuIHN0cmVhbV9kYXRhX2NyZWRpdCksIHlvdSBtYXkgbm90IG5lZWQgdG8gaGF2ZSByb2J1c3Qg ZGVhZGxvY2sgZGV0ZWN0aW9uLCBiZWNhdXNlIGRlYWRsb2NrcyBkdWUgdG8gdHJhbnNwb3J0IGNh bm5vdCBoYXBwZW4uICBUaGUgb25seSBkZWFkbG9ja3MgcG9zc2libGUgd2l0aCB0aGUgZm9sbG93 LXVwIHNjaGVtZSBhcmUgZGVhZGxvY2tzIGR1ZSB0byB0aGUgYXBwbGljYXRpb27igJlzIGNpcmN1 bGFyIGRlcGVuZGVuY3ksIG5vdCBzZW5kZXLigJlzIGNob2ljZSBvZiB3aGljaCBzdHJlYW0gdG8g c2VuZCBmaXJzdA0KDQotPVINCg0KDQpGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiTHViYXNoZXYsIEln b3IiIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj4NCkRh dGU6IFR1ZXNkYXksIEphbnVhcnkgMjMsIDIwMTggYXQgMjo1MCBQTQ0KVG86ICJxdWljQGlldGYu b3JnPG1haWx0bzpxdWljQGlldGYub3JnPiIgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+PiwgImlnb3Jsb3JkQGFsdW0ubWl0LmVkdTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQu ZWR1PiIgPGlnb3Jsb3JkQGFsdW0ubWl0LmVkdTxtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1 Pj4NClN1YmplY3Q6IERlYWRsb2NrIGF2b2lkYW5jZSBwcm9wb3NhbA0KDQpUaGUgcHJvYmxlbSB3 aXRoIGRlYWRsb2NraW5nIFFVSUMgc3RyZWFtcyBpcyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUg c2VuZGVyIChvciBwcm94eSkgd2lsbCDigJx1c2UgdXDigJ0gY29ubmVjdGlvbiBmbG93IGNvbnRy b2wgY3JlZGl0cyBvbiBsb3dlci1wcmlvcml0eSBzdHJlYW1zLCBibG9ja2luZyB0aGUgcmVjZWl2 ZXIgZnJvbSBtYWtpbmcgZm9yd2FyZCBwcm9ncmVzcyB3aXRoIGFueSBzdHJlYW1zLiAgVGhlIHJl Y2VpdmVyIGhhcyBubyBtZWNoYW5pc20gdG8gZGlyZWN0L2ZvcmNlIHRoZSBzZW5kZXIgdG8gc2Vu ZCBvbiBwcmVmZXJyZWQgc3RyZWFtcy4NCg0KSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgYSBjb25j ZXB0IG9mIOKAnHN0cmVhbSBkYXRhIGNyZWRpdOKAnSDigJMgdGhlIGNvbmNlcHQgb2YgZXh0cmEg ZmxvdyBjb250cm9sIGNyZWRpdHMgdGhhdCBjYW4gb25seSBiZSB1c2VkIGJ5IGEgc3BlY2lmaWMg c3RyZWFtLiAgQSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUgd291bGQgdXBkYXRlIHN1Y2ggY3Jl ZGl0cyAoc2VlIGJlbG93KS4gIERhdGEgc2VudCBvbiBhIHN0cmVhbSB3aWxsIGNvbnN1bWUgaXRz IG93biBjcmVkaXRzIGFzIG11Y2ggYXMgaXQgY2FuIGFuZCBjb25uZWN0aW9uIGNyZWRpdHMgKHVw ZGF0ZWQgYnkgTUFYX0RBVEEpIGZvciB0aGUgcmVzdCBvZiB0aGUgZGF0YS4NCg0KVGhlIHVwZGF0 ZWQgY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgYWNjb3VudGluZzoNCg0K4oCcDQpGb3IgZWFjaCBz dHJlYW0sIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIGlzIOKAnE1BWCh0aGVfbGFyZ2Vz dF9yZWNlaXZlZF9vZmZzZXQgLSBzdHJlYW1fZGF0YV9jcmVkaXRzLCAwKeKAnS4NCg0KVGhlIHN1 bSBvZiDigJx1c2VkIGNvbm5lY3Rpb24gY3JlZGl0c+KAnSBvbiBhbGwgc3RyZWFtcyAtDQppbmNs dWRpbmcgc3RyZWFtcyBpbiB0ZXJtaW5hbCBzdGF0ZXMsIGJ1dCBleGNsdWRpbmcgc3RyZWFtIDAg LSBNVVNUIE5PVCBleGNlZWQNCnRoZSB2YWx1ZSBhZHZlcnRpc2VkIGJ5IGEgcmVjZWl2ZXIgKGku ZS4gTUFYX0RBVEEpLiAgQW4gZW5kcG9pbnQgTVVTVCB0ZXJtaW5hdGUgYSBjb25uZWN0aW9uDQp3 aXRoIGEgUVVJQ19GTE9XX0NPTlRST0xfUkVDRUlWRURfVE9PX01VQ0hfREFUQSBlcnJvciBpZiBp dCB1c2VkIG1vcmUgY29ubmVjdGlvbiBjcmVkaXRzDQp0aGFuIHRoZSBtYXhpbXVtIGRhdGEgdmFs dWUgdGhhdCBpdCBoYXMgc2VudCwgdW5sZXNzIHRoaXMgaXMgYSByZXN1bHQgb2YgYQ0KY2hhbmdl IGluIHRoZSBpbml0aWFsIGxpbWl0cyAoc2VlIHt7emVyb3J0dC1wYXJhbWV0ZXJzfX0pLg0K4oCc DQoNClRoZSByZWNlaXZlciB3aWxsIGJlIGFibGUgdG8gZ3JhbnQgZGVkaWNhdGVkIGNyZWRpdHMg dG8gdGhlIGhpZ2gtcHJpb3JpdHkgc3RyZWFtIHcvbyByZXF1aXJpbmcgdGhlIHNlbmRlciBvciB0 aGUgaW50ZXJtZWRpYXJ5IHRvIGtub3cgYW55dGhpbmcgYWJvdXQgdGhlIHNlbWFudGljcyBvZiB0 aGUgcHJvdG9jb2wgYW5kIHdpdGhvdXQgd29ycnlpbmcgdGhhdCB0aGUgc2VuZGVyL2ludGVybWVk aWFyeSB3aWxsIOKAnHNxdWFuZGVy4oCdIHRoZSBjcmVkaXRzIG9uIHVuaW1wb3J0YW50IHN0cmVh bXMuDQoNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lLg0K DQpUaGUgZnJhbWUgdXBkYXRlcyBEYXRhIENyZWRpdCBmb3IgYSBzdHJlYW0uDQoNCn5+fg0KMCAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAg Mw0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgIFN0cmVhbSBJRCAo aSkgICAgICAgICAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAg ICAgICAgICAgRGF0YSBDcmVkaXQgKGkpICAgICAgICAgICAgICAgICAgICAgICAgLi4uDQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0Kfn5+DQoNClRoZSBmaWVsZHMgaW4gdGhlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZSBh cmUgYXMgZm9sbG93czoNCg0KU3RyZWFtIElEOg0KDQo6IFRoZSBzdHJlYW0gSUQgb2YgdGhlIHN0 cmVhbSB0aGF0IGlzIGFmZmVjdGVkIGVuY29kZWQgYXMgYSB2YXJpYWJsZS1sZW5ndGgNCiAgaW50 ZWdlci4NCg0KRGF0YSBDcmVkaXQ6DQoNCjogQSB2YXJpYWJsZS1sZW5ndGggaW50ZWdlciBpbmRp Y2F0aW5nIHRoZSBuZXcgdG90YWwgZGF0YSBjcmVkaXQgZm9yIHRoZSBzdHJlYW0uDQoNCkZvciBl YWNoIHN0cmVhbSBEYXRhIENyZWRpdCBzdGFydHMgd2l0aCAwLiAgVGhlIHNlbmRlciBjYW4gb25s eSBpbmNyZWFzZSBEYXRhIENyZWRpdCBpbiBzdWJzZXF1ZW50IFNUUkVBTV9EQVRBX0NSRURJVCBm cmFtZXMgZm9yIHRoZSBzYW1lIHN0cmVhbSwgYnV0IGxvc3MgYW5kIHJlb3JkZXJpbmcgY2FuIGNh dXNlIFNUUkVBTV9EQVRBX0NSRURJVCBmcmFtZXMgdG8gYmUgcmVjZWl2ZWQgb3V0IG9mIG9yZGVy LiAgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyB0aGF0IGRvIG5vdCBhZHZhbmNlIERhdGEgQ3Jl ZGl0IGZvciB0aGUgc3RyZWFtIE1VU1QgYmUgaWdub3JlZC4NCg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cg0KDQpDb21tZW50cz8NCg0KDQogICogICBJZ29yDQo= --_000_342bb1fcee94445ca714a71f1b3e01fdusma1exdag1mb5msgcorpak_ 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 b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9y bWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGww DQoJe21zby1saXN0LWlkOjg1NDI0MTE0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA1NDIx MDAyNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjk5MjIzODMzOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczoxNjc1MzkxNDEyO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxp c3QtaWQ6MTc2MzA4Nzk0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMjkyMTI0MDgyIDIxMzM5MDQ5OTIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlz dC1pZDo1NDMyOTQ5NDQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjc1NzMzOTA5MiAtOTUzMDkzOTAyIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwzOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwzOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTAwNTEz Mzg3NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM1MTYzMjA4Mjt9DQpAbGlzdCBsNDpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0Omxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw1DQoJe21zby1saXN0LWlkOjEwNDAyMDY2ODE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04 NDAxNDQ1NzA7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNg0KCXttc28tbGlzdC1pZDoxMTAyMzM1NzM5Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo3NzE4MTYwNDAg LTE2ODE3MjUwMDQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDY6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNjpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw2OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDY6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsNjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNw0KCXttc28tbGlzdC1pZDoxOTU4MjIwOTE2Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMzE1MzMzODE2 IDI1NzQ4NjI0MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDc6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNzpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGw3OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDc6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0Mx IiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzkiPldlIG11 c3QgYXNzdW1lIHRoYXQgYW55IGZpbml0ZSBidWZmZXIgY2FuIGJlIGNvbnN1bWVkLiBUaHVzLCBh bnkgcGFydGl0aW9uaW5nIG9mIHRoZSBhdmFpbGFibGUgbWVtb3J5IHdoaWNoIGlzIGZpbml0ZSBj YW5ub3QgcHJldmVudCB0aGlzIGZyb20gb2NjdXJyaW5nLiBXaGVuIGl0IG9jY3VycywgaXQgbWF5 IGluZHVjZQ0KIGluZGVmaW5pdGUgaGVhZC1vZi1saW5lLWJsb2NraW5nIG9uIGFsbCBmbG93LWNv bnRyb2xsZWQgdXBzdHJlYW0gbm9kZXMgaW4gdGhlIHRvcG9sb2d5LjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UbyBiZSBtb3JlIHNwZWNpZmljLCDigJxpdCBtYXkgaW5kdWNlIGluZGVm aW5pdGUgaGVhZC1vZi1saW5lLWJsb2NraW5nIG9uIGFsbCBmbG93LWNvbnRyb2xsZWQgdXBzdHJl YW0gbm9kZXMgaW4gdGhlIHRvcG9sb2d54oCdIGlzIGluY29ycmVjdC4mbmJzcDsg4oCcSW5kZWZp bml0ZeKAnSBibG9ja2luZyBtZWFucyBkZWFkbG9jay4mbmJzcDsgSE9MIGJsb2NraW5nIOKAkyBw b3NzaWJsZTsgZGVhZGxvY2sg4oCTIG5vLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGRlYWRs b2NrIGlzIHdoZW4gTk8gc3RyZWFtIGNhbiBtYWtlIGFueSBwcm9ncmVzcyB3aXRob3V0IGtpbGxp bmcgc29tZSBzdHJlYW0uJm5ic3A7IElmIGVhY2ggc3RyZWFtIGhhcyDigJxkZWRpY2F0ZWTigJ0g bWVtb3J5IGJ1ZmZlciAob3IgdGhlIGNsaWVudCBpcyB3aWxsaW5nIHRvIGRlZGljYXRlIGEgbWVt b3J5IGJ1ZmZlciB0byB0aGUgaGlnaGVzdC1wcmlvcml0eSBibG9ja2VkIHN0cmVhbSksIHRoZSBo aWdoZXN0LXByaW9yaXR5DQogc3RyZWFtIHdpbGwgbm90IGJsb2NrIOKAkyB0aGUgcmVjZWl2ZXIg d2lsbCBjb25zdW1lIGl0LCBmcmVlIHRoYXQgc3RyZWFtLXByaXZhdGUgYnVmZmVyLCBhbmQgc2Vu ZGVyIHdpbGwgc2VuZCBtb3JlIGRhdGEgdG8gdGhhdCBzdHJlYW0uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBsZm8xMCI+SWdvcjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBMdWJhc2hldiwg SWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBKYW51YXJ5IDIzLCAyMDE4IDY6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydG8gUGVv biAmbHQ7ZmVuaXhAZmIuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzsgaWdvcmxvcmRAYWx1bS5taXQu ZWR1PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBEZWFkbG9jayBhdm9pZGFuY2UgcHJvcG9zYWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBoYXZlIGZpbml0 ZSBidWZmZXIgbWVtb3J5IEFORCBhbGxvdyBhbGwgb2YgdGhhdCBidWZmZXIgbWVtb3J5IHRvIGJl IHVzZWQgZm9yIGFueSBzdHJlYW0sIHlvdSBjYW5ub3QgYXZvaWQgZGVhZGxvY2tzLiZuYnNwOyBI b3dldmVyLCBpZiB5b3UgZGVkaWNhdGUgc29tZSBidWZmZXIgbWVtb3J5IHRvIGVhY2ggc3RyZWFt IChkb2VzIG5vdCBuZWVkIHRvIGJlIG11Y2gg4oCTIGp1c3QgbmVlZHMgdG8gYmUgZW5vdWdoDQog Zm9yIG9uZSDigJxtZXNzYWdl4oCdKSwgeW91IGNhbiBhbHdheXMgbWFrZSBwcm9ncmVzcyBvbiB5 b3VyIGhpZ2hlc3QtcHJpb3JpdHkgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg dHJhZGUtb2ZmIGlzIHRoYXQgc29tZSBtZW1vcnkgbWF5IGVuZCB1cCB1bnVzZWQgKG1lbW9yeSBk ZWRpY2F0ZWQgdG8gc3RyZWFtcyB0aGF0IGRvIG5vdCBoYXZlIGFueXRoaW5nIHRvIHNlbmQpLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugd2FudCB0byBpbmNyZWFzZSB5b3VyIG1lbW9y eSB1dGlsaXphdGlvbiBldmVuIGZ1cnRoZXIsIHlvdSBtYXkgZW5kIHVwIGRvaW5nIGJsb2NrZWQt c3RyZWFtIGRldGVjdGlvbiAocmVzcG9uZGluZyB0byBTVFJFQU1fQkxPQ0tFRCBmcmFtZXMpIGFu ZCBnaXZlIGV4dHJhIG1lbW9yeSB0byB0aG9zZSBzdHJlYW1zIOKAnGp1c3QtaW4tdGltZeKAnS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJZ29yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0byBQZW9u IFs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIj5tYWlsdG86ZmVuaXhAZmIuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDIzLCAyMDE4IDY6MzQgUE08YnI+ DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVA YWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRv OnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86aWdvcmxv cmRAYWx1bS5taXQuZWR1Ij4NCmlnb3Jsb3JkQGFsdW0ubWl0LmVkdTwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IERlYWRsb2NrIGF2b2lkYW5jZSBwcm9wb3NhbDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgbXVzdCBhc3N1bWUgdGhhdCBhbnkgZmluaXRlIGJ1 ZmZlciBjYW4gYmUgY29uc3VtZWQuIFRodXMsIGFueSBwYXJ0aXRpb25pbmcgb2YgdGhlIGF2YWls YWJsZSBtZW1vcnkgd2hpY2ggaXMgZmluaXRlIGNhbm5vdCBwcmV2ZW50IHRoaXMgZnJvbSBvY2N1 cnJpbmcuIFdoZW4gaXQgb2NjdXJzLCBpdCBtYXkgaW5kdWNlIGluZGVmaW5pdGUgaGVhZC1vZi1s aW5lLWJsb2NraW5nIG9uIGFsbCBmbG93LWNvbnRyb2xsZWQNCiB1cHN0cmVhbSBub2RlcyBpbiB0 aGUgdG9wb2xvZ3kuIDxicj4NCjxicj4NCkluIG90aGVyIHdvcmRzLCB0aGUgcHJvYmxlbSBpcyBu b3QgcHJldmVudGFibGUgd2l0aCBhbnkgbWVjaGFuaXNtIHdlIGludHJvZHVjZSB3aXRoaW4gdGhl IHByb3RvY29sLiBBdCBiZXN0IHdlIGNhbiBtYWtlIGl0IGRldGVjdGFibGUgYW5kIHByb3ZpZGUg bWVjaGFuaXNtcyB0byBsaW1pdCB0aGUgZGFtYWdlIHdoZW4gaXQgaGFwcGVucy48YnI+DQo8YnI+ DQpUaGUgc3RyZWFtLWRhdGEtY3JlZGl0IHN0dWZmIGlzIGEgZ29vZCBtZWNoYW5pc20gdG8gbGlt aXQgdGhlIGRhbWFnZSB3aGlsZSBzdGlsbCBhbGxvd2luZyBmb3IgZmluaXRlIG1lbW9yeSB1c2Us IGJ1dCBpdCBpcyB1c2VmdWwgb25seSB3aGVuL2lmIGFuIGFwcGxpY2F0aW9uIGtub3dzIHRoYXQg c29tZSBhY3Rpb24gaXMgcmVxdWlyZWQuPGJyPg0KPGJyPg0KVGhlcmUgYXJlIGFsdGVybmF0ZSBt ZWNoYW5pc21zIHRoYXQgd291bGQgYWxzbyBiZSB1c2VmdWw6IGNhbmNlbGxpbmcgYSBzdHJlYW0s IGZvciBpbnN0YW5jZS48YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnAucy4gdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGF0IHdl4oCZdmUgZGVsZWdhdGVkIHRoZSBv d25lcnNoaXAgb2YgdGhlIGRhdGEgdG8gdGhlIGludGVybWVkaWFyeSBieSBhbGxvd2luZyB0aGUg c2VuZGVyIHRvIGZsdXNoIGl0cyBieXRlcyB1cG9uIHJlY2VpdmluZyBwMnAgYWNrcy4gVGhlIGJl c3Qgc29sdXRpb24gaGVyZSB3b3VsZCBiZSBlMmUgYWNrcyAod2hldGhlciBhcHBsaWNhdGlvbi1s YXllciBvciB0cmFuc3BvcnQNCiBvciBib3RoKS4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mcXVvdDtMdWJhc2hldiwgSWdvciZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTggYXQgOTowOCBBTTxi cj4NCjxiPlRvOiA8L2I+Um9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIu Y29tIj5mZW5peEBmYi5jb208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0 Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86aWdv cmxvcmRAYWx1bS5taXQuZWR1Ij5pZ29ybG9yZEBhbHVtLm1pdC5lZHU8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86aWdvcmxvcmRAYWx1bS5taXQuZWR1Ij5pZ29ybG9yZEBhbHVtLm1pdC5l ZHU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogRGVhZGxvY2sgYXZvaWRhbmNlIHBy b3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjx1bCBzdHlsZT0ibWFyZ2lu LXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bGlzdDpsNyBsZXZlbDEgbGZvMyI+VGhlIHN0cmVhbS1kYXRhLWNyZWRpdCB3b3VsZCBuZWVkIHRv IGJlIGV4cHJlc3NlZCBhcyBhIHN0cmVhbSBvZmZzZXQgKHRoaXMgcmVzb2x2ZXMgdGhlIHJhY2Vz IGFuZCBhbGxvd3MgdGhlIG1hdGggeW91IGhhdmUgZG93biB0aGVyZSB0byB3b3JrIHByb3Blcmx5 KS4gSSBzdXNwZWN0IHRoaXMgaXMgd2hhdCB5b3UgbWVhbiBpbiB0aGUgZmlyc3QgcGxhY2UuPG86 cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIHN0cmVhbS1kYXRhLWNyZWRpdCBp biB0aGlzIHByb3Bvc2FsIGlzIGV4cHJlc3NlZCBpbiBldmVyLWluY3JlYXNpbmcgb2Zmc2V0cy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw3IGxldmVsMSBsZm8zIj5PdGhlcndpc2UsIGxvb2tz IGdvb2QuIFRoaXMgd291bGQgZmFsbCB1bmRlciB0aGUg4oCYYWxsb3cgbW9yZSBidWZmZXJpbmcg YXQgdGhlIGFwcGxpY2F0aW9u4oCZIGJ1bGxldCBNYXJ0aW4gaGFkLCBidXQgSSBiZWxpZXZlIHRo YXQgaXMgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRvIGlmIGl0IGlzIGNvbnN0cmFpbmVkIGFuZCBk aXJlY3RlZCBieSB0aGUgYXBwbGljYXRpb24NCiAod2hpY2ggY291bGQgZGVjaWRlIHRvIGNhbmNl bCBhIHN0cmVhbSB0b28pLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1saXN0Omw3IGxldmVsMSBsZm8zIj5TaW5jZSBmbG93IGNvbnRyb2wgaXMgZTJlLCB0 aGlzIGRvZXNu4oCZdCBpbXBhY3QgbWVtb3J5IGF0IGEgcHJveHkuPG86cD48L286cD48L2xpPjwv dWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkV4YWN0bHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw3IGxldmVsMSBs Zm8zIj5XaGF0IHRoaXMgZG9lc27igJl0IHNvbHZlIGlzIHRoZSBkZXRlY3Rpb24gcHJvYmxlbS48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgeW91IGxvb2sgYXQgbXkgZm9sbG93LXVw IHByb3Bvc2FsICh3aGljaCBpcyBlZmZlY3RpdmVseSBjaGFuZ2luZyB0aGUgbWVhbmluZyBvZiBt YXhfc3RyZWFtX2RhdGEgdG8gbWVhbiBzdHJlYW1fZGF0YV9jcmVkaXQpLCB5b3UgbWF5IG5vdCBu ZWVkIHRvIGhhdmUgcm9idXN0IGRlYWRsb2NrIGRldGVjdGlvbiwgYmVjYXVzZSBkZWFkbG9ja3Mg ZHVlIHRvIHRyYW5zcG9ydCBjYW5ub3QgaGFwcGVuLiZuYnNwOyBUaGUgb25seQ0KIGRlYWRsb2Nr cyBwb3NzaWJsZSB3aXRoIHRoZSBmb2xsb3ctdXAgc2NoZW1lIGFyZSBkZWFkbG9ja3MgZHVlIHRv IHRoZSBhcHBsaWNhdGlvbuKAmXMgY2lyY3VsYXIgZGVwZW5kZW5jeSwgbm90IHNlbmRlcuKAmXMg Y2hvaWNlIG9mIHdoaWNoIHN0cmVhbSB0byBzZW5kIGZpcnN0PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQotPVI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhh bGYgb2YgJnF1b3Q7THViYXNoZXYsIElnb3ImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbHVi YXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+VHVlc2RheSwgSmFudWFyeSAyMywgMjAxOCBhdCAyOjUwIFBNPGJyPg0KPGI+VG86IDwv Yj4mcXVvdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4m cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9h PiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzppZ29ybG9yZEBhbHVtLm1pdC5lZHUiPmlnb3Js b3JkQGFsdW0ubWl0LmVkdTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzppZ29ybG9yZEBh bHVtLm1pdC5lZHUiPmlnb3Jsb3JkQGFsdW0ubWl0LmVkdTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPkRlYWRsb2NrIGF2b2lkYW5jZSBwcm9wb3NhbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvYmxlbSB3aXRoIGRlYWRsb2Nr aW5nIFFVSUMgc3RyZWFtcyBpcyB0aGUgcG9zc2liaWxpdHkgdGhhdCB0aGUgc2VuZGVyIChvciBw cm94eSkgd2lsbCDigJx1c2UgdXDigJ0gY29ubmVjdGlvbiBmbG93IGNvbnRyb2wgY3JlZGl0cyBv biBsb3dlci1wcmlvcml0eSBzdHJlYW1zLCBibG9ja2luZyB0aGUgcmVjZWl2ZXIgZnJvbSBtYWtp bmcgZm9yd2FyZCBwcm9ncmVzcyB3aXRoIGFueSBzdHJlYW1zLiZuYnNwOyBUaGUgcmVjZWl2ZXIN CiBoYXMgbm8gbWVjaGFuaXNtIHRvIGRpcmVjdC9mb3JjZSB0aGUgc2VuZGVyIHRvIHNlbmQgb24g cHJlZmVycmVkIHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgbGlrZSB0 byBwcm9wb3NlIGEgY29uY2VwdCBvZiDigJxzdHJlYW0gZGF0YSBjcmVkaXTigJ0g4oCTIHRoZSBj b25jZXB0IG9mIGV4dHJhIGZsb3cgY29udHJvbCBjcmVkaXRzIHRoYXQgY2FuIG9ubHkgYmUgdXNl ZCBieSBhIHNwZWNpZmljIHN0cmVhbS4mbmJzcDsgQSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUg d291bGQgdXBkYXRlIHN1Y2ggY3JlZGl0cyAoc2VlIGJlbG93KS4mbmJzcDsgRGF0YSBzZW50IG9u IGEgc3RyZWFtDQogd2lsbCBjb25zdW1lIGl0cyBvd24gY3JlZGl0cyBhcyBtdWNoIGFzIGl0IGNh biBhbmQgY29ubmVjdGlvbiBjcmVkaXRzICh1cGRhdGVkIGJ5IE1BWF9EQVRBKSBmb3IgdGhlIHJl c3Qgb2YgdGhlIGRhdGEuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1cGRhdGVkIGNvbm5l Y3Rpb24gZmxvdyBjb250cm9sIGFjY291bnRpbmc6Jm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj7igJw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBlYWNoIHN0 cmVhbSwg4oCcdXNlZCBjb25uZWN0aW9uIGNyZWRpdHPigJ0gaXMg4oCcTUFYKHRoZV9sYXJnZXN0 X3JlY2VpdmVkX29mZnNldCAtIHN0cmVhbV9kYXRhX2NyZWRpdHMsIDAp4oCdLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgc3VtIG9mIOKAnHVzZWQgY29ubmVjdGlvbiBjcmVkaXRz4oCdIG9u IGFsbCBzdHJlYW1zIC08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluY2x1 ZGluZyBzdHJlYW1zIGluIHRlcm1pbmFsIHN0YXRlcywgYnV0IGV4Y2x1ZGluZyBzdHJlYW0gMCAt IE1VU1QgTk9UIGV4Y2VlZDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhl IHZhbHVlIGFkdmVydGlzZWQgYnkgYSByZWNlaXZlciAoaS5lLiBNQVhfREFUQSkuJm5ic3A7IEFu IGVuZHBvaW50IE1VU1QgdGVybWluYXRlIGEgY29ubmVjdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d2l0aCBhIFFVSUNfRkxPV19DT05UUk9MX1JFQ0VJVkVEX1RPT19N VUNIX0RBVEEgZXJyb3IgaWYgaXQgdXNlZCBtb3JlIGNvbm5lY3Rpb24gY3JlZGl0czxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhhbiB0aGUgbWF4aW11bSBkYXRhIHZhbHVl IHRoYXQgaXQgaGFzIHNlbnQsIHVubGVzcyB0aGlzIGlzIGEgcmVzdWx0IG9mIGE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNoYW5nZSBpbiB0aGUgaW5pdGlhbCBsaW1pdHMg KHNlZSB7e3plcm9ydHQtcGFyYW1ldGVyc319KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcmVjZWl2ZXIgd2lsbCBi ZSBhYmxlIHRvIGdyYW50IGRlZGljYXRlZCBjcmVkaXRzIHRvIHRoZSBoaWdoLXByaW9yaXR5IHN0 cmVhbSB3L28gcmVxdWlyaW5nIHRoZSBzZW5kZXIgb3IgdGhlIGludGVybWVkaWFyeSB0byBrbm93 IGFueXRoaW5nIGFib3V0IHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sIGFuZCB3aXRob3V0 IHdvcnJ5aW5nIHRoYXQgdGhlIHNlbmRlci9pbnRlcm1lZGlhcnkgd2lsbCDigJxzcXVhbmRlcuKA nQ0KIHRoZSBjcmVkaXRzIG9uIHVuaW1wb3J0YW50IHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U1RSRUFNX0RBVEFfQ1JFRElUIGZy YW1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZnJhbWUgdXBkYXRlcyBEYXRhIENyZWRp dCBmb3IgYSBzdHJlYW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn5+fjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBTdHJlYW0gSUQgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgRGF0YSBDcmVkaXQgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn5+fjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgZmllbGRzIGluIHRoZSBTVFJFQU1fREFUQV9DUkVESVQgZnJhbWUg YXJlIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0cmVhbSBJRDo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+OiBUaGUgc3RyZWFtIElEIG9mIHRoZSBzdHJlYW0gdGhhdCBpcyBh ZmZlY3RlZCBlbmNvZGVkIGFzIGEgdmFyaWFibGUtbGVuZ3RoPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgaW50ZWdlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGF0YSBDcmVkaXQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjogQSB2YXJpYWJsZS1sZW5ndGgg aW50ZWdlciBpbmRpY2F0aW5nIHRoZSBuZXcgdG90YWwgZGF0YSBjcmVkaXQgZm9yIHRoZSBzdHJl YW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBlYWNoIHN0cmVhbSBEYXRhIENyZWRpdCBz dGFydHMgd2l0aCAwLiZuYnNwOyBUaGUgc2VuZGVyIGNhbiBvbmx5IGluY3JlYXNlIERhdGEgQ3Jl ZGl0IGluIHN1YnNlcXVlbnQgU1RSRUFNX0RBVEFfQ1JFRElUIGZyYW1lcyBmb3IgdGhlIHNhbWUg c3RyZWFtLCBidXQgbG9zcyBhbmQgcmVvcmRlcmluZyBjYW4gY2F1c2UgU1RSRUFNX0RBVEFfQ1JF RElUIGZyYW1lcyB0byBiZSByZWNlaXZlZCBvdXQgb2Ygb3JkZXIuJm5ic3A7DQogU1RSRUFNX0RB VEFfQ1JFRElUIGZyYW1lcyB0aGF0IGRvIG5vdCBhZHZhbmNlIERhdGEgQ3JlZGl0IGZvciB0aGUg c3RyZWFtIE1VU1QgYmUgaWdub3JlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Db21tZW50cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw2 IGxldmVsMSBsZm84Ij5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_342bb1fcee94445ca714a71f1b3e01fdusma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 16:45:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332A212D890 for ; Tue, 23 Jan 2018 16:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.28 X-Spam-Level: ** X-Spam-Status: No, score=2.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=mzVsk1jE; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=bBVIZmm2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyqLHmEPYrFW for ; Tue, 23 Jan 2018 16:45:46 -0800 (PST) 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 A208312D88E for ; Tue, 23 Jan 2018 16:45:46 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0O0gXrh001756; Tue, 23 Jan 2018 16:45:41 -0800 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=1ClZOQ+4X5pkGNuUuk2XPIW6SVO5iQ5VhgsmVVYqlHI=; b=mzVsk1jEhlVANf3eXxmBeVIY7kDrqgS2X2zVsqTEwYfPAclB+NrhNTDJh4sCUNKf4tVn jRLqGKriC/CBXnzl+JpLcAQmEWZNbXAOkPJgiALZU+X8+EG73rnZGyZmsH2bQN91Hp1O iKCEPijHEFoA3jhh86ZzNbCucIxT8uxWiA4= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fpcgx0jh8-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 16:45:40 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 19:45:39 -0500 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=1ClZOQ+4X5pkGNuUuk2XPIW6SVO5iQ5VhgsmVVYqlHI=; b=bBVIZmm2UZO+o6C6/EypOwnGSC6tZ3Wq4QQ/kOq0uMlKGuhwFo9+EUN9IVz4mxbPMj5QxXbhEf1PD1Xt1ftnkxPDfUI1Hh7yd9oPcP/Jy1QkJvJmlzuuiug2s0a0VbyA9v8smaddd9f8RGRoz/OVhQ0ltcTw6x+Q+DXtNNJy7tU= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2181.namprd15.prod.outlook.com (52.132.131.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 00:45:38 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Wed, 24 Jan 2018 00:45:38 +0000 From: Roberto Peon To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Re: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgIAAtfbg//6jU+Q= Date: Wed, 24 Jan 2018 00:45:38 +0000 Message-ID: References: <5086f27b81f74a1cad90555d25c227b3@usma1ex-dag1mb5.msg.corp.akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2181; 7:jn5v7rN8DCB9l6h7l/bIqYkHB9ky9BfzP36ZX1FUJd6rxcOaBNunU2SdjiVVwBd19mV82spJ9tRyEhdpk+9a0a1vXdQW1KEETqt7g2Rm2bVscJuxKalFQDr+1fqr/xjMJSOrfYhy3hFu4QB3aEEdPwjXdL/HoIUguX7P4YMmoj3/ltYXuRFhgyuPXE921HlRlE9upNWE2ngavQY6sRktofIqv7FYOfq8j0aeDN0ZWQyO9yCXGexmEvKCVGmxK39/; 20:OWh/fjvVpbKlAnePrrDZmFQhoZUibbUvHD9ovKWjKQCgJR1fXGEp/WbZEYKY0jTCVrhjt9/9TytxPeby38GTTv8xb4M6hHyVlGMDNWTFnC8j6+k/lt3ot8Jr3jdq7+JdWGD1IzMnxFgVJqsMoQ+0RPYLDC7HDixkvI6kOOFwc0g= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1aae23f8-c01a-4617-6a0c-08d562c3c9be x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2181; x-ms-traffictypediagnostic: DM5PR1501MB2181: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(67672495146484)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(2400081)(944501161)(3002001)(10201501046)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR1501MB2181; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2181; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(346002)(376002)(396003)(189003)(199004)(26005)(19627405001)(66066001)(59450400001)(14454004)(68736007)(86362001)(6506007)(76176011)(6346003)(53546011)(7696005)(106356001)(2906002)(2950100002)(102836004)(2201001)(236005)(93886005)(5660300001)(3280700002)(3660700001)(7116003)(8676002)(2900100001)(105586002)(8936002)(478600001)(3846002)(81166006)(6116002)(316002)(229853002)(74316002)(3480700004)(7736002)(55016002)(110136005)(97736004)(6246003)(2501003)(561944003)(25786009)(33656002)(6436002)(551984002)(99286004)(5250100002)(6606003)(53936002)(81156014)(2171002)(9686003)(54896002)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2181; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: c+ywQZnS6ZOPFpB2ouq0aEoXNJ6S+GmgGqw9a1UPWtoSgjyIyVZnUlv6XscSzLU/6k/ZuuF9JIMbxNOkX93Qiw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR1501MB21837BB374C9D5B22380C0B5CDE20DM5PR1501MB2183_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1aae23f8-c01a-4617-6a0c-08d562c3c9be X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 00:45:38.4856 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2181 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 00:45:49 -0000 --_000_DM5PR1501MB21837BB374C9D5B22380C0B5CDE20DM5PR1501MB2183_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes. That is why I'm saying that this is a strategy that is up to an implem= entation. For a naive receiver, which does not self-examine to see that it is blockin= g things, the STREAM_BLOCKED can allow a reaction within an RT. The tradeoff, thus, is an RTT of delay when in the degraded state of having= a full buffer for a naive implementation. That may still be cheaper than causing connection reconnects as it would ne= ed to rexmit the in-flight data as well as losing the congestion context/st= ate. Allocating 25% (or some similar amount) of memory to prevent an uncommon-ca= se of blocking seems suboptimal. That memory could instead be used for the = common case, whether caching or additional connections... -=3DR ________________________________ From: Lubashev, Igor Sent: Tuesday, January 23, 2018 3:51:22 PM To: Roberto Peon; quic@ietf.org; igorlord@alum.mit.edu Subject: RE: Deadlock avoidance proposal If you have finite buffer memory AND allow all of that buffer memory to be = used for any stream, you cannot avoid deadlocks. However, if you dedicate = some buffer memory to each stream (does not need to be much =96 just needs = to be enough for one =93message=94), you can always make progress on your h= ighest-priority stream. The trade-off is that some memory may end up unused (memory dedicated to st= reams that do not have anything to send). If you want to increase your memory utilization even further, you may end u= p doing blocked-stream detection (responding to STREAM_BLOCKED frames) and = give extra memory to those streams =93just-in-time=94. - Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 6:34 PM To: Lubashev, Igor ; quic@ietf.org; igorlord@alum.mit.= edu Subject: Re: Deadlock avoidance proposal We must assume that any finite buffer can be consumed. Thus, any partitioni= ng of the available memory which is finite cannot prevent this from occurri= ng. When it occurs, it may induce indefinite head-of-line-blocking on all f= low-controlled upstream nodes in the topology. In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens. The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required. There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance. -=3DR p.s. the real problem is that we=92ve delegated the ownership of the data t= o the intermediary by allowing the sender to flush its bytes upon receiving= p2p acks. The best solution here would be e2e acks (whether application-la= yer or transport or both). From: "Lubashev, Igor" > Date: Wednesday, January 24, 2018 at 9:08 AM To: Roberto Peon >, "quic@ietf.org" >, "igorlord@alum.mit.= edu" > Subject: RE: Deadlock avoidance proposal * The stream-data-credit would need to be expressed as a stream offset = (this resolves the races and allows the math you have down there to work pr= operly). I suspect this is what you mean in the first place. Yes, the stream-data-credit in this proposal is expressed in ever-increasin= g offsets. * Otherwise, looks good. This would fall under the =91allow more buffer= ing at the application=92 bullet Martin had, but I believe that is a reason= able thing to do if it is constrained and directed by the application (whic= h could decide to cancel a stream too). * Since flow control is e2e, this doesn=92t impact memory at a proxy. Exactly * What this doesn=92t solve is the detection problem. If you look at my follow-up proposal (which is effectively changing the mea= ning of max_stream_data to mean stream_data_credit), you may not need to ha= ve robust deadlock detection, because deadlocks due to transport cannot hap= pen. The only deadlocks possible with the follow-up scheme are deadlocks d= ue to the application=92s circular dependency, not sender=92s choice of whi= ch stream to send first -=3DR From: QUIC > on behalf = of "Lubashev, Igor" > Date: Tuesday, January 23, 2018 at 2:50 PM To: "quic@ietf.org" >, "igorlord@alum.mit.edu" > Subject: Deadlock avoidance proposal The problem with deadlocking QUIC streams is the possibility that the sende= r (or proxy) will =93use up=94 connection flow control credits on lower-pri= ority streams, blocking the receiver from making forward progress with any = streams. The receiver has no mechanism to direct/force the sender to send = on preferred streams. I would like to propose a concept of =93stream data credit=94 =96 the conce= pt of extra flow control credits that can only be used by a specific stream= . A STREAM_DATA_CREDIT frame would update such credits (see below). Data = sent on a stream will consume its own credits as much as it can and connect= ion credits (updated by MAX_DATA) for the rest of the data. The updated connection flow control accounting: =93 For each stream, =93used connection credits=94 is =93MAX(the_largest_receiv= ed_offset - stream_data_credits, 0)=94. The sum of =93used connection credits=94 on all streams - including streams in terminal states, but excluding stream 0 - MUST NOT exc= eed the value advertised by a receiver (i.e. MAX_DATA). An endpoint MUST termi= nate a connection with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it used more conne= ction credits than the maximum data value that it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). =93 The receiver will be able to grant dedicated credits to the high-priority s= tream w/o requiring the sender or the intermediary to know anything about t= he semantics of the protocol and without worrying that the sender/intermedi= ary will =93squander=94 the credits on unimportant streams. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D STREAM_DATA_CREDIT frame. The frame updates Data Credit for a stream. ~~~ 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 (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Credit (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the STREAM_DATA_CREDIT frame are as follows: Stream ID: : The stream ID of the stream that is affected encoded as a variable-length integer. Data Credit: : A variable-length integer indicating the new total data credit for the st= ream. For each stream Data Credit starts with 0. The sender can only increase Da= ta Credit in subsequent STREAM_DATA_CREDIT frames for the same stream, but = loss and reordering can cause STREAM_DATA_CREDIT frames to be received out = of order. STREAM_DATA_CREDIT frames that do not advance Data Credit for th= e stream MUST be ignored. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comments? * Igor --_000_DM5PR1501MB21837BB374C9D5B22380C0B5CDE20DM5PR1501MB2183_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Yes. That is why I'm saying that = this is a strategy that is up to an implementation.


    For a naive receiver, which does not self-examine to see that it is blockin= g things, the STREAM_BLOCKED can allow a reaction within an RT.


    The tradeoff, thus, is an RTT of delay when in the degraded state of h= aving a full buffer for a naive implementation.


    That may still be cheaper than causing connection reconnects as it wou= ld need to rexmit the in-flight data as well as losing the congestion conte= xt/state.

    Allocating 25% (or some similar amount) of memory to prevent an uncomm= on-case of blocking seems suboptimal. That memory could instead be used for= the common case, whether caching or additional connections...

    -=3DR

    From: Lubashev, Igor <il= ubashe@akamai.com>
    Sent: Tuesday, January 23, 2018 3:51:22 PM
    To: Roberto Peon; quic@ietf.org; igorlord@alum.mit.edu
    Subject: RE: Deadlock avoidance proposal
     

    If you have finite buffer memory AND allow all of = that buffer memory to be used for any stream, you cannot avoid deadlocks.&n= bsp; However, if you dedicate some buffer memory to each stream (does not n= eed to be much =96 just needs to be enough for one =93message=94), you can always make progress on your highest-prior= ity stream.

     

    The trade-off is that some memory may end up unuse= d (memory dedicated to streams that do not have anything to send).

     

    If you want to increase your memory utilization ev= en further, you may end up doing blocked-stream detection (responding to ST= REAM_BLOCKED frames) and give extra memory to those streams =93just-in-time= =94.

     

    - Igor

     

    From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 6:34 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; quic@ietf.org; igorl= ord@alum.mit.edu
    Subject: Re: Deadlock avoidance proposal

     

    We must assume that any finite buffer can be consu= med. Thus, any partitioning of the available memory which is finite cannot = prevent this from occurring. When it occurs, it may induce indefinite head-= of-line-blocking on all flow-controlled upstream nodes in the topology.

    In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens.

    The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required.

    There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance.
    -=3DR

    p.s. the real problem is that we=92ve delegated th= e ownership of the data to the intermediary by allowing the sender to flush= its bytes upon receiving p2p acks. The best solution here would be e2e ack= s (whether application-layer or transport or both).

     

    F= rom: "Lubashev, Igor"= ; <ilubashe@akamai.com> Date: Wednesday, January 24, 2018 at 9:08 AM
    To: Roberto Peon <fenix@fb.com>, "quic@ietf.org" <<= a href=3D"mailto:quic@ietf.org">quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: RE: Deadlock avoidance proposal

     

    • The stream-data-credit would need to b= e expressed as a stream offset (this resolves the races and allows the math= you have down there to work properly). I suspect this is what you mean in = the first place.

     

    Yes, the stream-data-credit in this proposal is ex= pressed in ever-increasing offsets.

     

    • Otherwise, looks good. This would fall= under the =91allow more buffering at the application=92 bullet Martin had,= but I believe that is a reasonable thing to do if it is constrained and di= rected by the application (which could decide to cancel a stream too).
    • Since fl= ow control is e2e, this doesn=92t impact memory at a proxy.

     

    Exactly

     

    • What this doesn=92t solve is the detec= tion problem.

     

    If you look at my follow-up proposal (which is eff= ectively changing the meaning of max_stream_data to mean stream_data_credit= ), you may not need to have robust deadlock detection, because deadlocks du= e to transport cannot happen.  The only deadlocks possible with the follow-up scheme are deadlocks due to the= application=92s circular dependency, not sender=92s choice of which stream= to send first


    -=3DR

     

     

    F= rom: QUIC <quic-bounces@ietf.org> on behalf of "L= ubashev, Igor" <ilubashe@aka= mai.com>
    Date: Tuesday, January 23, 2018 at 2:50 PM
    To: "quic@ietf.org" &= lt;quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: Deadlock avoidance proposal

     

    The problem with deadlocking QUIC streams is the p= ossibility that the sender (or proxy) will =93use up=94 connection flow con= trol credits on lower-priority streams, blocking the receiver from making f= orward progress with any streams.  The receiver has no mechanism to direct/force the sender to send on preferred = streams.

     

    I would like to propose a concept of =93stream dat= a credit=94 =96 the concept of extra flow control credits that can only be = used by a specific stream.  A STREAM_DATA_CREDIT frame would update su= ch credits (see below).  Data sent on a stream will consume its own credits as much as it can and connection credits (upd= ated by MAX_DATA) for the rest of the data.

     

    The updated connection flow control accounting:&nb= sp;

     

    =93

    For each stream, =93used connection credits=94 is = =93MAX(the_largest_received_offset - stream_data_credits, 0)=94.

     

    The sum of =93used connection credits=94 on all st= reams -

    including streams in terminal states, but excludin= g stream 0 - MUST NOT exceed

    the value advertised by a receiver (i.e. MAX_DATA)= .  An endpoint MUST terminate a connection

    with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA er= ror if it used more connection credits

    than the maximum data value that it has sent, unle= ss this is a result of a

    change in the initial limits (see {{zerortt-parame= ters}}).

    =93

     

    The receiver will be able to grant dedicated credi= ts to the high-priority stream w/o requiring the sender or the intermediary= to know anything about the semantics of the protocol and without worrying = that the sender/intermediary will =93squander=94 the credits on unimportant streams.

     

     

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

     

    STREAM_DATA_CREDIT frame.

     

    The frame updates Data Credit for a stream.

     

    ~~~

    0        &= nbsp;          1  &n= bsp;            = ;    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

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    |        &= nbsp;           &nbs= p;   Stream ID (i)        = ;            &n= bsp;   ...

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    |        &= nbsp;           &nbs= p;   Data Credit (i)       &nb= sp;            =     ...

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    ~~~

     

    The fields in the STREAM_DATA_CREDIT frame are as = follows:

     

    Stream ID:

     

    : The stream ID of the stream that is affected enc= oded as a variable-length

      integer.

     

    Data Credit:

     

    : A variable-length integer indicating the new tot= al data credit for the stream.

     

    For each stream Data Credit starts with 0.  T= he sender can only increase Data Credit in subsequent STREAM_DATA_CREDIT fr= ames for the same stream, but loss and reordering can cause STREAM_DATA_CRE= DIT frames to be received out of order.  STREAM_DATA_CREDIT frames that do not advance Data Credit for the stream M= UST be ignored.

     

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

     

     

    Comments?

     

    • Igor
    --_000_DM5PR1501MB21837BB374C9D5B22380C0B5CDE20DM5PR1501MB2183_-- From nobody Tue Jan 23 16:53:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F0912D951 for ; Tue, 23 Jan 2018 16:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.28 X-Spam-Level: ** X-Spam-Status: No, score=2.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=dRCQZjoU; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=UiWGBrRI Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XyX7g9cvkjv for ; Tue, 23 Jan 2018 16:53:09 -0800 (PST) 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 DF28312D950 for ; Tue, 23 Jan 2018 16:53:09 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0O0nu12015244; Tue, 23 Jan 2018 16:53:03 -0800 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=Iu/zH8Vz3oK1vvR24bPdsarYpIVj1dnhcJ+oeFaDjEY=; b=dRCQZjoUXy7X35bI/1Z9VOhoPItZ43DrVhXoE8EicxoM7pezn6+Ism+8eUPiEce1hcSM Db5SGda11tgcwFtJfWz9k4DsXxWjiepg53Zma29rrdAgCNq2b+8aRZgRCv6lvt/nu6il 6T+vqYJmIEwFoK9dmD3ikIo5Ht9sqLnRbek= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fpebtg9vj-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Jan 2018 16:53:03 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 23 Jan 2018 19:53:01 -0500 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=Iu/zH8Vz3oK1vvR24bPdsarYpIVj1dnhcJ+oeFaDjEY=; b=UiWGBrRIc0ofsWmRgzLunqexuCIOJFgAF1fEeg9UaVtgBa8aVVaoCWIXaVCiZci9addPo9qrgxW+FL7t46DugB8nXmx2n5uO6rq0KkhqaSduunkgxb4ShIozwPdeyoOsDV4666LWGweF6Et8PrKED8M+5ty5GB2CsICpVn5/Np0= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2181.namprd15.prod.outlook.com (52.132.131.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 00:52:59 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Wed, 24 Jan 2018 00:52:59 +0000 From: Roberto Peon To: "Lubashev, Igor" , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: Re: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgIAAtfbggAFoUYD//T2YfQ== Date: Wed, 24 Jan 2018 00:52:59 +0000 Message-ID: References: <5086f27b81f74a1cad90555d25c227b3@usma1ex-dag1mb5.msg.corp.akamai.com> , <342bb1fcee94445ca714a71f1b3e01fd@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <342bb1fcee94445ca714a71f1b3e01fd@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2181; 7:TU+xfo3mflfGswiyweyTV+JlVmx1uuJffzgQnnMhHbp0ExKRerg0QWdfVrk3Y1+7FpeUNIAOV4Ij7ELCpS3lOcFLYoHBDuOUHGnvVzPPdw2R2sK75NTrKE2v2DEMvPtsFZ6IDunydIclQaF4IpSTiAmePtTjxe0rp0z85n6ALdVxm/vGM3PL/GjbZ008ti7jRhlUdOAgTEnUwHhBGekQXR9Th88lXMyCLJtVoOef/RqJaNIAO/S0rTz0MGwQhyPA; 20:bTWhjedJ7zIAYF1PSkdd1HwnE12MQwMWoF6spd1g4XHvIWpOmM3kuRANhCkUEYSuoh1AZYntIIU1gYNusuHf7bJJ8W4HdHj8ZVtGBksTCUL0TVAi8/RCdM5KH0Iio9QTeLq3H27dhCiaetQ/xa+M278iAiDx9di7Ega7Ff9jwoM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c3252273-9ee4-4df7-638c-08d562c4d0b9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2181; x-ms-traffictypediagnostic: DM5PR1501MB2181: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(67672495146484)(240460790083961); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231023)(11241501184)(2400081)(944501161)(3002001)(10201501046)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR1501MB2181; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2181; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(366004)(39380400002)(346002)(199004)(189003)(74316002)(3480700004)(478600001)(2900100001)(105586002)(8936002)(316002)(229853002)(3846002)(6116002)(81166006)(81156014)(2171002)(6606003)(53936002)(551984002)(5250100002)(99286004)(54896002)(9686003)(97736004)(6246003)(2501003)(110136005)(55016002)(7736002)(33656002)(6436002)(561944003)(25786009)(53546011)(6346003)(6506007)(86362001)(76176011)(106356001)(7696005)(26005)(68736007)(19627405001)(66066001)(59450400001)(14454004)(5660300001)(3280700002)(3660700001)(7116003)(8676002)(2950100002)(2201001)(102836004)(2906002)(93886005)(236005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2181; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: YGYo79EHD8IHG/eZ8XX/TSTVbBB5152gd23mal8ogZEhy1F3fbD1YC0LV6+PcvJKutCE3gGgutGYD2gTnAW4Qw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR1501MB218368BCAC5E96E501CF00CECDE20DM5PR1501MB2183_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c3252273-9ee4-4df7-638c-08d562c4d0b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 00:52:59.6778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2181 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-23_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 00:53:12 -0000 --_000_DM5PR1501MB218368BCAC5E96E501CF00CECDE20DM5PR1501MB2183_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I'm trying to avoid bikeshedding :) There is connection-level blockage, and stream-level blockage. One can cause the other, but not *every* involved connection may be affecte= d. With finite memory, blockage/deadlock cannot be prevented. The only 'real' solution is e2e acks (separate from p2p flow control), allo= wing intermediaries to discard data p2p, suffering only a decrease in effic= iency, i.e. to have the sender buffer data until the ultimate receiver has = received it. Everything else is a patch, not that I'd personally object to patches... -=3DR ________________________________ From: Lubashev, Igor Sent: Tuesday, January 23, 2018 4:00:14 PM To: Lubashev, Igor; Roberto Peon; quic@ietf.org; igorlord@alum.mit.edu Subject: RE: Deadlock avoidance proposal * We must assume that any finite buffer can be consumed. Thus, any part= itioning of the available memory which is finite cannot prevent this from o= ccurring. When it occurs, it may induce indefinite head-of-line-blocking on= all flow-controlled upstream nodes in the topology. To be more specific, =93it may induce indefinite head-of-line-blocking on a= ll flow-controlled upstream nodes in the topology=94 is incorrect. =93Inde= finite=94 blocking means deadlock. HOL blocking =96 possible; deadlock =96= no. A deadlock is when NO stream can make any progress without killing some str= eam. If each stream has =93dedicated=94 memory buffer (or the client is wi= lling to dedicate a memory buffer to the highest-priority blocked stream), = the highest-priority stream will not block =96 the receiver will consume it= , free that stream-private buffer, and sender will send more data to that s= tream. * Igor From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Tuesday, January 23, 2018 6:51 PM To: Roberto Peon ; quic@ietf.org; igorlord@alum.mit.edu Subject: RE: Deadlock avoidance proposal If you have finite buffer memory AND allow all of that buffer memory to be = used for any stream, you cannot avoid deadlocks. However, if you dedicate = some buffer memory to each stream (does not need to be much =96 just needs = to be enough for one =93message=94), you can always make progress on your h= ighest-priority stream. The trade-off is that some memory may end up unused (memory dedicated to st= reams that do not have anything to send). If you want to increase your memory utilization even further, you may end u= p doing blocked-stream detection (responding to STREAM_BLOCKED frames) and = give extra memory to those streams =93just-in-time=94. - Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 6:34 PM To: Lubashev, Igor >; quic@= ietf.org; igorlord@alum.mit.edu Subject: Re: Deadlock avoidance proposal We must assume that any finite buffer can be consumed. Thus, any partitioni= ng of the available memory which is finite cannot prevent this from occurri= ng. When it occurs, it may induce indefinite head-of-line-blocking on all f= low-controlled upstream nodes in the topology. In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens. The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required. There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance. -=3DR p.s. the real problem is that we=92ve delegated the ownership of the data t= o the intermediary by allowing the sender to flush its bytes upon receiving= p2p acks. The best solution here would be e2e acks (whether application-la= yer or transport or both). From: "Lubashev, Igor" > Date: Wednesday, January 24, 2018 at 9:08 AM To: Roberto Peon >, "quic@ietf.org" >, "igorlord@alum.mit.= edu" > Subject: RE: Deadlock avoidance proposal * The stream-data-credit would need to be expressed as a stream offset = (this resolves the races and allows the math you have down there to work pr= operly). I suspect this is what you mean in the first place. Yes, the stream-data-credit in this proposal is expressed in ever-increasin= g offsets. * Otherwise, looks good. This would fall under the =91allow more buffer= ing at the application=92 bullet Martin had, but I believe that is a reason= able thing to do if it is constrained and directed by the application (whic= h could decide to cancel a stream too). * Since flow control is e2e, this doesn=92t impact memory at a proxy. Exactly * What this doesn=92t solve is the detection problem. If you look at my follow-up proposal (which is effectively changing the mea= ning of max_stream_data to mean stream_data_credit), you may not need to ha= ve robust deadlock detection, because deadlocks due to transport cannot hap= pen. The only deadlocks possible with the follow-up scheme are deadlocks d= ue to the application=92s circular dependency, not sender=92s choice of whi= ch stream to send first -=3DR From: QUIC > on behalf = of "Lubashev, Igor" > Date: Tuesday, January 23, 2018 at 2:50 PM To: "quic@ietf.org" >, "igorlord@alum.mit.edu" > Subject: Deadlock avoidance proposal The problem with deadlocking QUIC streams is the possibility that the sende= r (or proxy) will =93use up=94 connection flow control credits on lower-pri= ority streams, blocking the receiver from making forward progress with any = streams. The receiver has no mechanism to direct/force the sender to send = on preferred streams. I would like to propose a concept of =93stream data credit=94 =96 the conce= pt of extra flow control credits that can only be used by a specific stream= . A STREAM_DATA_CREDIT frame would update such credits (see below). Data = sent on a stream will consume its own credits as much as it can and connect= ion credits (updated by MAX_DATA) for the rest of the data. The updated connection flow control accounting: =93 For each stream, =93used connection credits=94 is =93MAX(the_largest_receiv= ed_offset - stream_data_credits, 0)=94. The sum of =93used connection credits=94 on all streams - including streams in terminal states, but excluding stream 0 - MUST NOT exc= eed the value advertised by a receiver (i.e. MAX_DATA). An endpoint MUST termi= nate a connection with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it used more conne= ction credits than the maximum data value that it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). =93 The receiver will be able to grant dedicated credits to the high-priority s= tream w/o requiring the sender or the intermediary to know anything about t= he semantics of the protocol and without worrying that the sender/intermedi= ary will =93squander=94 the credits on unimportant streams. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D STREAM_DATA_CREDIT frame. The frame updates Data Credit for a stream. ~~~ 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 (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Credit (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the STREAM_DATA_CREDIT frame are as follows: Stream ID: : The stream ID of the stream that is affected encoded as a variable-length integer. Data Credit: : A variable-length integer indicating the new total data credit for the st= ream. For each stream Data Credit starts with 0. The sender can only increase Da= ta Credit in subsequent STREAM_DATA_CREDIT frames for the same stream, but = loss and reordering can cause STREAM_DATA_CREDIT frames to be received out = of order. STREAM_DATA_CREDIT frames that do not advance Data Credit for th= e stream MUST be ignored. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comments? * Igor --_000_DM5PR1501MB218368BCAC5E96E501CF00CECDE20DM5PR1501MB2183_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    I'm trying to avoid bikeshedding = :)

    There is connection-level blockage, and stream-level blockage.

    One can cause the other, but not = *every* involved connection may be affected.

    With finite memory, blockage/deadlock cannot be prevented.


    The only 'real' solution is e2e acks (separate from p2p flow control), allo= wing intermediaries to discard data p2p, suffering only a decrease in effic= iency, i.e. to have the sender buffer data until the ultimate receiver has = received it.

    Everything else is a patch, not that I'd personally object to patches...

    -=3DR

    From: Lubashev, Igor <il= ubashe@akamai.com>
    Sent: Tuesday, January 23, 2018 4:00:14 PM
    To: Lubashev, Igor; Roberto Peon; quic@ietf.org; igorlord@alum.mit.e= du
    Subject: RE: Deadlock avoidance proposal
     
    • We must assume t= hat any finite buffer can be consumed. Thus, any partitioning of the availa= ble memory which is finite cannot prevent this from occurring. When it occu= rs, it may induce indefinite head-of-line-blocking on all flow-controlled upstream nodes in the topology.

     

    To be more specific, =93it may induce indefinite h= ead-of-line-blocking on all flow-controlled upstream nodes in the topology= =94 is incorrect.  =93Indefinite=94 blocking means deadlock.  HOL= blocking =96 possible; deadlock =96 no.

     

    A deadlock is when NO stream can make any progress= without killing some stream.  If each stream has =93dedicated=94 memo= ry buffer (or the client is willing to dedicate a memory buffer to the high= est-priority blocked stream), the highest-priority stream will not block =96 the receiver will consume it, free that stream-p= rivate buffer, and sender will send more data to that stream.

     

    • Igor

     

     

     

    From: Lubashev, Igor [mailto:ilubashe@akama= i.com]
    Sent: Tuesday, January 23, 2018 6:51 PM
    To: Roberto Peon <fenix@fb.com>; quic@ietf.org; igorlord@alum.= mit.edu
    Subject: RE: Deadlock avoidance proposal

     

    If you have finite buffer memory AND allow all of = that buffer memory to be used for any stream, you cannot avoid deadlocks.&n= bsp; However, if you dedicate some buffer memory to each stream (does not n= eed to be much =96 just needs to be enough for one =93message=94), you can always make progress on your highest-prior= ity stream.

     

    The trade-off is that some memory may end up unuse= d (memory dedicated to streams that do not have anything to send).

     

    If you want to increase your memory utilization ev= en further, you may end up doing blocked-stream detection (responding to ST= REAM_BLOCKED frames) and give extra memory to those streams =93just-in-time= =94.

     

    - Igor

     

    From: Roberto Peon [mailto:fenix@fb.com]
    Sent: Tuesday, January 23, 2018 6:34 PM
    To: Lubashev, Igor <ilubas= he@akamai.com>; quic@ietf.org; igorlord@alum.mit.edu
    Subject: Re: Deadlock avoidance proposal

     

    We must assume that any finite buffer can be consu= med. Thus, any partitioning of the available memory which is finite cannot = prevent this from occurring. When it occurs, it may induce indefinite head-= of-line-blocking on all flow-controlled upstream nodes in the topology.

    In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens.

    The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required.

    There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance.
    -=3DR

    p.s. the real problem is that we=92ve delegated th= e ownership of the data to the intermediary by allowing the sender to flush= its bytes upon receiving p2p acks. The best solution here would be e2e ack= s (whether application-layer or transport or both).

     

    F= rom: "Lubashev, Igor"= ; <ilubashe@akamai.com> Date: Wednesday, January 24, 2018 at 9:08 AM
    To: Roberto Peon <fenix@fb.com>, "quic@ietf.org" <<= a href=3D"mailto:quic@ietf.org">quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: RE: Deadlock avoidance proposal

     

    • The stream-data-credit would need to b= e expressed as a stream offset (this resolves the races and allows the math= you have down there to work properly). I suspect this is what you mean in = the first place.

     

    Yes, the stream-data-credit in this proposal is ex= pressed in ever-increasing offsets.

     

    • Otherwise, looks good. This would fall= under the =91allow more buffering at the application=92 bullet Martin had,= but I believe that is a reasonable thing to do if it is constrained and di= rected by the application (which could decide to cancel a stream too).
    • Since fl= ow control is e2e, this doesn=92t impact memory at a proxy.

     

    Exactly

     

    • What this doesn=92t solve is the detec= tion problem.

     

    If you look at my follow-up proposal (which is eff= ectively changing the meaning of max_stream_data to mean stream_data_credit= ), you may not need to have robust deadlock detection, because deadlocks du= e to transport cannot happen.  The only deadlocks possible with the follow-up scheme are deadlocks due to the= application=92s circular dependency, not sender=92s choice of which stream= to send first


    -=3DR

     

     

    F= rom: QUIC <quic-bounces@ietf.org> on behalf of "L= ubashev, Igor" <ilubashe@aka= mai.com>
    Date: Tuesday, January 23, 2018 at 2:50 PM
    To: "quic@ietf.org" &= lt;quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: Deadlock avoidance proposal

     

    The problem with deadlocking QUIC streams is the p= ossibility that the sender (or proxy) will =93use up=94 connection flow con= trol credits on lower-priority streams, blocking the receiver from making f= orward progress with any streams.  The receiver has no mechanism to direct/force the sender to send on preferred = streams.

     

    I would like to propose a concept of =93stream dat= a credit=94 =96 the concept of extra flow control credits that can only be = used by a specific stream.  A STREAM_DATA_CREDIT frame would update su= ch credits (see below).  Data sent on a stream will consume its own credits as much as it can and connection credits (upd= ated by MAX_DATA) for the rest of the data.

     

    The updated connection flow control accounting:&nb= sp;

     

    =93

    For each stream, =93used connection credits=94 is = =93MAX(the_largest_received_offset - stream_data_credits, 0)=94.

     

    The sum of =93used connection credits=94 on all st= reams -

    including streams in terminal states, but excludin= g stream 0 - MUST NOT exceed

    the value advertised by a receiver (i.e. MAX_DATA)= .  An endpoint MUST terminate a connection

    with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA er= ror if it used more connection credits

    than the maximum data value that it has sent, unle= ss this is a result of a

    change in the initial limits (see {{zerortt-parame= ters}}).

    =93

     

    The receiver will be able to grant dedicated credi= ts to the high-priority stream w/o requiring the sender or the intermediary= to know anything about the semantics of the protocol and without worrying = that the sender/intermediary will =93squander=94 the credits on unimportant streams.

     

     

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

     

    STREAM_DATA_CREDIT frame.

     

    The frame updates Data Credit for a stream.

     

    ~~~

    0        &= nbsp;          1  &n= bsp;            = ;    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

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    |        &= nbsp;           &nbs= p;   Stream ID (i)        = ;            &n= bsp;   ...

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    |        &= nbsp;           &nbs= p;   Data Credit (i)       &nb= sp;            =     ...

    +-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+

    ~~~

     

    The fields in the STREAM_DATA_CREDIT frame are as = follows:

     

    Stream ID:

     

    : The stream ID of the stream that is affected enc= oded as a variable-length

      integer.

     

    Data Credit:

     

    : A variable-length integer indicating the new tot= al data credit for the stream.

     

    For each stream Data Credit starts with 0.  T= he sender can only increase Data Credit in subsequent STREAM_DATA_CREDIT fr= ames for the same stream, but loss and reordering can cause STREAM_DATA_CRE= DIT frames to be received out of order.  STREAM_DATA_CREDIT frames that do not advance Data Credit for the stream M= UST be ignored.

     

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

     

     

    Comments?

     

    • Igor
    --_000_DM5PR1501MB218368BCAC5E96E501CF00CECDE20DM5PR1501MB2183_-- From nobody Tue Jan 23 17:33:50 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30D912D890 for ; Tue, 23 Jan 2018 17:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5P9Mi8AM7l7h for ; Tue, 23 Jan 2018 17:33:44 -0800 (PST) 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 3EC2F120047 for ; Tue, 23 Jan 2018 17:33:44 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0O1Wokc001550; Wed, 24 Jan 2018 01:33:36 GMT 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=g8fMhONOU7Vkt7aIMNBAKguXSp4MLbxPMUxz2MAilQM=; b=ZrUtClTDAiMQDSWYDgF9j+xzQ3tXHvOiJ4/b84JMLSAelEE6O8jJkvOKdrijv1GL8Cqf bTFPE64GDq0CZR6Wg3lDDoMDmZwYWNLUfvfKUG9JVa1o4KS0vSYKsZ7DYNr8iQSULmdL 3ATgmhpWa20SoQ2wfBBA/faLf2ph9dPjryKbXfCJxMbRdmDV2qY23lLL6rgQMxmSb8uq ImpCNzHdBYS8w54Bu9gufsK5DO1//maZ7dF17bcguT8q7I9w92vQxXQPcdiLljRpXUTf eoKM/OXsuv3Ruvxp+xpcyIlW7E2Hi6KSk8qb11t1sTzpo26JPU5Dm3zIjHxb1dkQrZ0b Xw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2fpe0mrhrb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 01:33:35 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0O1Vlgi011334; Tue, 23 Jan 2018 20:33:35 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20ekmwv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jan 2018 20:33:34 -0500 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; Tue, 23 Jan 2018 20:33:33 -0500 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; Tue, 23 Jan 2018 20:33:33 -0500 From: "Lubashev, Igor" To: Roberto Peon , "quic@ietf.org" , "igorlord@alum.mit.edu" Subject: RE: Deadlock avoidance proposal Thread-Topic: Deadlock avoidance proposal Thread-Index: AdOT9959ALO6h9wZTIKAZxoxZQbGMAA8KTMAABThvYD//4WUgIAAtfbggAFoUYD//T2Yff//+wnw Date: Wed, 24 Jan 2018 01:33:32 +0000 Message-ID: <1a3f48cacd154d70b31008d7b3269c30@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5086f27b81f74a1cad90555d25c227b3@usma1ex-dag1mb5.msg.corp.akamai.com> , <342bb1fcee94445ca714a71f1b3e01fd@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.38.42] Content-Type: multipart/alternative; boundary="_000_1a3f48cacd154d70b31008d7b3269c30usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240016 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 01:33:48 -0000 --_000_1a3f48cacd154d70b31008d7b3269c30usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Merging threads. I think we are in a general agreement here. The features of the proposal are: (a) Connection-level blockage (exhaustion of shared credits) does not cause= stream-level blockage (if the receiver is willing to allocate some dedicat= ed buffer memory to the stream, either in advance or after STREAM_BLOCKED); (b) Application-level logic can cause stream-level blockage (by refusing to= read, which will exhaust any finite buffer). And I really like your suggestion that a naive receiver can use STREAM_BLOC= KED as a signal to the application to decide whether it wants to unblock a = particular stream by temporarily giving it an extra buffer allocation. And= since this is likely to be a very uncommon case, a na=EFve receiver may pe= rform ok. * Igor P.S. I think the last proposal "limiting stream_data_offset to MAX(stream_max_da= ta, connection_max_data - SUM(stream_data_offset))" may actually simulate t= he way we want to manage buffers better then the current design. Either th= e transport is managing its own buffers, in which case it is happy to dedic= ate all/most of them to the "common connection pool" w/o per-stream limits = and let the sender decide how to use them. Or the transport is actually ma= naging per-stream buffers belonging to applications, in which case the tran= sport does not want to impose an arbitrary restriction on streams (in a for= m of the "MAX_DATA") and, instead, it may actually wish to "throw in" some = extra buffers of its own for the "common pool". From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 7:46 PM To: Lubashev, Igor ; quic@ietf.org; igorlord@alum.mit.= edu Subject: Re: Deadlock avoidance proposal Yes. That is why I'm saying that this is a strategy that is up to an implem= entation. For a naive receiver, which does not self-examine to see that it is blockin= g things, the STREAM_BLOCKED can allow a reaction within an RT. The tradeoff, thus, is an RTT of delay when in the degraded state of having= a full buffer for a naive implementation. That may still be cheaper than causing connection reconnects as it would ne= ed to rexmit the in-flight data as well as losing the congestion context/st= ate. Allocating 25% (or some similar amount) of memory to prevent an uncommon-ca= se of blocking seems suboptimal. That memory could instead be used for the = common case, whether caching or additional connections... -=3DR From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 7:53 PM To: Lubashev, Igor ; quic@ietf.org; igorlord@alum.mit.= edu Subject: Re: Deadlock avoidance proposal I'm trying to avoid bikeshedding :) There is connection-level blockage, and stream-level blockage. One can cause the other, but not *every* involved connection may be affecte= d. With finite memory, blockage/deadlock cannot be prevented. The only 'real' solution is e2e acks (separate from p2p flow control), allo= wing intermediaries to discard data p2p, suffering only a decrease in effic= iency, i.e. to have the sender buffer data until the ultimate receiver has = received it. Everything else is a patch, not that I'd personally object to patches... -=3DR ________________________________ From: Lubashev, Igor > Sent: Tuesday, January 23, 2018 4:00:14 PM To: Lubashev, Igor; Roberto Peon; quic@ietf.org; igor= lord@alum.mit.edu Subject: RE: Deadlock avoidance proposal * We must assume that any finite buffer can be consumed. Thus, any part= itioning of the available memory which is finite cannot prevent this from o= ccurring. When it occurs, it may induce indefinite head-of-line-blocking on= all flow-controlled upstream nodes in the topology. To be more specific, "it may induce indefinite head-of-line-blocking on all= flow-controlled upstream nodes in the topology" is incorrect. "Indefinite= " blocking means deadlock. HOL blocking - possible; deadlock - no. A deadlock is when NO stream can make any progress without killing some str= eam. If each stream has "dedicated" memory buffer (or the client is willin= g to dedicate a memory buffer to the highest-priority blocked stream), the = highest-priority stream will not block - the receiver will consume it, free= that stream-private buffer, and sender will send more data to that stream. * Igor From: Lubashev, Igor [mailto:ilubashe@akamai.com] Sent: Tuesday, January 23, 2018 6:51 PM To: Roberto Peon >; quic@ietf.org; igorlord@alum.mit.edu Subject: RE: Deadlock avoidance proposal If you have finite buffer memory AND allow all of that buffer memory to be = used for any stream, you cannot avoid deadlocks. However, if you dedicate = some buffer memory to each stream (does not need to be much - just needs to= be enough for one "message"), you can always make progress on your highest= -priority stream. The trade-off is that some memory may end up unused (memory dedicated to st= reams that do not have anything to send). If you want to increase your memory utilization even further, you may end u= p doing blocked-stream detection (responding to STREAM_BLOCKED frames) and = give extra memory to those streams "just-in-time". - Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Tuesday, January 23, 2018 6:34 PM To: Lubashev, Igor >; quic@= ietf.org; igorlord@alum.mit.edu Subject: Re: Deadlock avoidance proposal We must assume that any finite buffer can be consumed. Thus, any partitioni= ng of the available memory which is finite cannot prevent this from occurri= ng. When it occurs, it may induce indefinite head-of-line-blocking on all f= low-controlled upstream nodes in the topology. In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens. The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required. There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance. -=3DR p.s. the real problem is that we've delegated the ownership of the data to = the intermediary by allowing the sender to flush its bytes upon receiving p= 2p acks. The best solution here would be e2e acks (whether application-laye= r or transport or both). From: "Lubashev, Igor" > Date: Wednesday, January 24, 2018 at 9:08 AM To: Roberto Peon >, "quic@ietf.org" >, "igorlord@alum.mit.= edu" > Subject: RE: Deadlock avoidance proposal * The stream-data-credit would need to be expressed as a stream offset = (this resolves the races and allows the math you have down there to work pr= operly). I suspect this is what you mean in the first place. Yes, the stream-data-credit in this proposal is expressed in ever-increasin= g offsets. * Otherwise, looks good. This would fall under the 'allow more bufferin= g at the application' bullet Martin had, but I believe that is a reasonable= thing to do if it is constrained and directed by the application (which co= uld decide to cancel a stream too). * Since flow control is e2e, this doesn't impact memory at a proxy. Exactly * What this doesn't solve is the detection problem. If you look at my follow-up proposal (which is effectively changing the mea= ning of max_stream_data to mean stream_data_credit), you may not need to ha= ve robust deadlock detection, because deadlocks due to transport cannot hap= pen. The only deadlocks possible with the follow-up scheme are deadlocks d= ue to the application's circular dependency, not sender's choice of which s= tream to send first -=3DR From: QUIC > on behalf = of "Lubashev, Igor" > Date: Tuesday, January 23, 2018 at 2:50 PM To: "quic@ietf.org" >, "igorlord@alum.mit.edu" > Subject: Deadlock avoidance proposal The problem with deadlocking QUIC streams is the possibility that the sende= r (or proxy) will "use up" connection flow control credits on lower-priorit= y streams, blocking the receiver from making forward progress with any stre= ams. The receiver has no mechanism to direct/force the sender to send on p= referred streams. I would like to propose a concept of "stream data credit" - the concept of = extra flow control credits that can only be used by a specific stream. A S= TREAM_DATA_CREDIT frame would update such credits (see below). Data sent o= n a stream will consume its own credits as much as it can and connection cr= edits (updated by MAX_DATA) for the rest of the data. The updated connection flow control accounting: " For each stream, "used connection credits" is "MAX(the_largest_received_off= set - stream_data_credits, 0)". The sum of "used connection credits" on all streams - including streams in terminal states, but excluding stream 0 - MUST NOT exc= eed the value advertised by a receiver (i.e. MAX_DATA). An endpoint MUST termi= nate a connection with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error if it used more conne= ction credits than the maximum data value that it has sent, unless this is a result of a change in the initial limits (see {{zerortt-parameters}}). " The receiver will be able to grant dedicated credits to the high-priority s= tream w/o requiring the sender or the intermediary to know anything about t= he semantics of the protocol and without worrying that the sender/intermedi= ary will "squander" the credits on unimportant streams. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D STREAM_DATA_CREDIT frame. The frame updates Data Credit for a stream. ~~~ 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 (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Credit (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~~~ The fields in the STREAM_DATA_CREDIT frame are as follows: Stream ID: : The stream ID of the stream that is affected encoded as a variable-length integer. Data Credit: : A variable-length integer indicating the new total data credit for the st= ream. For each stream Data Credit starts with 0. The sender can only increase Da= ta Credit in subsequent STREAM_DATA_CREDIT frames for the same stream, but = loss and reordering can cause STREAM_DATA_CREDIT frames to be received out = of order. STREAM_DATA_CREDIT frames that do not advance Data Credit for th= e stream MUST be ignored. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Comments? * Igor --_000_1a3f48cacd154d70b31008d7b3269c30usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Merging threads.

     

    I think we are in a general agreement here.

     

    The features of the proposal are:

    (a) Connection-level blockage (exhaustion of shared = credits) does not cause stream-level blockage (if the receiver is willing t= o allocate some dedicated buffer memory to the stream, either in advance or= after STREAM_BLOCKED);

    (b) Application-level logic can cause stream-level b= lockage (by refusing to read, which will exhaust any finite buffer).

     

    And I really like your suggestion that a naive recei= ver can use STREAM_BLOCKED as a signal to the application to decide whether= it wants to unblock a particular stream by temporarily giving it an extra = buffer allocation.  And since this is likely to be a very uncommon case, a na=EFve receiver may perform ok.

     

    • Igor

     <= /p>

    P.S.

     <= /p>

    I think the last p= roposal “limiting stream_data_offset to MAX(stream_max_data, connecti= on_max_data - SUM(stream_data_offset))” may actually simulate the way= we want to manage buffers better then the current design.  Either the transport is managing its own buffers, in which c= ase it is happy to dedicate all/most of them to the “common connectio= n pool” w/o per-stream limits and let the sender decide how to use th= em.  Or the transport is actually managing per-stream buffers belonging to applications, in which case the transport does not wa= nt to impose an arbitrary restriction on streams (in a form of the “M= AX_DATA”) and, instead, it may actually wish to “throw in”= ; some extra buffers of its own for the “common pool”.

     <= /p>

     <= /p>

     <= /p>

     

    From: Roberto Peon [mailto:fenix@fb.com]
    Sent: Tuesday, January 23, 2018 7:46 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; quic@ietf.org; igorl= ord@alum.mit.edu
    Subject: Re: Deadlock avoidance proposal

     

    Yes. That is why I'm saying= that this is a strategy that is up to an implementation.=


    For a naive receiver, which does not self-examine to see that it is blockin= g things, the STREAM_BLOCKED can allow a reaction within an RT.<= /span>


    The tradeoff, thus, is an RTT of delay when in the degraded state of h= aving a full buffer for a naive implementation.


    That may still be cheaper than causing connection reconnects as it wou= ld need to rexmit the in-flight data as well as losing the congestion conte= xt/state.

    Allocating 25% (or some similar amount) of memory to prevent an uncomm= on-case of blocking seems suboptimal. That memory could instead be used for= the common case, whether caching or additional connections...

    -=3DR

     

    From: Roberto Peon [mailto:fenix@fb.com]
    Sent: Tuesday, January 23, 2018 7:53 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; quic@ietf.org; igorl= ord@alum.mit.edu
    Subject: Re: Deadlock avoidance proposal

     

    I'm trying to avoid bikeshe= dding :)

    There is connection-level blockage, and stream-level blockage.

    One can cause the other, bu= t not *every* involved connection may be affected.

    With finite memory, blockage/deadlock cannot be prevented.


    The only 'real' solution is e2e acks (separate from p2p flow control), allo= wing intermediaries to discard data p2p, suffering only a decrease in effic= iency, i.e. to have the sender buffer data until the ultimate receiver has = received it.

    Everything else is a patch, not that I'd personally object to patches...

    -=3DR

    From: Lubashev, Igor <ilubashe@akamai.com>
    Sent: Tuesday, January 23, 2018 4:00:14 PM
    To: Lubashev, Igor; Roberto Peon; q= uic@ietf.org; igorlord@alum.mit.edu
    Subject: RE: Deadlock avoidance proposal

     <= o:p>

    • We must assume that any finite buffer can = be consumed. Thus, any partitioning of the available memory which is finite= cannot prevent this from occurring. When it occurs, it may induce indefini= te head-of-line-blocking on all flow-controlled upstream nodes in the topology.

     

    To be more specific, “it may induce indefinite h= ead-of-line-blocking on all flow-controlled upstream nodes in the topology&= #8221; is incorrect.  “Indefinite” blocking means deadlock.  HOL blocking – possible; deadlock – no.

     

    A deadlock is when NO stream can make any progress wit= hout killing some stream.  If each stream has “dedicated” = memory buffer (or the client is willing to dedicate a memory buffer to the highest-priority blocked stream), the highest-priority strea= m will not block – the receiver will consume it, free that stream-pri= vate buffer, and sender will send more data to that stream.

     

    • Igor

     

     

     

    From: Lubashev, Igor [mailto:il= ubashe@akamai.com]
    Sent: Tuesday, January 23, 2018 6:51 PM
    To: Roberto Peon <fenix@fb.com>; quic@ietf.org; igorlord@alum.m= it.edu
    Subject: RE: Deadlock avoidance proposal

     

    If you have finite buffer memory AND allow all of that= buffer memory to be used for any stream, you cannot avoid deadlocks. = However, if you dedicate some buffer memory to each stream (does not need to be much – just needs to be enough f= or one “message”), you can always make progress on your highest= -priority stream.

     

    The trade-off is that some memory may end up unused (m= emory dedicated to streams that do not have anything to send).

     

    If you want to increase your memory utilization even f= urther, you may end up doing blocked-stream detection (responding to STREAM= _BLOCKED frames) and give extra memory to those streams “just-in-time”.

     

    - Igor

     

    From: Roberto Peon [mailto:fenix@fb.co= m]
    Sent: Tuesday, January 23, 2018 6:34 PM
    To: Lubashev, Igor <ilubas= he@akamai.com>; quic@ietf.org; igorlord@alum.mit.edu
    Subject: Re: Deadlock avoidance proposal

     

    We must assume that any finite buffer can be consumed.= Thus, any partitioning of the available memory which is finite cannot prev= ent this from occurring. When it occurs, it may induce indefinite head-of-line-blocking on all flow-controlled upst= ream nodes in the topology.

    In other words, the problem is not preventable with any mechanism we introd= uce within the protocol. At best we can make it detectable and provide mech= anisms to limit the damage when it happens.

    The stream-data-credit stuff is a good mechanism to limit the damage while = still allowing for finite memory use, but it is useful only when/if an appl= ication knows that some action is required.

    There are alternate mechanisms that would also be useful: cancelling a stre= am, for instance.
    -=3DR

    p.s. the real problem is that we’ve delegated th= e ownership of the data to the intermediary by allowing the sender to flush= its bytes upon receiving p2p acks. The best solution here would be e2e acks (whether application-layer or transport or= both).

     

    From: "Lubashev, Igo= r" <ilubashe@akamai.com&= gt;
    Date: Wednesday, January 24, 2018 at 9:08 AM
    To: Roberto Peon <fenix@fb.com>, "quic@ietf.org" <<= a href=3D"mailto:quic@ietf.org">quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: RE: Deadlock avoidance proposal

     

    • The stream-data-credit would need to be ex= pressed as a stream offset (this resolves the races and allows the math you= have down there to work properly). I suspect this is what you mean in the = first place.

     

    Yes, the stream-data-credit in this proposal is expres= sed in ever-increasing offsets.

     

    • Otherwise, looks good. This would fall und= er the ‘allow more buffering at the application’ bullet Martin = had, but I believe that is a reasonable thing to do if it is constrained an= d directed by the application (which could decide to cancel a stream too).
    • Since flow control is e2e, this doesn̵= 7;t impact memory at a proxy.

     

    Exactly

     

    • What this doesn’t solve is the detec= tion problem.

     

    If you look at my follow-up proposal (which is effecti= vely changing the meaning of max_stream_data to mean stream_data_credit), y= ou may not need to have robust deadlock detection, because deadlocks due to transport cannot happen.  The onl= y deadlocks possible with the follow-up scheme are deadlocks due to the app= lication’s circular dependency, not sender’s choice of which st= ream to send first


    -=3DR

     

     

    From: QUIC <quic-bounces@ietf.org> on behalf of &= quot;Lubashev, Igor" <ilubas= he@akamai.com>
    Date: Tuesday, January 23, 2018 at 2:50 PM
    To: "quic@ietf.org" &= lt;quic@ietf.org>, "igorlord@alum.mit.edu" <igorlord@alum.mit.edu>
    Subject: Deadlock avoidance proposal

     

    The problem with deadlocking QUIC streams is the possi= bility that the sender (or proxy) will “use up” connection flow= control credits on lower-priority streams, blocking the receiver from making forward progress with any streams.  The rece= iver has no mechanism to direct/force the sender to send on preferred strea= ms.

     

    I would like to propose a concept of “stream dat= a credit” – the concept of extra flow control credits that can = only be used by a specific stream.  A STREAM_DATA_CREDIT frame would update such credits (see below).  Data sent on a stream w= ill consume its own credits as much as it can and connection credits (updat= ed by MAX_DATA) for the rest of the data.

     

    The updated connection flow control accounting: 

     

    “

    For each stream, “used connection credits”= is “MAX(the_largest_received_offset - stream_data_credits, 0)”= .

     

    The sum of “used connection credits” on al= l streams -

    including streams in terminal states, but excluding st= ream 0 - MUST NOT exceed

    the value advertised by a receiver (i.e. MAX_DATA).&nb= sp; An endpoint MUST terminate a connection

    with a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA error = if it used more connection credits

    than the maximum data value that it has sent, unless t= his is a result of a

    change in the initial limits (see {{zerortt-parameters= }}).

    “

     

    The receiver will be able to grant dedicated credits t= o the high-priority stream w/o requiring the sender or the intermediary to = know anything about the semantics of the protocol and without worrying that the sender/intermediary will “squ= ander” the credits on unimportant streams.

     

     

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

     

    STREAM_DATA_CREDIT frame.

     

    The frame updates Data Credit for a stream.=

     

    ~~~

    0         = ;          1   =             &nb= sp;   2         &nbs= p;         3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 = 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+

    |         = ;            &n= bsp;  Stream ID (i)        &nb= sp;            =    ...

    +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+

    |         = ;            &n= bsp;  Data Credit (i)        &= nbsp;           &nbs= p;   ...

    +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+

    ~~~

     

    The fields in the STREAM_DATA_CREDIT frame are as foll= ows:

     

    Stream ID:

     

    : The stream ID of the stream that is affected encoded= as a variable-length

      integer.

     

    Data Credit:

     

    : A variable-length integer indicating the new total d= ata credit for the stream.

     

    For each stream Data Credit starts with 0.  The s= ender can only increase Data Credit in subsequent STREAM_DATA_CREDIT frames= for the same stream, but loss and reordering can cause STREAM_DATA_CREDIT frames to be received out of order.  STR= EAM_DATA_CREDIT frames that do not advance Data Credit for the stream MUST = be ignored.

     

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

     

     

    Comments?

     

    • Igor
    --_000_1a3f48cacd154d70b31008d7b3269c30usma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 21:08:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E87F12D959 for ; Tue, 23 Jan 2018 21:08:38 -0800 (PST) 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 0QQ74cjPp5s2 for ; Tue, 23 Jan 2018 21:08:36 -0800 (PST) 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 E98DA1275C5 for ; Tue, 23 Jan 2018 21:08:35 -0800 (PST) Received: by mail-wr0-x230.google.com with SMTP id e41so2834298wre.9 for ; Tue, 23 Jan 2018 21:08:35 -0800 (PST) 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=OT6doIcx2s1g8k+cwE5ECdNFLyxRQ4jpLiiZ2AUHNbE=; b=jOVtG1g1zg2d3FVGC2Bvz/Tt+jfWk7vubxhrCzjzowZORAo2IT8E4405bVwI03B2Iw VTgKzN2hiNZvWAJnpvwloN0Ph/82qSYbxqzfJ/1gIGFOslJ76J1BHOvI6QSnONFsK0rI 6qGHyOEeQYrUZVIYGoNnRfY/Ct/RGclJUhVZOodD9uG3g+oJZ8WL/7XsNvc4oVK1ypLC YlHKGVslbxSrKWoipLaIMb00Kf25RfH4XhY4yDBHPgmkUVEAz7DCLTAj4Ef9GIj6qA3E 1x86ZOxXbui2qZZ8P9jed4PgIZp/rfN9CYscPzaoYiO6yyHjNR+nCl7Xq47jBZLZd6fj E78Q== 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=OT6doIcx2s1g8k+cwE5ECdNFLyxRQ4jpLiiZ2AUHNbE=; b=QioFzRYUVCpwdjrkGhQBYHOEsTkul4jS6DjCjIw0KanBkxGCLSsdDlL0ovKxEjTyq2 NeqCxepoEHKVnspATauBhLbuDlKm8KpYyCBRuRLk5atLEM8tTyeeYefk4yf6ZW5k0lWi tXqRmu8m91S9Uq6KHp8TcLDuO3o+/m9LJE06XlprmyNwLVxAWR5SQ7NWBXhXllvs/3l6 xtGghMq6/PKRcEwXMFAPFbR46P3PkRiFQD/Hz/iReGTBZorjTvQE3y7/jSkbnsSJedLE U7xrL5qGJnLru01H/4fQizQ/RLQz8685SGSox4C/WuMnhqAv9QOZj3qUEOMi2eU58FLn 4nGw== X-Gm-Message-State: AKwxytda3k6CfrAzoj3BX4Cxp+Sc5y8ej8VIJEdLurKLDMorPMYrsUTQ oXNTPjqmfwu6hE1G/u9F08QEc+mGhE3pEZTkiQAc+w== X-Google-Smtp-Source: AH8x224hIhxF3cHh6EAGqQV1JPZTIz/PL+2jHcyveZ6GTBZBui9QpnRSlrA3HoHxNp/F4Mr+SwKjMlHJM4t7guspxew= X-Received: by 10.223.149.153 with SMTP id p25mr4786233wrp.155.1516770514156; Tue, 23 Jan 2018 21:08:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.190.140 with HTTP; Tue, 23 Jan 2018 21:08:33 -0800 (PST) From: Martin Duke Date: Wed, 24 Jan 2018 16:08:33 +1100 Message-ID: Subject: A better way to do conn id? To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045de7a8b3c4d805637ea74a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 05:08:38 -0000 --f403045de7a8b3c4d805637ea74a Content-Type: text/plain; charset="UTF-8" Today's variable-length connection ID discussion made me realize some problems with the current architecture, while the new architecture doesn't fix some of them and creates whole new ones. Issues: - The client desires unlinkability, but I suspect the market will provide no incentives for servers to work very hard to be unlinkable. There were conflicting "layer 9" arguments that variable conn ID makes this problem worse or better. - 16 Bytes is more overhead than 8 bytes. - The severity of this remains to be seen, but variable length conn ids will introduce more complexity in parsers and anything that utilizes the conn id (e.g. handshake key generation). It might make the invariants more complex as well. The whole thing, frankly, makes my head hurt. I humbly suggest the following proposal might avoid or mitigate some of these problems: 1. Every connection has a long-lived Client-generated Connection ID (CGCID) and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the SGCID is 16 bytes. 2. The CGCID is used to derive the handshake key. (unchanged from status quo) 3. The initial packet uses the CGCID. All other handshake packets use the SGCID. This is unchanged from the status quo. 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT packets sent by the server use the CGCID. This has two important properties: a) The server gets the 16 Bytes of entropy the load balancer needs b) The server->client direction, which in the usual case has most of the data, has a lower-overhead CID. 5. The algorithm that generates SGCID MUST have different output given a different CGCID. [We might strengthen this language further: you wouldn't want to simply add the NEW_CONN_ID sequence number to the existing SGCID, for instance]. 6. In advance of migration, the client sends a NEW_CONN_ID frame to provide a new CGCID (possibly omitting the stateless reset token). The server MUST respond with a NEW_CONN_ID that provides a new SGCID derived from the new CGCID. All packets on the new path use these CIDs. If people like this, I can generate a PR. I am very open to various tweaks to the general approach as well. I wanted to get this out there before the variable-length CID team gets deep in the weeds. Martin Duke --f403045de7a8b3c4d805637ea74a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Today's variable-length connect= ion ID discussion made me realize some problems with the current architectu= re, while the new architecture doesn't fix some of them and creates who= le new ones. Issues:

    - The client desires unlinkab= ility, but I suspect the market will provide no incentives for servers to w= ork very hard to be unlinkable. There were conflicting "layer 9" = arguments that variable conn ID makes this problem worse or better.

    - 16 Bytes is more overhead than 8 bytes.

    <= /div>
    - The severity of this remains to be seen, but variable length co= nn ids will introduce more complexity in parsers and anything that utilizes= the conn id (e.g. handshake key generation). It might make the invariants = more complex as well. The whole thing, frankly, makes my head hurt.

    I humbly suggest the following proposal might avoid or mi= tigate some of these problems:

    1. Every connection= has a long-lived Client-generated Connection ID (CGCID) and Server-generat= ed Connection ID (SGCID). The CGCID is 8 bytes and the SGCID is 16 bytes.

    2. The CGCID is used to derive the handshake key. (= unchanged from status quo)

    3. The initial packet u= ses the CGCID.=C2=A0 All other handshake packets use the SGCID. This is unc= hanged from the status quo.

    4. All 1-RTT packets b= y sent by the client use the SGCID. All 1-RTT packets sent by the server us= e the CGCID. This has two important properties:
    =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0a) The server gets the 16 Bytes of entropy the load= balancer needs
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0b) The s= erver->client direction, which in the usual case has most of the data, h= as a lower-overhead CID.

    5. The algorithm that gen= erates SGCID MUST have different output given a different CGCID. [We might = strengthen this language further: you wouldn't want to simply add the N= EW_CONN_ID sequence number to the existing SGCID, for instance].
    =
    6. In advance of migration, the client sends a NEW_CONN_ID f= rame to provide a new CGCID (possibly omitting the stateless reset token). = The server MUST respond with a NEW_CONN_ID that provides a new SGCID derive= d from the new CGCID. All packets on the new path use these CIDs.

    If people like this, I can generate a PR. I am very open to= various tweaks to the general approach as well. I wanted to get this out t= here before the variable-length CID team gets deep in the weeds.
    =
    Martin Duke


    --f403045de7a8b3c4d805637ea74a-- From nobody Tue Jan 23 21:19:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4112D958 for ; Tue, 23 Jan 2018 21:19:42 -0800 (PST) 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 iUf4EWsC0SxX for ; Tue, 23 Jan 2018 21:19:41 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034031275C5 for ; Tue, 23 Jan 2018 21:19:41 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id d124so2036780oib.13 for ; Tue, 23 Jan 2018 21:19:40 -0800 (PST) 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=uGRKBGR3xmuzs8++HwdFQdXzZA5lRkcF8YC9Dk5LbYM=; b=I3QCLf9wnEW56xNHGZ42zwCEM9lj1qHMu0bX2t9Qdssv70ZwgnmC9xC3+ogk590TDZ ly9f3C4ijDsCrou4uMpQEVeh05nSWgeRWyrwgSlRple2/reXSt2/XIPPSWL6Ur0ug93T amCXnaNdmdRTgwusz2Ld3ZJsHaRWsbYbak2lEvoEZyhBpmregMWKPC8QZv4wSXrNQjrW lpai/1W44RRBbFI8sJs4KR0aWEX6gLAZSMBUXNE8mF243gM8Immtlcy8C+dk4jKhz3ej ZnZsAtpm1i8aFkLS7TTf7JnfAgYnnSRQqLU2ukv+Gi7GprLtP5HF1N1sJ78DxjnIkBW7 WiOg== 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=uGRKBGR3xmuzs8++HwdFQdXzZA5lRkcF8YC9Dk5LbYM=; b=V368Dpm/dE9zSS4vKA16vq/PQWr2FFJxcnB4NKKvyuER3TDWClOi4nP7cJbLtLYNcQ 0z9sFJDPr63WnKCmhmtzr/iwitUxlz0YQIUJYLsiJstzK8WW+XadP8k3h1GpFhyFrNOC Yn9sDhMw+P7oSigqaJEG1wTFpTy+7bDmKDS8bOly6JmatikgUlcali2A56EL3zyN9RPQ wROtBRf2Tmcjl+dpg2fU9Eiy9UWAvxEbP+QZiX2qfi86POy6xZz005wl+nYPcun4rYH1 fbiYTqcRJhu16SgKy190c6WlXUcrA69sb/EPmTqsNGfop2dXXOGpVX0ZjzpbQ0s42/yL icXQ== X-Gm-Message-State: AKwxytfJrxsurR9THjRFYOiTAGulLRJgnKAyg0ddfohsNV5jJRPAt/2p BmYSm7n2L8ne7KcRCV5Zmnsd67SdlJFx8yK+7jg= X-Google-Smtp-Source: AH8x224qtSFuReuTq9Y9jxQdTs//K1QnnfpZMdr4lGjGgkiX6iqY9CGmfHDRE/FO0YCzxMzP2XZ5nyKGvbjgoAn0IIc= X-Received: by 10.202.106.67 with SMTP id f64mr7840793oic.92.1516771180195; Tue, 23 Jan 2018 21:19:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Tue, 23 Jan 2018 21:19:39 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 24 Jan 2018 16:19:39 +1100 Message-ID: Subject: Re: A better way to do conn id? To: Martin Duke 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: Wed, 24 Jan 2018 05:19:43 -0000 We have already concluded that if you want to do sane crypto, plus some sort of key identification, then you need MORE than 16 octets (though not much more). That makes things more complicated. ekr has an outcome that he will write up. On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke wrote: > Today's variable-length connection ID discussion made me realize some > problems with the current architecture, while the new architecture doesn't > fix some of them and creates whole new ones. Issues: > > - The client desires unlinkability, but I suspect the market will provide no > incentives for servers to work very hard to be unlinkable. There were > conflicting "layer 9" arguments that variable conn ID makes this problem > worse or better. > > - 16 Bytes is more overhead than 8 bytes. > > - The severity of this remains to be seen, but variable length conn ids will > introduce more complexity in parsers and anything that utilizes the conn id > (e.g. handshake key generation). It might make the invariants more complex > as well. The whole thing, frankly, makes my head hurt. > > I humbly suggest the following proposal might avoid or mitigate some of > these problems: > > 1. Every connection has a long-lived Client-generated Connection ID (CGCID) > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the > SGCID is 16 bytes. > > 2. The CGCID is used to derive the handshake key. (unchanged from status > quo) > > 3. The initial packet uses the CGCID. All other handshake packets use the > SGCID. This is unchanged from the status quo. > > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT packets > sent by the server use the CGCID. This has two important properties: > a) The server gets the 16 Bytes of entropy the load balancer > needs > b) The server->client direction, which in the usual case has most > of the data, has a lower-overhead CID. > > 5. The algorithm that generates SGCID MUST have different output given a > different CGCID. [We might strengthen this language further: you wouldn't > want to simply add the NEW_CONN_ID sequence number to the existing SGCID, > for instance]. > > 6. In advance of migration, the client sends a NEW_CONN_ID frame to provide > a new CGCID (possibly omitting the stateless reset token). The server MUST > respond with a NEW_CONN_ID that provides a new SGCID derived from the new > CGCID. All packets on the new path use these CIDs. > > If people like this, I can generate a PR. I am very open to various tweaks > to the general approach as well. I wanted to get this out there before the > variable-length CID team gets deep in the weeds. > > Martin Duke > > From nobody Tue Jan 23 21:21:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E4912D959 for ; Tue, 23 Jan 2018 21:21:21 -0800 (PST) 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 Fyb2kLGVazpl for ; Tue, 23 Jan 2018 21:21:18 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 AC9CB1275C5 for ; Tue, 23 Jan 2018 21:21:17 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id i186so5937223wmi.4 for ; Tue, 23 Jan 2018 21:21:17 -0800 (PST) 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=sva1wroGVcwAeqC28Tple5SPb+M7kVlRve1wmIIKr08=; b=ujk8swVK0kbpIRuTSPgYE0LXdFMSIcaAYFBkCO/CD5XPNzVhWUPe02v+U3OMssuj0o c5Dlw5uzgI6BQZy7RlPsd5rswTJyIdCrYW/PSkddOlJj0GEFUaRFR7bIw+zOPfDECXk6 InpLNt+f5GevYiI4ghVYhtZ0KJ7i3SpNk6CTZeJ32ld6wx0SCOiaZTsDUWmscTdn7bBs BODiRuN8s57gxfQVb61TsdWH3z8w87xDvoDBZ+heOaFUnq6iSDDot0VTZkhwqPvSC/5v 4DpD3aAEgIDlaOaiuzoSLRpCbAUPyY/L02OrBYM6MNeqeCgY3FX581eSrOdXn4F+5iUT JQig== 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=sva1wroGVcwAeqC28Tple5SPb+M7kVlRve1wmIIKr08=; b=Ho8WBRA61KV1l4TBB/Uc1EfLVgrh+kz+0yHYOzcNqrKjVrOU09bP7i5UjYvdm8iPmu jZBg3srwh4oLQ5CNszcrjNdRf2D2YWSxzHzwLIlaAuZR2hXxFm5na6hzGwSOEqhdAC9h QGh3C5MSOGjpxLViZvZiaCv6x3idbvFjexXP9q4Ve9LleCVs04oPh1YR4v97d3KDBH4I dyWXvEKn05xJrEf9VF4SJymRsSnLUU2jWvVzo/pVyRMxT6gwU+WZyyj0sbQNEllEzeXO eaDvxfa2B+4vyYU7Cbs/rKM8fyT+nOVFs0P4e3fFVoePIOMGbCLmMbUzd80gjFgRhtLO 50UQ== X-Gm-Message-State: AKwxyteFZuJVwNRUgpwY2cAiCAxXWrCK1+hZsAm/Cm6sr2uwjk4B3ePY H9s4kU3E5LQIOzIOL8A7PLSsw/Ns5gpD0b4TfPw= X-Google-Smtp-Source: AH8x226mGJJsFU1MUa786DcveqhiVJVuQT6q/KqK5CAew3Rc1Dgv8DOtdzJjNMpTY5qr5eY0Cw1RFfKMHfeyrw16Uv4= X-Received: by 10.28.190.3 with SMTP id o3mr4024345wmf.17.1516771276271; Tue, 23 Jan 2018 21:21:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.190.140 with HTTP; Tue, 23 Jan 2018 21:21:15 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 24 Jan 2018 16:21:15 +1100 Message-ID: Subject: Re: A better way to do conn id? To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e083161d420b68105637ed5d4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 05:21:21 -0000 --089e083161d420b68105637ed5d4 Content-Type: text/plain; charset="UTF-8" Very well, replace 16 with whatever number you guys come up with. On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson wrote: > We have already concluded that if you want to do sane crypto, plus > some sort of key identification, then you need MORE than 16 octets > (though not much more). That makes things more complicated. ekr has > an outcome that he will write up. > > On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke > wrote: > > Today's variable-length connection ID discussion made me realize some > > problems with the current architecture, while the new architecture > doesn't > > fix some of them and creates whole new ones. Issues: > > > > - The client desires unlinkability, but I suspect the market will > provide no > > incentives for servers to work very hard to be unlinkable. There were > > conflicting "layer 9" arguments that variable conn ID makes this problem > > worse or better. > > > > - 16 Bytes is more overhead than 8 bytes. > > > > - The severity of this remains to be seen, but variable length conn ids > will > > introduce more complexity in parsers and anything that utilizes the conn > id > > (e.g. handshake key generation). It might make the invariants more > complex > > as well. The whole thing, frankly, makes my head hurt. > > > > I humbly suggest the following proposal might avoid or mitigate some of > > these problems: > > > > 1. Every connection has a long-lived Client-generated Connection ID > (CGCID) > > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the > > SGCID is 16 bytes. > > > > 2. The CGCID is used to derive the handshake key. (unchanged from status > > quo) > > > > 3. The initial packet uses the CGCID. All other handshake packets use > the > > SGCID. This is unchanged from the status quo. > > > > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT > packets > > sent by the server use the CGCID. This has two important properties: > > a) The server gets the 16 Bytes of entropy the load balancer > > needs > > b) The server->client direction, which in the usual case has > most > > of the data, has a lower-overhead CID. > > > > 5. The algorithm that generates SGCID MUST have different output given a > > different CGCID. [We might strengthen this language further: you wouldn't > > want to simply add the NEW_CONN_ID sequence number to the existing SGCID, > > for instance]. > > > > 6. In advance of migration, the client sends a NEW_CONN_ID frame to > provide > > a new CGCID (possibly omitting the stateless reset token). The server > MUST > > respond with a NEW_CONN_ID that provides a new SGCID derived from the new > > CGCID. All packets on the new path use these CIDs. > > > > If people like this, I can generate a PR. I am very open to various > tweaks > > to the general approach as well. I wanted to get this out there before > the > > variable-length CID team gets deep in the weeds. > > > > Martin Duke > > > > > --089e083161d420b68105637ed5d4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Very well, replace 16 with whatever number you guys come u= p with.

    On W= ed, Jan 24, 2018 at 4:19 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
    We have alread= y concluded that if you want to do sane crypto, plus
    some sort of key identification, then you need MORE than 16 octets
    (though not much more).=C2=A0 That makes things more complicated.=C2=A0 ekr= has
    an outcome that he will write up.

    On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
    > Today's variable-length connection ID discussion made me realize s= ome
    > problems with the current architecture, while the new architecture doe= sn't
    > fix some of them and creates whole new ones. Issues:
    >
    > - The client desires unlinkability, but I suspect the market will prov= ide no
    > incentives for servers to work very hard to be unlinkable. There were<= br> > conflicting "layer 9" arguments that variable conn ID makes = this problem
    > worse or better.
    >
    > - 16 Bytes is more overhead than 8 bytes.
    >
    > - The severity of this remains to be seen, but variable length conn id= s will
    > introduce more complexity in parsers and anything that utilizes the co= nn id
    > (e.g. handshake key generation). It might make the invariants more com= plex
    > as well. The whole thing, frankly, makes my head hurt.
    >
    > I humbly suggest the following proposal might avoid or mitigate some o= f
    > these problems:
    >
    > 1. Every connection has a long-lived Client-generated Connection ID (C= GCID)
    > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and t= he
    > SGCID is 16 bytes.
    >
    > 2. The CGCID is used to derive the handshake key. (unchanged from stat= us
    > quo)
    >
    > 3. The initial packet uses the CGCID.=C2=A0 All other handshake packet= s use the
    > SGCID. This is unchanged from the status quo.
    >
    > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT pa= ckets
    > sent by the server use the CGCID. This has two important properties: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a) The server gets the 16 Byt= es of entropy the load balancer
    > needs
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b) The server->client dire= ction, which in the usual case has most
    > of the data, has a lower-overhead CID.
    >
    > 5. The algorithm that generates SGCID MUST have different output given= a
    > different CGCID. [We might strengthen this language further: you would= n't
    > want to simply add the NEW_CONN_ID sequence number to the existing SGC= ID,
    > for instance].
    >
    > 6. In advance of migration, the client sends a NEW_CONN_ID frame to pr= ovide
    > a new CGCID (possibly omitting the stateless reset token). The server = MUST
    > respond with a NEW_CONN_ID that provides a new SGCID derived from the = new
    > CGCID. All packets on the new path use these CIDs.
    >
    > If people like this, I can generate a PR. I am very open to various tw= eaks
    > to the general approach as well. I wanted to get this out there before= the
    > variable-length CID team gets deep in the weeds.
    >
    > Martin Duke
    >
    >

    --089e083161d420b68105637ed5d4-- From nobody Tue Jan 23 21:34:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1171275C5 for ; Tue, 23 Jan 2018 21:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ms2BwAPSR-8B for ; Tue, 23 Jan 2018 21:34:51 -0800 (PST) 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 A714812D95C for ; Tue, 23 Jan 2018 21:34:51 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0O5OMpH020212; Wed, 24 Jan 2018 05:34:50 GMT 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=7ZCJ/RzOBDmYQ7SV2JhjKe6cE0gyvN7/qPM6GpJMFMU=; b=HvMXwIVDL/MG+/3AiyvMWF6f6Ai5sT9vZ5rOv/1DjGe2QLHpH+ZBZUkf1kqL3r8RT/9a 6NgPNbXMRY0HudFhlzTRxdJcyBIzYJXu0JKQooiQ4a5Yw+dB224d1gFhjES5AuAaUQXW kFwo/L939NealXOlcrkYxpUDLJcnJcJvAyOnjc0qtjb5vrb1WzYeGZezvuTK+f3ihDNc WHJbQcfwO+/WB8wX72/G0Y4bU4aPU4kSbzU6BXQ7F/BX2KmmWxViTbiTKtW0/FwARFaF sVa3Ab4lI298KdT+OPHAARr/mmxjK2SxI0FjzI5FGwvh5KG8p8khpZmxWFVrI9+VuCpL 1w== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2fkxa1uwuh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 05:34:49 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0O5X3of021517; Wed, 24 Jan 2018 00:34:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fm20em530-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 00:34:48 -0500 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, 24 Jan 2018 00:34:47 -0500 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, 24 Jan 2018 00:34:47 -0500 From: "Lubashev, Igor" To: Martin Duke , Martin Thomson CC: IETF QUIC WG Subject: RE: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNFo0y0NS2zYe0mRyyv7KOC+e6OC0AuAgAAAc4D//60wMA== Date: Wed, 24 Jan 2018 05:34:47 +0000 Message-ID: <6d7331bfb9e041e4a712f3edf99a3001@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.38.42] Content-Type: multipart/alternative; boundary="_000_6d7331bfb9e041e4a712f3edf99a3001usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240070 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_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 mlxscore=0 impostorscore=0 mlxlogscore=972 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240069 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 05:34:55 -0000 --_000_6d7331bfb9e041e4a712f3edf99a3001usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHR3byBhbHRlcm5hdGl2ZXMgdG8gYWxsb3cgZm9yIGtleSByb3RhdGlvbiB0byDigJxhdm9p ZOKAnSBnb2luZyBvdmVyIDE2IG9jdGV0cyBhcmU6DQoNCg0KICAxLiAgKFZpY3RvciB2b2ljZWQg dGhpcyB0b2RheSkgU3RlYWwgYSBjb2RlIHBvaW50IGZyb20gdGhlIHBhY2tldCB0eXBlOiBoYXZl IDIgYml0cyB0aGF0IHJlcHJlc2VudDoNCjAtYnl0ZSBjb25uZWN0aW9uIGlkOw0KOC1ieXRlIGNv bm5lY3Rpb24gaWQ7DQoxNi1ieXRlIGNvbm5lY3Rpb24gaWQgKGtleSBhKTsNCjE2LWJ5dGUgY29u bmVjdGlvbiBpZCAoa2V5IGIpDQoNCg0KICAxLiAg4oCcVHJpYWwgRW5jcnlwdGlvbuKAnSA6IFN0 ZWFsIGEgYml0IGZyb20geW91ciAxMjggYml0IGNvbm5lY3Rpb24gSUQNCg0KWW91ciBiaXQgMCBv ZiB5b3VyIENvbm5lY3Rpb24gSUQgd2lsbCByZXByZXNlbnQgdGhlIGtleSB1c2VkIGZvciBlbmNy eXB0aW9uLg0KU2luY2UgeW91IGhhdmUgZW50cm9weSBpbiB5b3VyIENvbm5lY3Rpb24gSUQsIGtl ZXAgZ2VuZXJhdGluZyBuZXcgZW50cm9weSBhbmQgZW5jcnlwdGluZywgdW50aWwgYml0IDAgY29t ZXMgb3V0IGp1c3QgdGhlIHdheSB5b3Ugd2FudCBpdC4gIE9uIGF2ZXJhZ2UsIHlvdSB3aWxsIGRv IDAuNzUgZXh0cmEgZW5jcnlwdGlvbiBvcGVyYXRpb25zLg0KDQoNCiAgKiAgIElnb3INCg0KRnJv bTogTWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSmFudWFyeSAyNCwgMjAxOCAxMjoyMSBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IEEgYmV0dGVyIHdheSB0byBkbyBjb25uIGlkPw0KDQpWZXJ5IHdlbGws IHJlcGxhY2UgMTYgd2l0aCB3aGF0ZXZlciBudW1iZXIgeW91IGd1eXMgY29tZSB1cCB3aXRoLg0K DQpPbiBXZWQsIEphbiAyNCwgMjAxOCBhdCA0OjE5IFBNLCBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PiB3cm90 ZToNCldlIGhhdmUgYWxyZWFkeSBjb25jbHVkZWQgdGhhdCBpZiB5b3Ugd2FudCB0byBkbyBzYW5l IGNyeXB0bywgcGx1cw0Kc29tZSBzb3J0IG9mIGtleSBpZGVudGlmaWNhdGlvbiwgdGhlbiB5b3Ug bmVlZCBNT1JFIHRoYW4gMTYgb2N0ZXRzDQoodGhvdWdoIG5vdCBtdWNoIG1vcmUpLiAgVGhhdCBt YWtlcyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZC4gIGVrciBoYXMNCmFuIG91dGNvbWUgdGhhdCBo ZSB3aWxsIHdyaXRlIHVwLg0KDQpPbiBXZWQsIEphbiAyNCwgMjAxOCBhdCA0OjA4IFBNLCBNYXJ0 aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21h aWwuY29tPj4gd3JvdGU6DQo+IFRvZGF5J3MgdmFyaWFibGUtbGVuZ3RoIGNvbm5lY3Rpb24gSUQg ZGlzY3Vzc2lvbiBtYWRlIG1lIHJlYWxpemUgc29tZQ0KPiBwcm9ibGVtcyB3aXRoIHRoZSBjdXJy ZW50IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIG5ldyBhcmNoaXRlY3R1cmUgZG9lc24ndA0KPiBm aXggc29tZSBvZiB0aGVtIGFuZCBjcmVhdGVzIHdob2xlIG5ldyBvbmVzLiBJc3N1ZXM6DQo+DQo+ IC0gVGhlIGNsaWVudCBkZXNpcmVzIHVubGlua2FiaWxpdHksIGJ1dCBJIHN1c3BlY3QgdGhlIG1h cmtldCB3aWxsIHByb3ZpZGUgbm8NCj4gaW5jZW50aXZlcyBmb3Igc2VydmVycyB0byB3b3JrIHZl cnkgaGFyZCB0byBiZSB1bmxpbmthYmxlLiBUaGVyZSB3ZXJlDQo+IGNvbmZsaWN0aW5nICJsYXll ciA5IiBhcmd1bWVudHMgdGhhdCB2YXJpYWJsZSBjb25uIElEIG1ha2VzIHRoaXMgcHJvYmxlbQ0K PiB3b3JzZSBvciBiZXR0ZXIuDQo+DQo+IC0gMTYgQnl0ZXMgaXMgbW9yZSBvdmVyaGVhZCB0aGFu IDggYnl0ZXMuDQo+DQo+IC0gVGhlIHNldmVyaXR5IG9mIHRoaXMgcmVtYWlucyB0byBiZSBzZWVu LCBidXQgdmFyaWFibGUgbGVuZ3RoIGNvbm4gaWRzIHdpbGwNCj4gaW50cm9kdWNlIG1vcmUgY29t cGxleGl0eSBpbiBwYXJzZXJzIGFuZCBhbnl0aGluZyB0aGF0IHV0aWxpemVzIHRoZSBjb25uIGlk DQo+IChlLmcuIGhhbmRzaGFrZSBrZXkgZ2VuZXJhdGlvbikuIEl0IG1pZ2h0IG1ha2UgdGhlIGlu dmFyaWFudHMgbW9yZSBjb21wbGV4DQo+IGFzIHdlbGwuIFRoZSB3aG9sZSB0aGluZywgZnJhbmts eSwgbWFrZXMgbXkgaGVhZCBodXJ0Lg0KPg0KPiBJIGh1bWJseSBzdWdnZXN0IHRoZSBmb2xsb3dp bmcgcHJvcG9zYWwgbWlnaHQgYXZvaWQgb3IgbWl0aWdhdGUgc29tZSBvZg0KPiB0aGVzZSBwcm9i bGVtczoNCj4NCj4gMS4gRXZlcnkgY29ubmVjdGlvbiBoYXMgYSBsb25nLWxpdmVkIENsaWVudC1n ZW5lcmF0ZWQgQ29ubmVjdGlvbiBJRCAoQ0dDSUQpDQo+IGFuZCBTZXJ2ZXItZ2VuZXJhdGVkIENv bm5lY3Rpb24gSUQgKFNHQ0lEKS4gVGhlIENHQ0lEIGlzIDggYnl0ZXMgYW5kIHRoZQ0KPiBTR0NJ RCBpcyAxNiBieXRlcy4NCj4NCj4gMi4gVGhlIENHQ0lEIGlzIHVzZWQgdG8gZGVyaXZlIHRoZSBo YW5kc2hha2Uga2V5LiAodW5jaGFuZ2VkIGZyb20gc3RhdHVzDQo+IHF1bykNCj4NCj4gMy4gVGhl IGluaXRpYWwgcGFja2V0IHVzZXMgdGhlIENHQ0lELiAgQWxsIG90aGVyIGhhbmRzaGFrZSBwYWNr ZXRzIHVzZSB0aGUNCj4gU0dDSUQuIFRoaXMgaXMgdW5jaGFuZ2VkIGZyb20gdGhlIHN0YXR1cyBx dW8uDQo+DQo+IDQuIEFsbCAxLVJUVCBwYWNrZXRzIGJ5IHNlbnQgYnkgdGhlIGNsaWVudCB1c2Ug dGhlIFNHQ0lELiBBbGwgMS1SVFQgcGFja2V0cw0KPiBzZW50IGJ5IHRoZSBzZXJ2ZXIgdXNlIHRo ZSBDR0NJRC4gVGhpcyBoYXMgdHdvIGltcG9ydGFudCBwcm9wZXJ0aWVzOg0KPiAgICAgICAgICAg IGEpIFRoZSBzZXJ2ZXIgZ2V0cyB0aGUgMTYgQnl0ZXMgb2YgZW50cm9weSB0aGUgbG9hZCBiYWxh bmNlcg0KPiBuZWVkcw0KPiAgICAgICAgICAgIGIpIFRoZSBzZXJ2ZXItPmNsaWVudCBkaXJlY3Rp b24sIHdoaWNoIGluIHRoZSB1c3VhbCBjYXNlIGhhcyBtb3N0DQo+IG9mIHRoZSBkYXRhLCBoYXMg YSBsb3dlci1vdmVyaGVhZCBDSUQuDQo+DQo+IDUuIFRoZSBhbGdvcml0aG0gdGhhdCBnZW5lcmF0 ZXMgU0dDSUQgTVVTVCBoYXZlIGRpZmZlcmVudCBvdXRwdXQgZ2l2ZW4gYQ0KPiBkaWZmZXJlbnQg Q0dDSUQuIFtXZSBtaWdodCBzdHJlbmd0aGVuIHRoaXMgbGFuZ3VhZ2UgZnVydGhlcjogeW91IHdv dWxkbid0DQo+IHdhbnQgdG8gc2ltcGx5IGFkZCB0aGUgTkVXX0NPTk5fSUQgc2VxdWVuY2UgbnVt YmVyIHRvIHRoZSBleGlzdGluZyBTR0NJRCwNCj4gZm9yIGluc3RhbmNlXS4NCj4NCj4gNi4gSW4g YWR2YW5jZSBvZiBtaWdyYXRpb24sIHRoZSBjbGllbnQgc2VuZHMgYSBORVdfQ09OTl9JRCBmcmFt ZSB0byBwcm92aWRlDQo+IGEgbmV3IENHQ0lEIChwb3NzaWJseSBvbWl0dGluZyB0aGUgc3RhdGVs ZXNzIHJlc2V0IHRva2VuKS4gVGhlIHNlcnZlciBNVVNUDQo+IHJlc3BvbmQgd2l0aCBhIE5FV19D T05OX0lEIHRoYXQgcHJvdmlkZXMgYSBuZXcgU0dDSUQgZGVyaXZlZCBmcm9tIHRoZSBuZXcNCj4g Q0dDSUQuIEFsbCBwYWNrZXRzIG9uIHRoZSBuZXcgcGF0aCB1c2UgdGhlc2UgQ0lEcy4NCj4NCj4g SWYgcGVvcGxlIGxpa2UgdGhpcywgSSBjYW4gZ2VuZXJhdGUgYSBQUi4gSSBhbSB2ZXJ5IG9wZW4g dG8gdmFyaW91cyB0d2Vha3MNCj4gdG8gdGhlIGdlbmVyYWwgYXBwcm9hY2ggYXMgd2VsbC4gSSB3 YW50ZWQgdG8gZ2V0IHRoaXMgb3V0IHRoZXJlIGJlZm9yZSB0aGUNCj4gdmFyaWFibGUtbGVuZ3Ro IENJRCB0ZWFtIGdldHMgZGVlcCBpbiB0aGUgd2VlZHMuDQo+DQo+IE1hcnRpbiBEdWtlDQo+DQo+ DQoNCg== --_000_6d7331bfb9e041e4a712f3edf99a3001usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUwODg0NTE1Ow0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODUzODcxNzA2IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjczMDAz NDk1MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM5 OTQ5MjE1NiAzMjc3MjY5NDAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0d28gYWx0ZXJuYXRpdmVzIHRvIGFsbG93IGZvciBrZXkg cm90YXRpb24gdG8g4oCcYXZvaWTigJ0gZ29pbmcgb3ZlciAxNiBvY3RldHMgYXJlOjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wg c3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPihWaWN0b3Igdm9pY2VkIHRoaXMgdG9kYXkpIFN0ZWFsIGEgY29kZSBwb2ludCBmcm9t IHRoZSBwYWNrZXQgdHlwZTogaGF2ZSAyIGJpdHMgdGhhdCByZXByZXNlbnQ6PG86cD48L286cD48 L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ MC1ieXRlIGNvbm5lY3Rpb24gaWQ7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+OC1ieXRlIGNvbm5lY3Rpb24gaWQ7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MTYt Ynl0ZSBjb25uZWN0aW9uIGlkIChrZXkgYSk7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+MTYtYnl0ZSBjb25uZWN0aW9uIGlkIChr ZXkgYik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0K PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj7igJxUcmlhbCBFbmNyeXB0aW9u4oCdIDogU3RlYWwgYSBiaXQg ZnJvbSB5b3VyIDEyOCBiaXQgY29ubmVjdGlvbiBJRDxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPllvdXIgYml0IDAgb2YgeW91ciBDb25uZWN0aW9uIElE IHdpbGwgcmVwcmVzZW50IHRoZSBrZXkgdXNlZCBmb3IgZW5jcnlwdGlvbi48YnI+DQpTaW5jZSB5 b3UgaGF2ZSBlbnRyb3B5IGluIHlvdXIgQ29ubmVjdGlvbiBJRCwga2VlcCBnZW5lcmF0aW5nIG5l dyBlbnRyb3B5IGFuZCBlbmNyeXB0aW5nLCB1bnRpbCBiaXQgMCBjb21lcyBvdXQganVzdCB0aGUg d2F5IHlvdSB3YW50IGl0LiZuYnNwOyBPbiBhdmVyYWdlLCB5b3Ugd2lsbCBkbyAwLjc1IGV4dHJh IGVuY3J5cHRpb24gb3BlcmF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IE1hcnRpbiBEdWtlIFttYWlsdG86bWFydGluLmguZHVrZUBn bWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVhcnkgMjQsIDIwMTgg MTI6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBBIGJldHRlciB3YXkgdG8gZG8gY29u biBpZD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZlcnkgd2VsbCwgcmVwbGFjZSAx NiB3aXRoIHdoYXRldmVyIG51bWJlciB5b3UgZ3V5cyBjb21lIHVwIHdpdGguPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAyNCwgMjAxOCBh dCA0OjE5IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9t c29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIGhhdmUgYWxyZWFkeSBjb25jbHVkZWQgdGhhdCBpZiB5b3Ugd2FudCB0byBkbyBz YW5lIGNyeXB0bywgcGx1czxicj4NCnNvbWUgc29ydCBvZiBrZXkgaWRlbnRpZmljYXRpb24sIHRo ZW4geW91IG5lZWQgTU9SRSB0aGFuIDE2IG9jdGV0czxicj4NCih0aG91Z2ggbm90IG11Y2ggbW9y ZSkuJm5ic3A7IFRoYXQgbWFrZXMgdGhpbmdzIG1vcmUgY29tcGxpY2F0ZWQuJm5ic3A7IGVrciBo YXM8YnI+DQphbiBvdXRjb21lIHRoYXQgaGUgd2lsbCB3cml0ZSB1cC48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gV2VkLCBKYW4gMjQs IDIwMTggYXQgNDowOCBQTSwgTWFydGluIER1a2UgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u aC5kdWtlQGdtYWlsLmNvbSI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IFRvZGF5J3MgdmFyaWFibGUtbGVuZ3RoIGNvbm5lY3Rpb24gSUQgZGlzY3Vzc2lv biBtYWRlIG1lIHJlYWxpemUgc29tZTxicj4NCiZndDsgcHJvYmxlbXMgd2l0aCB0aGUgY3VycmVu dCBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBuZXcgYXJjaGl0ZWN0dXJlIGRvZXNuJ3Q8YnI+DQom Z3Q7IGZpeCBzb21lIG9mIHRoZW0gYW5kIGNyZWF0ZXMgd2hvbGUgbmV3IG9uZXMuIElzc3Vlczo8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIFRoZSBjbGllbnQgZGVzaXJlcyB1bmxpbmthYmlsaXR5LCBi dXQgSSBzdXNwZWN0IHRoZSBtYXJrZXQgd2lsbCBwcm92aWRlIG5vPGJyPg0KJmd0OyBpbmNlbnRp dmVzIGZvciBzZXJ2ZXJzIHRvIHdvcmsgdmVyeSBoYXJkIHRvIGJlIHVubGlua2FibGUuIFRoZXJl IHdlcmU8YnI+DQomZ3Q7IGNvbmZsaWN0aW5nICZxdW90O2xheWVyIDkmcXVvdDsgYXJndW1lbnRz IHRoYXQgdmFyaWFibGUgY29ubiBJRCBtYWtlcyB0aGlzIHByb2JsZW08YnI+DQomZ3Q7IHdvcnNl IG9yIGJldHRlci48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtIDE2IEJ5dGVzIGlzIG1vcmUgb3Zlcmhl YWQgdGhhbiA4IGJ5dGVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gVGhlIHNldmVyaXR5IG9mIHRo aXMgcmVtYWlucyB0byBiZSBzZWVuLCBidXQgdmFyaWFibGUgbGVuZ3RoIGNvbm4gaWRzIHdpbGw8 YnI+DQomZ3Q7IGludHJvZHVjZSBtb3JlIGNvbXBsZXhpdHkgaW4gcGFyc2VycyBhbmQgYW55dGhp bmcgdGhhdCB1dGlsaXplcyB0aGUgY29ubiBpZDxicj4NCiZndDsgKGUuZy4gaGFuZHNoYWtlIGtl eSBnZW5lcmF0aW9uKS4gSXQgbWlnaHQgbWFrZSB0aGUgaW52YXJpYW50cyBtb3JlIGNvbXBsZXg8 YnI+DQomZ3Q7IGFzIHdlbGwuIFRoZSB3aG9sZSB0aGluZywgZnJhbmtseSwgbWFrZXMgbXkgaGVh ZCBodXJ0Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEkgaHVtYmx5IHN1Z2dlc3QgdGhlIGZvbGxvd2lu ZyBwcm9wb3NhbCBtaWdodCBhdm9pZCBvciBtaXRpZ2F0ZSBzb21lIG9mPGJyPg0KJmd0OyB0aGVz ZSBwcm9ibGVtczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAxLiBFdmVyeSBjb25uZWN0aW9uIGhhcyBh IGxvbmctbGl2ZWQgQ2xpZW50LWdlbmVyYXRlZCBDb25uZWN0aW9uIElEIChDR0NJRCk8YnI+DQom Z3Q7IGFuZCBTZXJ2ZXItZ2VuZXJhdGVkIENvbm5lY3Rpb24gSUQgKFNHQ0lEKS4gVGhlIENHQ0lE IGlzIDggYnl0ZXMgYW5kIHRoZTxicj4NCiZndDsgU0dDSUQgaXMgMTYgYnl0ZXMuPGJyPg0KJmd0 Ozxicj4NCiZndDsgMi4gVGhlIENHQ0lEIGlzIHVzZWQgdG8gZGVyaXZlIHRoZSBoYW5kc2hha2Ug a2V5LiAodW5jaGFuZ2VkIGZyb20gc3RhdHVzPGJyPg0KJmd0OyBxdW8pPGJyPg0KJmd0Ozxicj4N CiZndDsgMy4gVGhlIGluaXRpYWwgcGFja2V0IHVzZXMgdGhlIENHQ0lELiZuYnNwOyBBbGwgb3Ro ZXIgaGFuZHNoYWtlIHBhY2tldHMgdXNlIHRoZTxicj4NCiZndDsgU0dDSUQuIFRoaXMgaXMgdW5j aGFuZ2VkIGZyb20gdGhlIHN0YXR1cyBxdW8uPGJyPg0KJmd0Ozxicj4NCiZndDsgNC4gQWxsIDEt UlRUIHBhY2tldHMgYnkgc2VudCBieSB0aGUgY2xpZW50IHVzZSB0aGUgU0dDSUQuIEFsbCAxLVJU VCBwYWNrZXRzPGJyPg0KJmd0OyBzZW50IGJ5IHRoZSBzZXJ2ZXIgdXNlIHRoZSBDR0NJRC4gVGhp cyBoYXMgdHdvIGltcG9ydGFudCBwcm9wZXJ0aWVzOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhKSBUaGUgc2VydmVyIGdldHMgdGhlIDE2IEJ5dGVz IG9mIGVudHJvcHkgdGhlIGxvYWQgYmFsYW5jZXI8YnI+DQomZ3Q7IG5lZWRzPGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGIpIFRoZSBzZXJ2ZXItJmd0 O2NsaWVudCBkaXJlY3Rpb24sIHdoaWNoIGluIHRoZSB1c3VhbCBjYXNlIGhhcyBtb3N0PGJyPg0K Jmd0OyBvZiB0aGUgZGF0YSwgaGFzIGEgbG93ZXItb3ZlcmhlYWQgQ0lELjxicj4NCiZndDs8YnI+ DQomZ3Q7IDUuIFRoZSBhbGdvcml0aG0gdGhhdCBnZW5lcmF0ZXMgU0dDSUQgTVVTVCBoYXZlIGRp ZmZlcmVudCBvdXRwdXQgZ2l2ZW4gYTxicj4NCiZndDsgZGlmZmVyZW50IENHQ0lELiBbV2UgbWln aHQgc3RyZW5ndGhlbiB0aGlzIGxhbmd1YWdlIGZ1cnRoZXI6IHlvdSB3b3VsZG4ndDxicj4NCiZn dDsgd2FudCB0byBzaW1wbHkgYWRkIHRoZSBORVdfQ09OTl9JRCBzZXF1ZW5jZSBudW1iZXIgdG8g dGhlIGV4aXN0aW5nIFNHQ0lELDxicj4NCiZndDsgZm9yIGluc3RhbmNlXS48YnI+DQomZ3Q7PGJy Pg0KJmd0OyA2LiBJbiBhZHZhbmNlIG9mIG1pZ3JhdGlvbiwgdGhlIGNsaWVudCBzZW5kcyBhIE5F V19DT05OX0lEIGZyYW1lIHRvIHByb3ZpZGU8YnI+DQomZ3Q7IGEgbmV3IENHQ0lEIChwb3NzaWJs eSBvbWl0dGluZyB0aGUgc3RhdGVsZXNzIHJlc2V0IHRva2VuKS4gVGhlIHNlcnZlciBNVVNUPGJy Pg0KJmd0OyByZXNwb25kIHdpdGggYSBORVdfQ09OTl9JRCB0aGF0IHByb3ZpZGVzIGEgbmV3IFNH Q0lEIGRlcml2ZWQgZnJvbSB0aGUgbmV3PGJyPg0KJmd0OyBDR0NJRC4gQWxsIHBhY2tldHMgb24g dGhlIG5ldyBwYXRoIHVzZSB0aGVzZSBDSURzLjxicj4NCiZndDs8YnI+DQomZ3Q7IElmIHBlb3Bs ZSBsaWtlIHRoaXMsIEkgY2FuIGdlbmVyYXRlIGEgUFIuIEkgYW0gdmVyeSBvcGVuIHRvIHZhcmlv dXMgdHdlYWtzPGJyPg0KJmd0OyB0byB0aGUgZ2VuZXJhbCBhcHByb2FjaCBhcyB3ZWxsLiBJIHdh bnRlZCB0byBnZXQgdGhpcyBvdXQgdGhlcmUgYmVmb3JlIHRoZTxicj4NCiZndDsgdmFyaWFibGUt bGVuZ3RoIENJRCB0ZWFtIGdldHMgZGVlcCBpbiB0aGUgd2VlZHMuPGJyPg0KJmd0Ozxicj4NCiZn dDsgTWFydGluIER1a2U8YnI+DQomZ3Q7PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_6d7331bfb9e041e4a712f3edf99a3001usma1exdag1mb5msgcorpak_-- From nobody Tue Jan 23 21:54:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D2612D959 for ; Tue, 23 Jan 2018 21:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=evequefou.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 0093R3vKyu08 for ; Tue, 23 Jan 2018 21:54:02 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6FE1275C5 for ; Tue, 23 Jan 2018 21:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JCr2bRayhkAHSAFEAmO7cs6CFWoZUzHlr7V41E9Ym3w=; b=lsbK8LO3c6nzdZwOZALyob6lO5PPj+YZNcyKuQUjsAg85ud+k2Aw7rdzZzCCGwGpEOGrS65jWgPSY+9BDv+omf5CzOvRpU0k9fD+CyrmV0RMvT20DDbM6GCfLeBYJ1s9d84+78E2T49Z1+ZetlyGhUqN9BZtUdDWtT6ZkYsntaM= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB3376.namprd08.prod.outlook.com (10.164.203.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 05:53:56 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0444.014; Wed, 24 Jan 2018 05:53:56 +0000 From: Mike Bishop To: IETF QUIC WG CC: Charles 'Buck' Krasic Subject: Updated QCRAM Draft Thread-Topic: Updated QCRAM Draft Thread-Index: AdOU155bAsc1/g3LTZii92sX1uSC2g== Date: Wed, 24 Jan 2018 05:53:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.22] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB3376; 7:ZUpkrZ4QSPiG6MM7H5LP6R8bEH6BctrX64dK4IpZ6xjm/CHmSGhEiGVaAHBAO8EdFMh97eRAtC886e160F3C87/kCHxw6MwB70sVd1lu3BUt9TkEwn9nhrepAwOutPR66jTbDETPygUDE+O6QUUA2cgCmCxraYc7/qLVHAR95EaTgZV7oIcuaMUKMcFxFQIT6AWetLlff/k3wTbRQT9Bd6+guZjaeJeNc2vQKInslLt69NVMOsmUSjlHt77z7ixa x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 016a4b0a-3e46-4d28-d83b-08d562eedb2b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB3376; x-ms-traffictypediagnostic: MWHPR08MB3376: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231023)(2400081)(944501161)(93006095)(93001095)(3002001)(6041288)(20161123560045)(20161123564045)(2016111802025)(20161123558120)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB3376; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB3376; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39830400003)(376002)(346002)(396003)(199004)(189003)(10710500007)(102836004)(6506007)(25786009)(74482002)(4326008)(2900100001)(606006)(6346003)(7696005)(77096007)(790700001)(3846002)(2906002)(966005)(2420400007)(6116002)(14454004)(26005)(7110500001)(97736004)(66066001)(478600001)(558084003)(7736002)(6436002)(9686003)(6306002)(54896002)(236005)(99286004)(105586002)(15650500001)(3280700002)(3660700001)(316002)(106356001)(74316002)(3480700004)(8936002)(81166006)(81156014)(8676002)(6916009)(7116003)(5660300001)(68736007)(55016002)(53936002)(86362001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3376; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:3; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-message-info: IaoE1S4S1ga4Au+rk8aVdxUfJbKCDsYHSyKBKFR26pj1kMbJOz3lfmhNiF7IVPTAntHSyfMyl+ssP63s0ZtDOA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432AA6E7D43B2318F23B671DAE20MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 016a4b0a-3e46-4d28-d83b-08d562eedb2b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 05:53:55.8012 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3376 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 05:54:04 -0000 --_000_MWHPR08MB2432AA6E7D43B2318F23B671DAE20MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft= -krasic-quic-qcram-04 -- please read before tomorrow's meeting so we can ha= ve a useful discussion. Thanks! --_000_MWHPR08MB2432AA6E7D43B2318F23B671DAE20MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read b= efore tomorrow’s meeting so we can have a useful discussion.  Th= anks!

    --_000_MWHPR08MB2432AA6E7D43B2318F23B671DAE20MWHPR08MB2432namp_-- From nobody Wed Jan 24 00:00:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66F12D892 for ; Wed, 24 Jan 2018 00:00:50 -0800 (PST) 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=cbcPnM93; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=fTTyLsJg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMHT2QoblbR1 for ; Wed, 24 Jan 2018 00:00:48 -0800 (PST) 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 159D112D847 for ; Wed, 24 Jan 2018 00:00:48 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0O80F1K003745; Wed, 24 Jan 2018 00:00:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=RbgoLvnMqDhY6iawl3h/aH3FIj09L4QPJK0Hgm0bvEQ=; b=cbcPnM93kCIg6O/96inG6XqgYVMxk0gPGOd195ix0z6HvPDV7Yra6mRGuKFtzS7AW0zL awv1wB2YGoHJICWtMy/MwEyxkFVUQplOJ6bSJcyuOsRtF7U8HjZG9U2fecFhPfqiZuPB 5jq/9zJRf9uzWsLMdR/O+j9e4MpuPPhWEJU= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fpjxggdvd-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jan 2018 00:00:43 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.21) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 24 Jan 2018 03:00:41 -0500 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=RbgoLvnMqDhY6iawl3h/aH3FIj09L4QPJK0Hgm0bvEQ=; b=fTTyLsJgPmJexiGCl/jbgMnYVV1/0o15Uhlpsl9RJOGm5VeRvCfaBfjFWJz0B9TcR0ny1qulXxZIoC0OK0wVCgwbLBWiFQxoXzjtO0S8q3sONwgL5+/+D1cOgSfBb6WWucq8wBLOGxkSIcaNPdp5jI1Ti1eA8J9Qn1EWzabug2k= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1454.namprd15.prod.outlook.com (10.173.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 08:00:38 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0428.024; Wed, 24 Jan 2018 08:00:38 +0000 From: Subodh Iyengar To: "Lubashev, Igor" , Martin Duke , Martin Thomson CC: IETF QUIC WG Subject: Re: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNF1Km/QxvV28ECJ6ipSoEe6+qOCfDqAgAAAcoCAAAPIgIAAJpN9 Date: Wed, 24 Jan 2018 08:00:38 +0000 Message-ID: References: , <6d7331bfb9e041e4a712f3edf99a3001@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <6d7331bfb9e041e4a712f3edf99a3001@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::308c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 7:pAmxkGGxoyA2ym3kOUstzb7gz+L1/aKf9IehBMZijMaznah0uNlYnQHAAMOz+NB8nNF8KXYyN5aO3588vWQNBi6eSredVeJSzUcj2TumX9jPeKb6fj83cjlah+85SNTR5AbPipuB2/4qujyNfBqNEQNXN8vmY8TipRpe1nByULyJtF8A61pM9+1W9GfhHJxgFvCs4EJ/vVNScPNLUD69wdCS5iLsAUF6u4WIYw6GPCGIuiLJNOufrz3hpFcQwwPw; 20:iz/UKpry/dk+zWUMuknuXfJ5vGm9PL5gyhKHF0+dxtI52/kvhr73KUo9F24imw0flx3Rs5VBf5bt8pUUOVHjsizsC1doQTECaJLnARF5K6ysGjCFDFoPUEZ4QvNb03Uk4rRu6bnJn//GtcFlbRblBL/lEYQ1411VQCmPsj7zZpE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4d14cd73-3060-4a93-0a39-08d563008e5a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1454; x-ms-traffictypediagnostic: MWHPR15MB1454: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231023)(11241501184)(2400081)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1454; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(39860400002)(346002)(376002)(189003)(199004)(57704003)(86362001)(33656002)(6606003)(2950100002)(6506007)(102836004)(5660300001)(77096007)(561944003)(53546011)(229853002)(106356001)(68736007)(105586002)(8936002)(81156014)(81166006)(8676002)(76176011)(59450400001)(478600001)(7696005)(6436002)(19627405001)(97736004)(14454004)(55016002)(2906002)(93886005)(6116002)(39060400002)(2900100001)(6246003)(25786009)(4326008)(99286004)(3280700002)(54896002)(53936002)(3660700001)(74316002)(7736002)(236005)(316002)(9686003)(110136005)(43043002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: UyfpTOqzo1K3/Lt3JOwnqENq95YwqqV3oxZYhsTIVCWebNFxYQ8PXBJ5qtJm7tKh3ieZgNelxOA8204D/yAZYw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14559FAA5FAEF0577E1FC747B6E20MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4d14cd73-3060-4a93-0a39-08d563008e5a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 08:00:38.0021 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1454 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 08:00:50 -0000 --_000_MWHPR15MB14559FAA5FAEF0577E1FC747B6E20MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > (Victor voiced this today) Steal a code point from the packet type: have = 2 bits that represent Why do we need to represent the size of the connection id as bits in the pa= cket? We usually represent the lengths as bits in the packet for 2 reasons: 1. to be able to change them per packet 2. If they need to be interpreted by unrelated parties. I raised this question in the meeting today whether or not connid size need= s to change with every packet and the answer seemed no. Also in the current= design the interpretation of connid is only relevant to the server / relat= ed parties, in which case the server could represent it's connid in its own= self describing format which doesn't need any new bits. L3 load balancers = and L7 load balancers would share the knowledge of the format of the connec= tion id to determine how long it is. So it would seem like we don't need an= y extra bits. Are any of these assumptions I'm making incorrect? Subodh ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Tuesday, January 23, 2018 9:34:47 PM To: Martin Duke; Martin Thomson Cc: IETF QUIC WG Subject: RE: A better way to do conn id? The two alternatives to allow for key rotation to =93avoid=94 going over 16= octets are: 1. (Victor voiced this today) Steal a code point from the packet type: h= ave 2 bits that represent: 0-byte connection id; 8-byte connection id; 16-byte connection id (key a); 16-byte connection id (key b) 1. =93Trial Encryption=94 : Steal a bit from your 128 bit connection ID Your bit 0 of your Connection ID will represent the key used for encryption= . Since you have entropy in your Connection ID, keep generating new entropy a= nd encrypting, until bit 0 comes out just the way you want it. On average,= you will do 0.75 extra encryption operations. * Igor From: Martin Duke [mailto:martin.h.duke@gmail.com] Sent: Wednesday, January 24, 2018 12:21 AM To: Martin Thomson Cc: IETF QUIC WG Subject: Re: A better way to do conn id? Very well, replace 16 with whatever number you guys come up with. On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson > wrote: We have already concluded that if you want to do sane crypto, plus some sort of key identification, then you need MORE than 16 octets (though not much more). That makes things more complicated. ekr has an outcome that he will write up. On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke > wrote: > Today's variable-length connection ID discussion made me realize some > problems with the current architecture, while the new architecture doesn'= t > fix some of them and creates whole new ones. Issues: > > - The client desires unlinkability, but I suspect the market will provide= no > incentives for servers to work very hard to be unlinkable. There were > conflicting "layer 9" arguments that variable conn ID makes this problem > worse or better. > > - 16 Bytes is more overhead than 8 bytes. > > - The severity of this remains to be seen, but variable length conn ids w= ill > introduce more complexity in parsers and anything that utilizes the conn = id > (e.g. handshake key generation). It might make the invariants more comple= x > as well. The whole thing, frankly, makes my head hurt. > > I humbly suggest the following proposal might avoid or mitigate some of > these problems: > > 1. Every connection has a long-lived Client-generated Connection ID (CGCI= D) > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the > SGCID is 16 bytes. > > 2. The CGCID is used to derive the handshake key. (unchanged from status > quo) > > 3. The initial packet uses the CGCID. All other handshake packets use th= e > SGCID. This is unchanged from the status quo. > > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT packe= ts > sent by the server use the CGCID. This has two important properties: > a) The server gets the 16 Bytes of entropy the load balancer > needs > b) The server->client direction, which in the usual case has m= ost > of the data, has a lower-overhead CID. > > 5. The algorithm that generates SGCID MUST have different output given a > different CGCID. [We might strengthen this language further: you wouldn't > want to simply add the NEW_CONN_ID sequence number to the existing SGCID, > for instance]. > > 6. In advance of migration, the client sends a NEW_CONN_ID frame to provi= de > a new CGCID (possibly omitting the stateless reset token). The server MUS= T > respond with a NEW_CONN_ID that provides a new SGCID derived from the new > CGCID. All packets on the new path use these CIDs. > > If people like this, I can generate a PR. I am very open to various tweak= s > to the general approach as well. I wanted to get this out there before th= e > variable-length CID team gets deep in the weeds. > > Martin Duke > > --_000_MWHPR15MB14559FAA5FAEF0577E1FC747B6E20MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    > (Vi= ctor voiced this today) Steal a code point from the packet type: have 2 bit= s that represent

    Why do we need to represent the size of the connection id as bits in the pa= cket? We usually represent the lengths as bits in th= e packet for 2 reasons:

    1. to be able to change them= per packet
    2. If they need to be interpreted by unrelate= d parties.


    I raised this question in the= meeting today whether or not connid size needs to change with every packet and the answer seemed no. Also in the current design the interpretation of conn= id is only relevant to the server / related parties, in which case the serv= er could represent it's connid in its own self describing format which doesn't need any new bits. L3 load ba= lancers and L7 load balancers would share the knowledge of the format of th= e connection id to determine how long it is. So it would seem like we don't= need any extra bits. Are any of these assumptions I'm making incorrect?


    Subodh

    From: QUIC <quic-bounces= @ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
    Sent: Tuesday, January 23, 2018 9:34:47 PM
    To: Martin Duke; Martin Thomson
    Cc: IETF QUIC WG
    Subject: RE: A better way to do conn id?
     

    The two alternatives to allow for key rotation to = =93avoid=94 going over 16 octets are:

     

    1. (Victor voiced t= his today) Steal a code point from the packet type: have 2 bits that repres= ent:

    0-byte connection id;

    8-byte connection id;

    16-byte connection id (= key a);

    16-byte connection id (= key b)

     

    1. =93Trial Encrypt= ion=94 : Steal a bit from your 128 bit connection ID

    Your bit 0 of your Connection ID will repre= sent the key used for encryption.
    Since you have entropy in your Connection ID, keep generating new entropy a= nd encrypting, until bit 0 comes out just the way you want it.  On ave= rage, you will do 0.75 extra encryption operations.

     

    • Igor

     

    From: Martin Duke [mailto:martin.h.duke@gma= il.com]
    Sent: Wednesday, January 24, 2018 12:21 AM
    To: Martin Thomson <martin.thomson@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: A better way to do conn id?

     

    Very well, replace 16 with whatever number you guy= s come up with.

     

    On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:

    We have already concluded that if you want to do s= ane crypto, plus
    some sort of key identification, then you need MORE than 16 octets
    (though not much more).  That makes things more complicated.  ekr= has
    an outcome that he will write up.


    On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
    > Today's variable-length connection ID discussion made me realize some<= br> > problems with the current architecture, while the new architecture doe= sn't
    > fix some of them and creates whole new ones. Issues:
    >
    > - The client desires unlinkability, but I suspect the market will prov= ide no
    > incentives for servers to work very hard to be unlinkable. There were<= br> > conflicting "layer 9" arguments that variable conn ID makes = this problem
    > worse or better.
    >
    > - 16 Bytes is more overhead than 8 bytes.
    >
    > - The severity of this remains to be seen, but variable length conn id= s will
    > introduce more complexity in parsers and anything that utilizes the co= nn id
    > (e.g. handshake key generation). It might make the invariants more com= plex
    > as well. The whole thing, frankly, makes my head hurt.
    >
    > I humbly suggest the following proposal might avoid or mitigate some o= f
    > these problems:
    >
    > 1. Every connection has a long-lived Client-generated Connection ID (C= GCID)
    > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and t= he
    > SGCID is 16 bytes.
    >
    > 2. The CGCID is used to derive the handshake key. (unchanged from stat= us
    > quo)
    >
    > 3. The initial packet uses the CGCID.  All other handshake packet= s use the
    > SGCID. This is unchanged from the status quo.
    >
    > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT pa= ckets
    > sent by the server use the CGCID. This has two important properties: >            a) The server gets the 16 Byt= es of entropy the load balancer
    > needs
    >            b) The server->client dire= ction, which in the usual case has most
    > of the data, has a lower-overhead CID.
    >
    > 5. The algorithm that generates SGCID MUST have different output given= a
    > different CGCID. [We might strengthen this language further: you would= n't
    > want to simply add the NEW_CONN_ID sequence number to the existing SGC= ID,
    > for instance].
    >
    > 6. In advance of migration, the client sends a NEW_CONN_ID frame to pr= ovide
    > a new CGCID (possibly omitting the stateless reset token). The server = MUST
    > respond with a NEW_CONN_ID that provides a new SGCID derived from the = new
    > CGCID. All packets on the new path use these CIDs.
    >
    > If people like this, I can generate a PR. I am very open to various tw= eaks
    > to the general approach as well. I wanted to get this out there before= the
    > variable-length CID team gets deep in the weeds.
    >
    > Martin Duke
    >
    >

     

    --_000_MWHPR15MB14559FAA5FAEF0577E1FC747B6E20MWHPR15MB1455namp_-- From nobody Wed Jan 24 00:01:34 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B07A12D965 for ; Wed, 24 Jan 2018 00:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 HfjQh84Oncgc for ; Wed, 24 Jan 2018 00:01:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A885D12D964 for ; Wed, 24 Jan 2018 00:01:30 -0800 (PST) X-AuditID: c1b4fb3a-716549c0000037f2-87-5a683d583e04 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0B.47.14322.85D386A5; Wed, 24 Jan 2018 09:01:28 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 24 Jan 2018 09:01:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XtcfcXe1ktymIxMBFtyMbLSie/FY27DaQi8tp96IYx4=; b=lPXwWqn/DmRFdO7RG+poq2uxn5W4uAjudKRNhPg/ec+8YhrDx1fRUnF7KwFqb25IqWm/HHSfZ+G3sOAiXAx63lE7oWDXi9ZMiYZk6Tg/drBFNz5xxuWrqwsoJ48KIOpnBWZSHLhwdkavpkVa4aPeHvpiP1IBx5pm3p8f/sSN6V0= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3724.eurprd07.prod.outlook.com (52.133.6.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 08:01:25 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c%13]) with mapi id 15.20.0444.008; Wed, 24 Jan 2018 08:01:25 +0000 From: Ingemar Johansson S To: QUIC WG Subject: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5Q== Date: Wed, 24 Jan 2018 08:01:25 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3724; 7:ZebNAiOrqvQYFXJn5vLdTo211i0k8mao2x4ajNYLplUBBNEmTu1T9lObTgH0jtpRWfuA1DLKp4mrRjP3JUGuqRIp8i2uC9iiGFphDY4Xpljl/vbojI/TNWmWX1+RSElCRHYbDlrbmdLl8fGJVYuaDkkhdf9TTfNRtz0m/pIDCZIVKhgRlKiePZJMuTykWd0oxbSaAHLQT7VOxuJvO/lnKCtWqS3wMQvVwjw2Qy4BC4r9xb3jvPhqmG+aFF+1nb30 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 36622196-1686-412f-8f24-08d56300aacd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3724; x-ms-traffictypediagnostic: HE1PR0702MB3724: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231046)(2400081)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0702MB3724; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3724; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39380400002)(366004)(39860400002)(346002)(199004)(189003)(66066001)(7736002)(59450400001)(53936002)(2900100001)(105586002)(19609705001)(33656002)(561944003)(99286004)(106356001)(68736007)(2906002)(3660700001)(81166006)(6436002)(3280700002)(3480700004)(8936002)(6916009)(55016002)(7116003)(54896002)(6306002)(236005)(81156014)(97736004)(478600001)(5250100002)(8676002)(14454004)(316002)(9326002)(966005)(86362001)(25786009)(102836004)(74316002)(606006)(6506007)(9686003)(5660300001)(26005)(6346003)(790700001)(3846002)(7696005)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3724; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-microsoft-antispam-message-info: 2RL8ExgmMbeVx/0pmd9w2U73qJCwgkhjeG7wbbZbgt6Uv0+af0mZ4weyQZLgA0NoEmy1UDteV54QDhOIGPCMJg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB3625F6E2C399F7E6F187C883C2E20HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 36622196-1686-412f-8f24-08d56300aacd X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 08:01:25.7978 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3724 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLKsWRmVeSWpSXmKPExsUyM2K7qG6EbUaUwaZnJhY9C7gdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXR8+8fe8GVuoqLL7+wNTAuqO5i5OSQEDCRuPNiLlMXIxeHkMBh Rok7L6dAOScYJVqPdrKBOCwCn5gkHr/dzQyRmc4k8fz2F1aQfiGB54wSs064g9hsAjYSKw99 ZwSxRQSkJTat+cgGYgsLiEisWruDFSIuKfHuSysLhK0ncWHmOXYQm0VAVWLOIZAFnBy8AgkS yx89A5vDKCArcf/7PbB6ZgFxiVtP5jNB3C0gsWTPeWYIW1Ti5eN/rBC2gsSfS4/YIGxZiUvz uxlBjpYQ2MYk0T3pIwtEQk9i68S3QAkOINtXYuufWIiaU4wSM5esZYeo0ZF4tecHO0RNvkTH VKj52RL956exQtTPYZZ4dK4ZKiEjcejnDRaIxDNWiYef7zBDQihVYvnaVqhvkiU+3eyFaqiW WD6ji30Co/YsJM9B2PkSZyasYp0FDgxBiZMzn7DMArqDWUBTYv0ufYgSRYkp3Q/ZIWwNidY5 c9mRxRcwsq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECEw0B7f8ttrBePC54yFGAQ5GJR5e CaWMKCHWxLLiytxDjBIczEoivHms6VFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeZ3SLKKEBNIT S1KzU1MLUotgskwcnFINjN4lu03bZzbtsONh1LxXOKXok72z9Pkp3xU6J32I95uZzHp7xROx U46/ti/zN2nQyv1jbxJudK512xeWvHvPbx/1qLPT8proY8fdOjuqeX3ygm8MtfP5DpTOe7Am WHkGY73Qsbs7pi6SPdq4WGei5/ol7nZ/lX0VFlgeyOExq9AJNIy/9vxbvRJLcUaioRZzUXEi AKjI2pgwAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 08:01:33 -0000 --_000_HE1PR0702MB3625F6E2C399F7E6F187C883C2E20HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQSBmZXcgaW1wcmVzc2lvbnMgb24gdGhlIEVDTiBpbiBRVUlDIGRpc2N1c3Npb25zLiBU aGUgYXVkaW8gd2FzIHNvLXNvLCBmcmVxdWVudCBpbnRlcnJ1cHRpb25zIGFuZCBMQVJHRSBkaWZm ZXJlbmNlcyBpbiBhdWRpbyBsZXZlbCArIGJhZGx5IGltcGxlbWVudGVkIGVhcnMg8J+Yiiwgc28g c29tZXRpbWVzIEkgbWlzc2VkIHRoZSBkZXRhaWxzIGFuZCBwb3NzaWJseSBraWNrIGluIG9wZW4g ZG9vcnMuDQoNCiogIEZlZWRiYWNrIGZvcm1hdC4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIHByb3Bv c2VkIHByb3Bvc2FsIGJhc2VkIG9uIEVDVCgwKSwgRUNUKDEpIGFuZCBDRSBjb3VudGVycyBkb2Vz IG5vdCBwbGF5IHdlbGwgd2l0aCBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gSSBiZWxpZXZlLCBidXQg SSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHRoZSBwcm9ibGVtLiBJIHVuZGVy c3RhbmQgdGhhdCB0aGVyZSBhcmUgdHdvIGNvbmNlcm5zIChwZXJoYXBzIG1vcmU/KToNCiAgMS4g Q291bnRlcnMgYXJlIHJlc2V0LCB0aGlzIG1lYW5zIHRoYXQgdGhlcmUgd2lsbCBiZSBhIHBvdGVu dGlhbGx5IHZlcnkgbGFyZ2UgKG5lZ2F0aXZlPykgZGlmZmVyZW5jZSBpbiBDRSBtYXJrZWQgcGFj a2V0cy4gSSBiZWxpZXZlIHRoYXQgdGhpcyBjYW4gYmUgZGV0ZWN0ZWQgYXMgZmFsc2UgY29uZ2Vz dGlvbiBzaWduYWwgYW5kIGlnbm9yZWQgYnkgdGhlIGNvbmdlc3Rpb24gc2lnbmFsLg0KICAyLiBE aWZmaWN1bHRpZXMgdG8gZGV0ZWN0IEVDTiBibGVhY2hpbmcuIEl0IGlzIHRyaWNreSB0byB1bmRl cnN0YW5kIGlmIHBhY2tldHMgYWxvbmcgdGhlIG5ldyBwYXRoIGFyZSBibGVhY2hlZCBiYXNlZCBv biB0aGUgRUNUIGNvdW50ZXJzLiBUaGlzIGNhbiBiZSBhIG1vcmUgY29tcGxpY2F0ZWQgY2FzZS4N CkluIGFueSBjYXNlIGl0IHdhcyBzdWdnZXN0ZWQgdG8gaW5kaWNhdGUgdGhlIEVDTiBiaXRzIGZv ciB0aGUgcGFja2V0cyBpbiB0aGUgQUNLIGZyYW1lLiBTdWNoIGEgZm9ybWF0IHdhcyBhY3R1YWxs eSBvdXRsaW5lZCBpbiBlYXJsaWVyIHByb3Bvc2FsIChzZWUgcGFnZSA2LCBGaWd1cmUgMyBpbiBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxICku IEl0IGlzIE9rIHdpdGggbWUgdG8gY2hhbmdlIHRvIGEgZm9ybWF0IHNpbWlsYXIgdG8gdGhpcyBp ZiB0aGUgZ3JvdXAgcHJlZmVycyB0aGF0Lg0KDQoqIENvbmdlc3Rpb24gY29udHJvbCBmb3IgRUNU KDEpLCBMNFMgOiBNeSBmZWVsaW5nIGlzIHRoYXQgaXQgaXMgZm9yIG5vdyBPSyB0byBsZWF2ZSB0 aGlzIGFzIGZ1dHVyZSB3b3JrLiBUaGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBhcmUgYWJz b2x1dGVseSBubyBpZGVhcyBvbiBob3cgdG8gaW1wbGVtZW50IHRoaXMsIGZvciBzaG9ydCBSVFQg ZW52aXJvbm1lbnRzIERDVENQIHN0eWxlIGNvbmdlc3Rpb24gY29udHJvbCBpcyBxdWl0ZSBPSy4g RnVydGhlcm1vcmUgSSBhbmQgcmVjZW50bHkgd29ya2VkIG9uIGEgTDRTIGNvbmdlc3Rpb24gY29u dHJvbCB0aGF0IGlzIGJhc2VkIG9uIEJCUiwgdGhlIHJlc3VsdHMgbG9vayBxdWl0ZSBwcm9taXNp bmcgYW5kIHRoZSBjaGFuZ2VzIHRvIHRoZSBCQlIgYWxnb3JpdGhtIGFyZSBxdWl0ZSBtaW5pbWFs LiBJIGFtIHdpbGxpbmcgdG8gcHJlc2VudCB0aGlzIGF0IElDQ1JHIGluIExvbmRvbiBpZiB0aGVy ZSBpcyBhbnkgaW50ZXJlc3QgaW4gdGhpcy4NCiogRUNOIGluIFFVSUMgdjEgb3IgbGF0ZXIgOiBJ IHdvdWxkIHZlcnkgbXVjaCBwcmVmZXIgdGhhdCBFQ04gc3VwcG9ydCBnb2VzIGludG8gdjEuIE9u IHRoZSB0ZWNobmljYWwgc2lkZSBpdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBleHBlcmltZW50IHdp dGggRUNOLCBwb3RlbnRpYWxseSBvbiBhIGxhcmdlciBzY2FsZS4gT24gdGhlIHBvbGl0aWNhbCBz aWRlIGl0IGhlbHBzIHRvIG1ha2UgdGhlIOKAnGNoaWNrZW4gYW5kIGVnZ+KAnSBwcm9ibGVtIGJl Y29tZSBoaXN0b3J5Lg0KDQovSW5nZW1hcg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQpNYXN0ZXIgUmVzZWFyY2hlcg0KDQpFcmlj c3NvbiBSZXNlYXJjaA0KTmV0d29yayBQcm90b2NvbHMgJiBFMkUgUGVyZm9ybWFuY2UNCkxhYnJh dG9yaWVncsOkbmQgMTENCjk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NClBob25lICs0Ni0xMDcxIDQz MDQyDQpTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0KaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0Kd3d3LmVyaWNz c29uLmNvbQ0KDQpUaGUgd29ybGQgaXMgZnVsbCBvZiBtYWdpY2FsIHRoaW5ncyBwYXRpZW50bHkN CiAgICB3YWl0aW5nIGZvciBvdXIgd2l0cyB0byBncm93IHNoYXJwZXINCiAgICAgICAgICAgICAg IEJlcnRyYW5kIFJ1c3NlbGwNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K --_000_HE1PR0702MB3625F6E2C399F7E6F187C883C2E20HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8q IEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEg TWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQ YXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsN CgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNt Ow0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODYyMzk5Nzk4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMTI0Mjg3NTA0IDY3Njk4NzA1IDY3Njk4NzEzIDY3 Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QSBmZXcgaW1wcmVzc2lvbnMgb24gdGhlIEVDTiBpbiBRVUlDIGRpc2N1 c3Npb25zLiBUaGUgYXVkaW8gd2FzIHNvLXNvLCBmcmVxdWVudCBpbnRlcnJ1cHRpb25zIGFuZCBM QVJHRSBkaWZmZXJlbmNlcyBpbiBhdWRpbyBsZXZlbCAmIzQzOyBiYWRseSBpbXBsZW1lbnRlZCBl YXJzDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDss c2Fucy1zZXJpZiI+8J+Yijwvc3Bhbj4sIHNvIHNvbWV0aW1lcyBJIG1pc3NlZCB0aGUgZGV0YWls cyBhbmQgcG9zc2libHkga2ljayBpbiBvcGVuIGRvb3JzLg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiogJm5ic3A7RmVlZGJhY2sgZm9ybWF0LiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcHJvcG9z ZWQgcHJvcG9zYWwgYmFzZWQgb24gRUNUKDApLCBFQ1QoMSkgYW5kIENFIGNvdW50ZXJzIGRvZXMg bm90IHBsYXkgd2VsbCB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBJIGJlbGlldmUsIGJ1dCBJ IGFtIG5vdCAxMDAlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0uIEkgdW5kZXJz dGFuZCB0aGF0IHRoZXJlIGFyZQ0KIHR3byBjb25jZXJucyAocGVyaGFwcyBtb3JlPyk6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMS4gQ291bnRlcnMgYXJlIHJl c2V0LCB0aGlzIG1lYW5zIHRoYXQgdGhlcmUgd2lsbCBiZSBhIHBvdGVudGlhbGx5IHZlcnkgbGFy Z2UgKG5lZ2F0aXZlPykgZGlmZmVyZW5jZSBpbiBDRSBtYXJrZWQgcGFja2V0cy4gSSBiZWxpZXZl IHRoYXQgdGhpcyBjYW4gYmUgZGV0ZWN0ZWQgYXMgZmFsc2UgY29uZ2VzdGlvbiBzaWduYWwgYW5k IGlnbm9yZWQgYnkgdGhlIGNvbmdlc3Rpb24gc2lnbmFsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDIuIERpZmZpY3VsdGllcyB0byBkZXRlY3QgRUNOIGJsZWFj aGluZy4gSXQgaXMgdHJpY2t5IHRvIHVuZGVyc3RhbmQgaWYgcGFja2V0cyBhbG9uZyB0aGUgbmV3 IHBhdGggYXJlIGJsZWFjaGVkIGJhc2VkIG9uIHRoZSBFQ1QgY291bnRlcnMuIFRoaXMgY2FuIGJl IGEgbW9yZSBjb21wbGljYXRlZCBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SW4gYW55IGNhc2UgaXQgd2FzIHN1Z2dlc3RlZCB0byBpbmRpY2F0ZSB0aGUgRUNOIGJp dHMgZm9yIHRoZSBwYWNrZXRzIGluIHRoZSBBQ0sgZnJhbWUuIFN1Y2ggYSBmb3JtYXQgd2FzIGFj dHVhbGx5IG91dGxpbmVkIGluIGVhcmxpZXIgcHJvcG9zYWwgKHNlZSBwYWdlIDYsIEZpZ3VyZSAz IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29u LXF1aWMtZWNuLTAxIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29u LXF1aWMtZWNuLTAxPC9hPiApLiBJdCBpcyBPayB3aXRoIG1lIHRvIGNoYW5nZSB0byBhIGZvcm1h dCBzaW1pbGFyIHRvIHRoaXMgaWYgdGhlIGdyb3VwIHByZWZlcnMgdGhhdC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+KiBDb25nZXN0aW9uIGNvbnRyb2wgZm9yIEVDVCgxKSwgTDRTIDogTXkgZmVl bGluZyBpcyB0aGF0IGl0IGlzIGZvciBub3cgT0sgdG8gbGVhdmUgdGhpcyBhcyBmdXR1cmUgd29y ay4gVGhhdCBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlcmUgYXJlIGFic29sdXRlbHkgbm8gaWRlYXMg b24gaG93IHRvIGltcGxlbWVudCB0aGlzLCBmb3Igc2hvcnQgUlRUIGVudmlyb25tZW50cyBEQ1RD UCBzdHlsZSBjb25nZXN0aW9uIGNvbnRyb2wNCiBpcyBxdWl0ZSBPSy4gRnVydGhlcm1vcmUgSSBh bmQgcmVjZW50bHkgd29ya2VkIG9uIGEgTDRTIGNvbmdlc3Rpb24gY29udHJvbCB0aGF0IGlzIGJh c2VkIG9uIEJCUiwgdGhlIHJlc3VsdHMgbG9vayBxdWl0ZSBwcm9taXNpbmcgYW5kIHRoZSBjaGFu Z2VzIHRvIHRoZSBCQlIgYWxnb3JpdGhtIGFyZSBxdWl0ZSBtaW5pbWFsLiBJIGFtIHdpbGxpbmcg dG8gcHJlc2VudCB0aGlzIGF0IElDQ1JHIGluIExvbmRvbiBpZiB0aGVyZSBpcyBhbnkgaW50ZXJl c3QNCiBpbiB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIEVDTiBpbiBRVUlDIHYxIG9yIGxhdGVy IDogSSB3b3VsZCB2ZXJ5IG11Y2ggcHJlZmVyIHRoYXQgRUNOIHN1cHBvcnQgZ29lcyBpbnRvIHYx LiBPbiB0aGUgdGVjaG5pY2FsIHNpZGUgaXQgbWFrZXMgaXQgcG9zc2libGUgdG8gZXhwZXJpbWVu dCB3aXRoIEVDTiwgcG90ZW50aWFsbHkgb24gYSBsYXJnZXIgc2NhbGUuIE9uIHRoZSBwb2xpdGlj YWwgc2lkZSBpdCBoZWxwcyB0byBtYWtlIHRoZSDigJxjaGlja2VuIGFuZA0KIGVnZ+KAnSBwcm9i bGVtIGJlY29tZSBoaXN0b3J5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5v bmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SW5nZW1hciBKb2hhbnNzb24mbmJzcDsgTS5TYy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0 LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5NYXN0ZXIgUmVzZWFyY2hlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFj ZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+RXJpY3Nzb24gUmVzZWFyY2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TmV0d29y ayBQcm90b2NvbHMgJmFtcDsgRTJFIFBlcmZvcm1hbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkxhYnJhdG9yaWVncsOkbmQgMTE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ OTcxIDI4LCBMdWxlw6UsIFN3ZWRlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5QaG9u ZSAmIzQzOzQ2LTEwNzEgNDMwNDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U01TL01N UyAmIzQzOzQ2LTczIDA3OCAzMjg5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhy ZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsdWUiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1h dXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0id3d3LmVyaWNzc29uLmNvbSI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsdWUiPnd3dy5lcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0NDQ0NERCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3Nw YWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztiYWNrZ3JvdW5kOndoaXRlIj5U aGUgd29ybGQgaXMgZnVsbCBvZiBtYWdpY2FsIHRoaW5ncyBwYXRpZW50bHkNCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzM7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7d2FpdGluZyBmb3Igb3VyIHdpdHMgdG8gZ3JvdyBzaGFycGVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztiYWNrZ3JvdW5kOndoaXRl Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVydHJhbmQgUnVzc2VsbDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PHNwYW4g c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_HE1PR0702MB3625F6E2C399F7E6F187C883C2E20HE1PR0702MB3625_-- From nobody Wed Jan 24 01:12:03 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7689612D96C for ; Wed, 24 Jan 2018 01:12:02 -0800 (PST) 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 yrP9mgkUj47r for ; Wed, 24 Jan 2018 01:12:00 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63F7712D969 for ; Wed, 24 Jan 2018 01:12:00 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id q67so2267190pga.9 for ; Wed, 24 Jan 2018 01:12:00 -0800 (PST) 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=5DgwWMJWrsPAYH+v3GIWFiDQuXkiyWm4njeI9jGcEhg=; b=fCrlvuD7KztIQoEAAcgB0gFtCX6TfkieFRQs4xGwAZKaFfHVP6FQ1pL/gReBwt4/RI 8dRhwAHILQXObrKo7NN257Ev4U2vb5yWZIzoGSdj+3czBDYfb8h9wJF8WKUnqyF6RgaO juJJaLaceFwfV3Hi9R63Sv5O6eiG1ESSx8dNuI/clOIN/TqXeI4SD/qIMeKusLAscPKG wa7KYVZm05R6tnuJjKbqsDdFdMTQbqvEAiksF+/0WtOhNcdVHa+iPIXFu0F7cXdA+jaH lf2MWv9viv9sg/YR3nAyRY9kV8eFj68lYuePEO3FVhdKngp5A85wTP47vNdb2qJAC5Ye DmfA== 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=5DgwWMJWrsPAYH+v3GIWFiDQuXkiyWm4njeI9jGcEhg=; b=ITesM0TIcKUnwe+hztIqcfIA9P9pdOHZKavEWvTEooJMMPXYYg5RGOOdPcgxCgrxEh j04k46JDzRIrPsJ1betAOlDArxFzmlkriHPYVCveUpP/6wkvFgl4iIMPTj6k557DmvRj 9MvppORIsr5xn4Qjsbn5ehKVMLIvyO5sbvL6J4ig7qZLDRxA0Tm1m9KiRoj5kPI8MVLR 0zxwbsn+1iPOkrg4eTggKJ0knSMSKeiMPxOhMIaTYSviCwMEWS+UMca7cvU4BLeb8TPU Eo/4cDp3+Nk4QUTOZMPZwxYVslF8G/9A2ZR4+jeP+ViyhWtZVc4P6QpsXQAS3cYKKWJc IISA== X-Gm-Message-State: AKwxytfzu2YTa9AJT8H34i0Qk4peocLTsFz6aovxyujX16C4/5TDmO9Z r60S34dHSmqAdgaims3yqSbNOG8MkCFa/NRz1Kg= X-Google-Smtp-Source: AH8x226lW+aldk0c41cfXkFh40DOOg9C+VGIXenESFonaTzIvTGKH6AEnMAO5Mj0alGar8Dolrd7PBx8PgEri2mPgUk= X-Received: by 10.99.125.88 with SMTP id m24mr10129685pgn.277.1516785119641; Wed, 24 Jan 2018 01:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 24 Jan 2018 01:11:58 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Wed, 24 Jan 2018 20:11:58 +1100 Message-ID: Subject: Re: Updated QCRAM Draft To: Mike Bishop Cc: IETF QUIC WG , "Charles 'Buck' Krasic" Content-Type: multipart/alternative; boundary="94eb2c1b498841c56f0563820ef8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 09:12:02 -0000 --94eb2c1b498841c56f0563820ef8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Buck, Thank you for the draft. I like the approach and I think that it is not difficult to implement. Reading the spec, the question I have is why you need the BLOCKING flag and two variables (i.e. base index and depends). Can't each HEADERS frame always hold just one offset (i.e. largest index that the frame refers to)? Maybe I am missing something. 2018-01-24 16:53 GMT+11:00 Mike Bishop : > Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/ > draft-krasic-quic-qcram-04 -- please read before tomorrow=E2=80=99s meeti= ng so we > can have a useful discussion. Thanks! > --=20 Kazuho Oku --94eb2c1b498841c56f0563820ef8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Buck,

    Thank you for the draft.

    I like the approach and I think that it is not difficult t= o implement.

    Reading the spec, the question I have= is why you need the BLOCKING flag and two variables (i.e. base index and d= epends). Can't each HEADERS frame always hold just one offset (i.e. lar= gest index that the frame refers to)?

    Maybe I am m= issing something.


    =
    2018-01-24 16:53 GMT+11:00 Mike Bishop <mbis= hop@evequefou.be>:

    Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please r= ead before tomorrow=E2=80=99s meeting so we can have a useful discussion.= =C2=A0 Thanks!




    --
    Kazuho Oku
    --94eb2c1b498841c56f0563820ef8-- From nobody Wed Jan 24 04:10:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6221200C5 for ; Wed, 24 Jan 2018 04:10:18 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 bbXL9t6cBtkA for ; Wed, 24 Jan 2018 04:10:16 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::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 06CFC1200C1 for ; Wed, 24 Jan 2018 04:10:16 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id i13so1434870ybl.9 for ; Wed, 24 Jan 2018 04:10:15 -0800 (PST) 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=eD/LfQbk3JbTGmZ7RJrYobGZYX4WSGsaZ5Q3KEMQ0sc=; b=cAgGNi683IPsexSezAnlU8UD8bvor2XhE2fq9xdZL/caXf4mCpgYNgATNd+EMD5h34 p2awoTjVwIvTxIGNzrjsjslqssOMucNWps9hgeFoq0Bq3hILJ2QuuZEoLcJpeSe6V6Qb NgLXl6NIh2VqYNPdVZS09oI89wmgGeswxnUV6a4BNLzq3PQ/nnyzXKKTM0t3sin575Qb /JdzezIs4ty+8j8gv2i45fLlWs/q1RECjMD/5rRkowuGRWG7/ABmpICUMIOU4C6us76r UVfnNeVgWIyc8+OnDOyc3hIAnEFkZEc2jHseU1qtCezFBxqkMDOMMnmfU3knn7EltANq bZRw== 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=eD/LfQbk3JbTGmZ7RJrYobGZYX4WSGsaZ5Q3KEMQ0sc=; b=O/asmz+ZzmY7AlwRL2dLlfMSpzN1PVYwxz53l5aGF3isiVjsAf8CVs3s0Hvz/V3XvC IE0LfmFv0fZdXdGndLG1DhXOxs5seyeB5/tQDlcyqw9ZoPeGhQ3mOGFonU1lN6YZkrib wx7wfr7FD9F45iuZXmbvPYGCIar2S2JWfD+0JYIGiHHSF5z8p9yryYqx0pPl+SDJFALF ltl0/svWSQbdPhDb2/W6qFzeRPbJ5qeYFrPz8LFnrtm5bf/bDUhyZBevGSCTxwDL1m6z dAQAeOQ/7u2GJRwZsfXPgbPD7KsUHQBhFY52ZD4Z4U6nLQ4ytDzhHpaSrLrnymMsTXNy oF6Q== X-Gm-Message-State: AKwxytdfp5W2ROHuavv12LfxWhHA7faW6Uv9MDoGHK4VCO6Fx5cQEj2p YdmnbhpeL+YUVdcm8lc5+i6EDKqon0ls8ccptK4e9Uor X-Google-Smtp-Source: AH8x224Xgg5xy2/uNo9kS7CQQg53EZdl9L116x/rJ62//oPSdFlo2TiUdHzWKLRKOT2W8dyyvxSqXJo2IhIucr5kSD8= X-Received: by 10.37.94.6 with SMTP id s6mr4979975ybb.323.1516795814838; Wed, 24 Jan 2018 04:10:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.12.70 with HTTP; Wed, 24 Jan 2018 04:10:14 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 24 Jan 2018 23:10:14 +1100 Message-ID: Subject: Re: Updated QCRAM Draft To: Kazuho Oku Cc: Mike Bishop , IETF QUIC WG , "Charles 'Buck' Krasic" Content-Type: multipart/alternative; boundary="001a1140fdc4bdfbfb0563848b67" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 12:10:18 -0000 --001a1140fdc4bdfbfb0563848b67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The draft outlines what I think the room converged on, and it seems fairly straightforward -- thanks for the quick turnaround! Kazuho: I could be wrong, so Buck or Mike should correct me if so, but I believe the "Base Index" is basically what I think of as the "generation ID" of the table. It reflects the number of table operations that have happened... this is important when you have evictions, since just a reference to the largest index is ambiguous if there have been evictions. I don't understand however how the largest index is "Base Index - Depends". I would've thought the largest index would simply be "Depends". What am I missing? On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku wrote: > Buck, > > Thank you for the draft. > > I like the approach and I think that it is not difficult to implement. > > Reading the spec, the question I have is why you need the BLOCKING flag > and two variables (i.e. base index and depends). Can't each HEADERS frame > always hold just one offset (i.e. largest index that the frame refers to)= ? > > Maybe I am missing something. > > > 2018-01-24 16:53 GMT+11:00 Mike Bishop : > >> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/dr >> aft-krasic-quic-qcram-04 -- please read before tomorrow=E2=80=99s meetin= g so we >> can have a useful discussion. Thanks! >> > > > > -- > Kazuho Oku > --001a1140fdc4bdfbfb0563848b67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    The draft outlines what I think the room converged on, and= it seems fairly straightforward -- thanks for the quick turnaround!
    Kazuho: I could be wrong, so Buck or Mike should correct me if= so, but I believe the "Base Index" is basically what I think of = as the "generation ID" of the table. It reflects the number of ta= ble operations that have happened... this is important when you have evicti= ons, since just a reference to the largest index is ambiguous if there have= been evictions.=C2=A0

    I don't understand howe= ver how the largest index is "Base Index - Depends". I would'= ve thought the largest index would simply be "Depends". What am I= missing?

    On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <kazuhooku@gmail.com= > wrote:
    Buck,=

    Thank you for the draft.

    I lik= e the approach and I think that it is not difficult to implement.

    Reading the spec, the question I have is why you need the B= LOCKING flag and two variables (i.e. base index and depends). Can't eac= h HEADERS frame always hold just one offset (i.e. largest index that the fr= ame refers to)?

    Maybe I am missing something.


    2018-01-24 16:53 GMT+11:00 Mike Bishop <mbishop@e= vequefou.be>:

    Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please r= ead before tomorrow=E2=80=99s meeting so we can have a useful discussion.= =C2=A0 Thanks!




    --
    Kazuho Oku

    --001a1140fdc4bdfbfb0563848b67-- From nobody Wed Jan 24 05:42:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78B33124239 for ; Wed, 24 Jan 2018 05:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 FQQSAPreGs3p for ; Wed, 24 Jan 2018 05:42:49 -0800 (PST) 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 AB2A11241F8 for ; Wed, 24 Jan 2018 05:42:49 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0ODaruI006007; Wed, 24 Jan 2018 13:42:46 GMT 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=VSFaN8lvhQ1FdJ/HbdBhGTrv4kdWMx3++zIRzeaTGJQ=; b=ImrI1wpw0pK8Vp+dVy6/tx9OMHsyl/56kMrRvrGp+c19O3rXZ/dqdoGxHGZge2Fzo4RY I+5N9XpJtoDjjG3SbTcXlt59iheKb2NTgH0VNjYZuXS3QjSDWpQtc1gHUhPnMu34Pzhr 342K5GtYLskuAam9cfT7GnGcrdPfh1LLSxu/RfZIAUrdG99DV4LdPQdI5nHetRPth/99 AOWcVsrz5TsJ6xQ82d8BwXZyp1nhMHIhjurGEdoMM5ke8oJVhuRvvx98RR2WUX17eUsJ DI/G1JfNxPUleZKMmXGp2ul5q4XL8liIgOi7KVtGDZcUbiTYwSth4R3OJ0SAt+YB0eR2 ig== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2fkxa1wp61-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 13:42:46 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0ODZc7e011807; Wed, 24 Jan 2018 08:42:45 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fm1yyngdx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 08:42:45 -0500 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, 24 Jan 2018 08:42:44 -0500 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, 24 Jan 2018 08:42:44 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "martin.h.duke@gmail.com" , "subodh@fb.com" CC: "quic@ietf.org" Subject: RE: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNFo0y0NS2zYe0mRyyv7KOC+e6OC0AuAgAAAc4D//60wMIAAf1gAgAALw4Y= Date: Wed, 24 Jan 2018 13:42:43 +0000 Message-ID: <7d8388b249d141d795f9c9f3bdb88433@usma1ex-dag1mb5.msg.corp.akamai.com> References: , <6d7331bfb9e041e4a712f3edf99a3001@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_7d8388b249d141d795f9c9f3bdb88433usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240183 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240183 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 13:42:52 -0000 --_000_7d8388b249d141d795f9c9f3bdb88433usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The argument that connection id can be self-describing is not wrong. Connection id can be self-describing, and it would need to be, if the sever= is to allow using different lengths for different connections and to do ke= y rotation. It does add complexity to connection id generation (cannot easi= ly use AES instruction to do encryption) and reduces the number of availabl= e bits, even for shorter connection IDs. Victor's suggestion is to use just one extra bit in the packet type octet t= o avoid all of these troubles. It does bring up questions of requiring cons= istency in those bits throughout the connection lifetime - a definite "cost= " of the scheme. But it also has benefits (see above). So this seems to be = a viable option, but not a obvious option (since trade-offs are needed). - Igor -----Original Message----- From: Subodh Iyengar [subodh@fb.com] Received: Wednesday, 24 Jan 2018, 3:00AM To: Lubashev, Igor [ilubashe@akamai.com]; Martin Duke [martin.h.duke@gmail.= com]; Martin Thomson [martin.thomson@gmail.com] CC: IETF QUIC WG [quic@ietf.org] Subject: Re: A better way to do conn id? > (Victor voiced this today) Steal a code point from the packet type: have = 2 bits that represent Why do we need to represent the size of the connection id as bits in the pa= cket? We usually represent the lengths as bits in the packet for 2 reasons: 1. to be able to change them per packet 2. If they need to be interpreted by unrelated parties. I raised this question in the meeting today whether or not connid size need= s to change with every packet and the answer seemed no. Also in the current= design the interpretation of connid is only relevant to the server / relat= ed parties, in which case the server could represent it's connid in its own= self describing format which doesn't need any new bits. L3 load balancers = and L7 load balancers would share the knowledge of the format of the connec= tion id to determine how long it is. So it would seem like we don't need an= y extra bits. Are any of these assumptions I'm making incorrect? Subodh ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Tuesday, January 23, 2018 9:34:47 PM To: Martin Duke; Martin Thomson Cc: IETF QUIC WG Subject: RE: A better way to do conn id? The two alternatives to allow for key rotation to =93avoid=94 going over 16= octets are: 1. (Victor voiced this today) Steal a code point from the packet type: h= ave 2 bits that represent: 0-byte connection id; 8-byte connection id; 16-byte connection id (key a); 16-byte connection id (key b) 1. =93Trial Encryption=94 : Steal a bit from your 128 bit connection ID Your bit 0 of your Connection ID will represent the key used for encryption= . Since you have entropy in your Connection ID, keep generating new entropy a= nd encrypting, until bit 0 comes out just the way you want it. On average,= you will do 0.75 extra encryption operations. * Igor From: Martin Duke [mailto:martin.h.duke@gmail.com] Sent: Wednesday, January 24, 2018 12:21 AM To: Martin Thomson Cc: IETF QUIC WG Subject: Re: A better way to do conn id? Very well, replace 16 with whatever number you guys come up with. On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson > wrote: We have already concluded that if you want to do sane crypto, plus some sort of key identification, then you need MORE than 16 octets (though not much more). That makes things more complicated. ekr has an outcome that he will write up. On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke > wrote: > Today's variable-length connection ID discussion made me realize some > problems with the current architecture, while the new architecture doesn'= t > fix some of them and creates whole new ones. Issues: > > - The client desires unlinkability, but I suspect the market will provide= no > incentives for servers to work very hard to be unlinkable. There were > conflicting "layer 9" arguments that variable conn ID makes this problem > worse or better. > > - 16 Bytes is more overhead than 8 bytes. > > - The severity of this remains to be seen, but variable length conn ids w= ill > introduce more complexity in parsers and anything that utilizes the conn = id > (e.g. handshake key generation). It might make the invariants more comple= x > as well. The whole thing, frankly, makes my head hurt. > > I humbly suggest the following proposal might avoid or mitigate some of > these problems: > > 1. Every connection has a long-lived Client-generated Connection ID (CGCI= D) > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and the > SGCID is 16 bytes. > > 2. The CGCID is used to derive the handshake key. (unchanged from status > quo) > > 3. The initial packet uses the CGCID. All other handshake packets use th= e > SGCID. This is unchanged from the status quo. > > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT packe= ts > sent by the server use the CGCID. This has two important properties: > a) The server gets the 16 Bytes of entropy the load balancer > needs > b) The server->client direction, which in the usual case has m= ost > of the data, has a lower-overhead CID. > > 5. The algorithm that generates SGCID MUST have different output given a > different CGCID. [We might strengthen this language further: you wouldn't > want to simply add the NEW_CONN_ID sequence number to the existing SGCID, > for instance]. > > 6. In advance of migration, the client sends a NEW_CONN_ID frame to provi= de > a new CGCID (possibly omitting the stateless reset token). The server MUS= T > respond with a NEW_CONN_ID that provides a new SGCID derived from the new > CGCID. All packets on the new path use these CIDs. > > If people like this, I can generate a PR. I am very open to various tweak= s > to the general approach as well. I wanted to get this out there before th= e > variable-length CID team gets deep in the weeds. > > Martin Duke > > --_000_7d8388b249d141d795f9c9f3bdb88433usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The argument that connection id can be self-describing is = not wrong.

    Connection id can be self-describing, and it would need to be, if the sever= is to allow using different lengths for different connections and to do ke= y rotation. It does add complexity to connection id generation (cannot easi= ly use AES instruction to do encryption) and reduces the number of available bits, even for shorter connection IDs.=

    Victor's suggestion is to use just one extra bit in the packet type octet t= o avoid all of these troubles. It does bring up questions of requiring cons= istency in those bits throughout the connection lifetime - a definite "= ;cost" of the scheme. But it also has benefits (see above). So this seems to be a viable option, but not a obvio= us option (since trade-offs are needed).

    - Igor

    -----Original Message-----
    From: Subodh Iyengar [subodh@fb.com]
    Received: Wednesday, 24 Jan 2018, 3:00AM
    To: Lubashev, Igor [ilubashe@akamai.com]; Martin Duke [martin.h.duke= @gmail.com]; Martin Thomson [martin.thomson@gmail.com]
    CC: IETF QUIC WG [quic@ietf.org]
    Subject: Re: A better way to do conn id?

    > (Vic= tor voiced this today) Steal a code point from the packet type: have 2 bits= that represent

    Why do we need to represent the size of the connection id as bits in the pa= cket? We usually represent the lengths as bits in the= packet for 2 reasons:

    1. to be able to change them p= er packet
    2. If they need to be interpreted by unrelated pa= rties.


    I raised this question in the m= eeting today whether or not connid size needs to change with every packet and the answer seemed no. Also in the current design the interpretation of connid = is only relevant to the server / related parties, in which case the server = could represent it's connid in its own self describing format which doesn't need any new bits. L3 load balanc= ers and L7 load balancers would share the knowledge of the format of the co= nnection id to determine how long it is. So it would seem like we don't nee= d any extra bits. Are any of these assumptions I'm making incorrect?


    Subodh

    From: QUIC <quic-bounces= @ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
    Sent: Tuesday, January 23, 2018 9:34:47 PM
    To: Martin Duke; Martin Thomson
    Cc: IETF QUIC WG
    Subject: RE: A better way to do conn id?
     

    The two alternatives to allow for key rotation to = =93avoid=94 going over 16 octets are:

     

    1. (Victor voiced t= his today) Steal a code point from the packet type: have 2 bits that repres= ent:

    0-byte connection id;

    8-byte connection id;

    16-byte connection id (= key a);

    16-byte connection id (= key b)

     

    1. =93Trial Encrypt= ion=94 : Steal a bit from your 128 bit connection ID

    Your bit 0 of your Connection ID will repre= sent the key used for encryption.
    Since you have entropy in your Connection ID, keep generating new entropy a= nd encrypting, until bit 0 comes out just the way you want it.  On ave= rage, you will do 0.75 extra encryption operations.

     

    • Igor

     

    From: Martin Duke [mailto:martin.h.duke@gma= il.com]
    Sent: Wednesday, January 24, 2018 12:21 AM
    To: Martin Thomson <martin.thomson@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: A better way to do conn id?

     

    Very well, replace 16 with whatever number you guy= s come up with.

     

    On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:

    We have already concluded that if you want to do s= ane crypto, plus
    some sort of key identification, then you need MORE than 16 octets
    (though not much more).  That makes things more complicated.  ekr= has
    an outcome that he will write up.


    On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
    > Today's variable-length connection ID discussion made me realize some<= br> > problems with the current architecture, while the new architecture doe= sn't
    > fix some of them and creates whole new ones. Issues:
    >
    > - The client desires unlinkability, but I suspect the market will prov= ide no
    > incentives for servers to work very hard to be unlinkable. There were<= br> > conflicting "layer 9" arguments that variable conn ID makes = this problem
    > worse or better.
    >
    > - 16 Bytes is more overhead than 8 bytes.
    >
    > - The severity of this remains to be seen, but variable length conn id= s will
    > introduce more complexity in parsers and anything that utilizes the co= nn id
    > (e.g. handshake key generation). It might make the invariants more com= plex
    > as well. The whole thing, frankly, makes my head hurt.
    >
    > I humbly suggest the following proposal might avoid or mitigate some o= f
    > these problems:
    >
    > 1. Every connection has a long-lived Client-generated Connection ID (C= GCID)
    > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and t= he
    > SGCID is 16 bytes.
    >
    > 2. The CGCID is used to derive the handshake key. (unchanged from stat= us
    > quo)
    >
    > 3. The initial packet uses the CGCID.  All other handshake packet= s use the
    > SGCID. This is unchanged from the status quo.
    >
    > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT pa= ckets
    > sent by the server use the CGCID. This has two important properties: >            a) The server gets the 16 Byt= es of entropy the load balancer
    > needs
    >            b) The server->client dire= ction, which in the usual case has most
    > of the data, has a lower-overhead CID.
    >
    > 5. The algorithm that generates SGCID MUST have different output given= a
    > different CGCID. [We might strengthen this language further: you would= n't
    > want to simply add the NEW_CONN_ID sequence number to the existing SGC= ID,
    > for instance].
    >
    > 6. In advance of migration, the client sends a NEW_CONN_ID frame to pr= ovide
    > a new CGCID (possibly omitting the stateless reset token). The server = MUST
    > respond with a NEW_CONN_ID that provides a new SGCID derived from the = new
    > CGCID. All packets on the new path use these CIDs.
    >
    > If people like this, I can generate a PR. I am very open to various tw= eaks
    > to the general approach as well. I wanted to get this out there before= the
    > variable-length CID team gets deep in the weeds.
    >
    > Martin Duke
    >
    >

     

    --_000_7d8388b249d141d795f9c9f3bdb88433usma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 05:50:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328DA12422F for ; Wed, 24 Jan 2018 05:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YujIh-v5T-ob for ; Wed, 24 Jan 2018 05:50:53 -0800 (PST) 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 C4EC71241F8 for ; Wed, 24 Jan 2018 05:50:53 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0ODlflH025920; Wed, 24 Jan 2018 13:50:51 GMT 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=ISuTzr2DVX4dLjrnal/kuBLeNdULP2yP5ZSMXRaQoOM=; b=VMbz1Q1Sn3SRg0CPh5n0KfjvSY/uYC5QI/qNOpTcG8zEgqEoGLBYRs4c961xd9hxWgex u4r6JpsMiOYypcd+GbzgjUbD8PBfD/YPbMXqpZhvJ+u7CWp3mW0mVnvz3l/+G/Tn0mnK vlWdCMxEyTXQvts78nWIk9IjEl5W/ODsMFW44xvGGKYoTfS7DLNI4fFx0P6+udGI8Yci YE6zDzHqFFnwovENkE5ml4WfNDgxXAyZyGabWzqOTYRaHR+iv/JL5hzBtwcEOC3hN4Mk FZcLnVRazHVK/283xO1Lul8SR1jse23mvQxKPJzumbrH7WtAsiHSBpr/h90jvsUYnrRs hw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2fpkvpt3mp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 13:50:50 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0ODonHM004724; Wed, 24 Jan 2018 08:50:49 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2fp9tvajt5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 08:50:49 -0500 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; Wed, 24 Jan 2018 08:50:43 -0500 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, 24 Jan 2018 08:50:44 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "ingemar.s.johansson@ericsson.com" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QANT3GJ Date: Wed, 24 Jan 2018 13:50:43 +0000 Message-ID: <068c1f9c7125401d91a368ee0ca1ab83@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 Content-Type: multipart/alternative; boundary="_000_068c1f9c7125401d91a368ee0ca1ab83usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240185 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240184 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 13:50:57 -0000 --_000_068c1f9c7125401d91a368ee0ca1ab83usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are right - it was not easy to catch everything. I came with an impress= ion that the main objection to counters was not connection migration but in= compatibility with the future multi-path. Even though multi-path is not in = scope for v1, people were afraid of the total incompatibility of the scheme= . Am I the only one with that impression? - Igor -----Original Message----- From: Ingemar Johansson S [ingemar.s.johansson@ericsson.com] Received: Wednesday, 24 Jan 2018, 3:01AM To: QUIC WG [quic@ietf.org] Subject: ECN in QUIC Hi A few impressions on the ECN in QUIC discussions. The audio was so-so, freq= uent interruptions and LARGE differences in audio level + badly implemented= ears ?, so sometimes I missed the details and possibly kick in open doors. * Feedback format. I understand that the proposed proposal based on ECT(0)= , ECT(1) and CE counters does not play well with connection migration. I be= lieve, but I am not 100% sure that I understand the problem. I understand t= hat there are two concerns (perhaps more?): 1. Counters are reset, this means that there will be a potentially very l= arge (negative?) difference in CE marked packets. I believe that this can b= e detected as false congestion signal and ignored by the congestion signal. 2. Difficulties to detect ECN bleaching. It is tricky to understand if pa= ckets along the new path are bleached based on the ECT counters. This can b= e a more complicated case. In any case it was suggested to indicate the ECN bits for the packets in th= e ACK frame. Such a format was actually outlined in earlier proposal (see p= age 6, Figure 3 in https://tools.ietf.org/html/draft-johansson-quic-ecn-01<= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Djohansson-2Dquic-2Decn-2D01&d=3DDwMGaQ&c=3D96ZbZZcaMF4w0F4jpN6LZg&r= =3DDjn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=3DxVzIA9f7WjK8CVIQ3B-v9ZNl= -Uf8HCY4nYPb0fMRO-4&s=3DS9aqc8UIGaTDX3ZMs1VTyWiLSSG01ndFhhr_Zg01H1Y&e=3D> )= . It is Ok with me to change to a format similar to this if the group prefe= rs that. * Congestion control for ECT(1), L4S : My feeling is that it is for now OK = to leave this as future work. That does not mean that there are absolutely = no ideas on how to implement this, for short RTT environments DCTCP style c= ongestion control is quite OK. Furthermore I and recently worked on a L4S c= ongestion control that is based on BBR, the results look quite promising an= d the changes to the BBR algorithm are quite minimal. I am willing to prese= nt this at ICCRG in London if there is any interest in this. * ECN in QUIC v1 or later : I would very much prefer that ECN support goes = into v1. On the technical side it makes it possible to experiment with ECN,= potentially on a larger scale. On the political side it helps to make the = "chicken and egg" problem become history. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson Research Network Protocols & E2E Performance Labratoriegr?nd 11 971 28, Lule?, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com The world is full of magical things patiently waiting for our wits to grow sharper Bertrand Russell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_068c1f9c7125401d91a368ee0ca1ab83usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are right - it was not easy to catch everything. I cam= e with an impression that the main objection to counters was not connection= migration but incompatibility with the future multi-path. Even though multi-path is not in scope for v1, peop= le were afraid of the total incompatibility of the scheme. Am I the only on= e with that impression?

    - Igor

    -----Original Message-----
    From: Ingemar Johansson S [ingemar.s.johansson@ericsson.com]
    Received: Wednesday, 24 Jan 2018, 3:01AM
    To: QUIC WG [quic@ietf.org]
    Subject: ECN in QUIC

    Hi

     

    A few impressions on the ECN in QUIC discussions. Th= e audio was so-so, frequent interruptions and LARGE differences in audio le= vel + badly implemented ears �&= #56842;, so sometimes I missed the details and possibly kick in open= doors.

     

    *  Feedback format. I understand that the propo= sed proposal based on ECT(0), ECT(1) and CE counters does not play well wit= h connection migration. I believe, but I am not 100% sure that I understand= the problem. I understand that there are two concerns (perhaps more?):

      1. Counters are reset, this means that there = will be a potentially very large (negative?) difference in CE marked packet= s. I believe that this can be detected as false congestion signal and ignor= ed by the congestion signal.

      2. Difficulties to detect ECN bleaching. It i= s tricky to understand if packets along the new path are bleached based on = the ECT counters. This can be a more complicated case.

    In any case it was suggested to indicate the ECN bit= s for the packets in the ACK frame. Such a format was actually outlined in = earlier proposal (see page 6, Figure 3 in https://tools.ietf.org/html/draft-johansson-quic-ecn-01 ). It is Ok wit= h me to change to a format similar to this if the group prefers that.

     

    * Congestion control for ECT(1), L4S : My feeling is= that it is for now OK to leave this as future work. That does not mean tha= t there are absolutely no ideas on how to implement this, for short RTT env= ironments DCTCP style congestion control is quite OK. Furthermore I and recently worked on a L4S congestion control= that is based on BBR, the results look quite promising and the changes to = the BBR algorithm are quite minimal. I am willing to present this at ICCRG = in London if there is any interest in this.

    * ECN in QUIC v1 or later : I would very much prefer= that ECN support goes into v1. On the technical side it makes it possible = to experiment with ECN, potentially on a larger scale. On the political sid= e it helps to make the “chicken and egg” problem become history.

     

    /Ingemar

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

    Ingemar Johansson = ; M.Sc.

    Master Researcher

     

    Ericsson Research

    Network Protocols &= ; E2E Performance

    Labratoriegränd 1= 1

    971 28, Luleå, S= weden

    Phone +46-1071 430= 42

    SMS/MMS +46-73 078= 3289

    ingemar.s.johansso= n@ericsson.com

    w= ww.ericsson.com

    &n= bsp;

    The world is full of magical things patiently

        waiting for our wits to grow sharper

              &nbs= p;    Bertrand Russell
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D    <= /p>

     

    --_000_068c1f9c7125401d91a368ee0ca1ab83usma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 05:53:40 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973DD124207 for ; Wed, 24 Jan 2018 05:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 dFmang-MY69A for ; Wed, 24 Jan 2018 05:53:37 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0453D1241F8 for ; Wed, 24 Jan 2018 05:53:36 -0800 (PST) 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=9FqOe7fgIDB7d9PV9ZAnIbn9gGeXxn8BnSEtniGbu6E=; b=LxVJ14/Z6zxMHgbtNEiJdaLch2uZ1xmisJQu/f7XE58/tk7Cih8IfUYbajdqrBCUoOB1OLbRQfj89fnir62ulaopXCIEBHEUdHSFSLNQJsTNoDPptPXdeVwQ+zfoiLXiF+U3ZUUeuMP5BWkO/nvu3VbUu+/u+DxYc9gw2FAuOuM= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1037.eurprd07.prod.outlook.com (10.161.111.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Wed, 24 Jan 2018 13:53:33 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79%14]) with mapi id 15.20.0444.008; Wed, 24 Jan 2018 13:53:33 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Subodh Iyengar , "Lubashev, Igor" , Martin Duke , Martin Thomson CC: IETF QUIC WG , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Subject: Re: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNFpZktDW5VFAk2UUOOMSGGBoKOCfDqAgAAAcoCAAAPIgIAAKMAAgABimgA= Date: Wed, 24 Jan 2018 13:53:33 +0000 Message-ID: References: <6d7331bfb9e041e4a712f3edf99a3001@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [88.111.107.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1037; 7:8dySw2/0fgIwbe7hiq4yzT9cX3FMqzfmH5rT6O6ctM77T1GVZP0dThq8eYOhRNXfNTrdPLC+JMZZfn4tRQhd5n6zbFtYy4NC0i+bHh6eRF2yK60MJN69MyFS0zh4rdcikLzNvOT5p0FkhSRTA5VA7dnkzkhAlsAROpjBw1Yy6qfAFJ5HKh2rnBylg+6jcdRyJ0pyOlVdba07giDfDWTw9OLmJ826Y/IEPC04t1eJnUGItT2J+3qt6IaqqkKBP3AZ x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(39380400002)(366004)(199004)(189003)(57704003)(33656002)(6486002)(54896002)(107886003)(236005)(6512007)(76176011)(6436002)(6246003)(106356001)(6306002)(39060400002)(25786009)(229853002)(36756003)(68736007)(83716003)(5250100002)(6506007)(82746002)(3660700001)(58126008)(316002)(66066001)(110136005)(4326008)(54906003)(3280700002)(99286004)(53546011)(93886005)(53936002)(102836004)(83506002)(26005)(478600001)(2906002)(97736004)(105586002)(8936002)(8676002)(81156014)(81166006)(6116002)(3846002)(2900100001)(86362001)(7736002)(5660300001)(2950100002)(14454004)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1037; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5269d8c7-4402-459c-9426-08d56331dbb7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR07MB1037; x-ms-traffictypediagnostic: VI1PR07MB1037: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231046)(11241501184)(806099)(2400081)(944501161)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR07MB1037; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1037; x-forefront-prvs: 056297E276 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +wnX7xZ+wQoAoght3zSwuIIY0tmPJkrv6Rg1J5vX6NXnrDklnBSBwSjig9/FkFM/hDlq+Z9Io69zYORiWQeg3xhejGCRBD7uKA1vtuvqEAcRxMiyn5Pcjt/IWxfy24S4 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_C9597BA10DDF4572BF13D94DAA3B4812nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5269d8c7-4402-459c-9426-08d56331dbb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 13:53:33.2488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1037 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 13:53:39 -0000 --_000_C9597BA10DDF4572BF13D94DAA3B4812nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gMjQvMDEvMjAxOCwgMDg6MDAsICJRVUlDIG9uIGJlaGFsZiBvZiBTdWJvZGggSXllbmdhciIg PHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPiBvbiBi ZWhhbGYgb2Ygc3Vib2RoQGZiLmNvbTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+IHdyb3RlOg0KDQoN Cj4gKFZpY3RvciB2b2ljZWQgdGhpcyB0b2RheSkgU3RlYWwgYSBjb2RlIHBvaW50IGZyb20gdGhl IHBhY2tldCB0eXBlOiBoYXZlIDIgYml0cyB0aGF0IHJlcHJlc2VudA0KDQpXaHkgZG8gd2UgbmVl ZCB0byByZXByZXNlbnQgdGhlIHNpemUgb2YgdGhlIGNvbm5lY3Rpb24gaWQgYXMgYml0cyBpbiB0 aGUgcGFja2V0PyBXZSB1c3VhbGx5IHJlcHJlc2VudCB0aGUgbGVuZ3RocyBhcyBiaXRzIGluIHRo ZSBwYWNrZXQgZm9yIDIgcmVhc29uczoNCjEuICAgICAgdG8gYmUgYWJsZSB0byBjaGFuZ2UgdGhl bSBwZXIgcGFja2V0DQoyLiAgICAgIElmIHRoZXkgbmVlZCB0byBiZSBpbnRlcnByZXRlZCBieSB1 bnJlbGF0ZWQgcGFydGllcy4NClRoaXMgc2FtZSB0aGluZyBjYW1lIG91dCBpbiB0aGUgZGlzY3Vz c2lvbiBhcm91bmQgY29ubmVjdGlvbi1pZCBpbiBEVExTLiAgSWYgdHJvdWJsZXNob290aW5nIGlz IGEgY29uY2VybiAoYW5kIEkgdGhpbmsgaXQgc2hvdWxkKSwgdGhlbiBhbiDigJx1bnJlbGF0ZWTi gJ0gcGFydHkgbWlnaHQgbmVlZCB0byBkZWNvZGUgQ0lEIChlLmcuLCB0byBzaW5nbGUgb3V0IGEg ZmxvdyBhbW9uZyBnYXppbGxpb24gb3RoZXJzKS4NCg0KQ2hlZXJzDQo= --_000_C9597BA10DDF4572BF13D94DAA3B4812nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnAueG1zb25vcm1hbCwgbGkueG1zb25vcm1hbCwgZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxl LW5hbWU6eF9tc29ub3JtYWw7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLnhtc29saXN0cGFyYWdyYXBoLCBsaS54bXNvbGlzdHBhcmFncmFwaCwgZGl2Lnhtc29saXN0 cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvbGlzdHBhcmFncmFwaDsNCgltYXJnaW4t dG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdp bi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLnhtc29ub3JtYWwwLCBs aS54bXNvbm9ybWFsMCwgZGl2Lnhtc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvbm9y bWFsMDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAueG1zb2NocGRl ZmF1bHQsIGxpLnhtc29jaHBkZWZhdWx0LCBkaXYueG1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxl LW5hbWU6eF9tc29jaHBkZWZhdWx0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi54ZW1haWxzdHlsZTE4DQoJe21zby1zdHlsZS1uYW1lOnhfZW1haWxzdHlsZTE4 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCglt YXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7 bXNvLWxpc3QtaWQ6MTE4MDE5OTM5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTYzMDU0NzA3 MDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzExNTE4NDY1Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotNjQxOTU0MDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDINCgl7bXNvLWxpc3QtaWQ6MTg1OTQ2ODc4NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTMzNDc0Mzk0Mjt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDU5OTMyMDc3Ow0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMTY4NDM0NjE5NDt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0LzAx LzIwMTgsIDA4OjAwLCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBTdWJvZGggSXllbmdhciZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpzdWJvZGhAZmIuY29t Ij5zdWJvZGhAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bToxMi4wcHQ7bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxhIG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IChWaWN0b3Igdm9p Y2VkIHRoaXMgdG9kYXkpIFN0ZWFsIGEgY29kZSBwb2ludCBmcm9tIHRoZSBwYWNrZXQgdHlwZTog aGF2ZSAyIGJpdHMgdGhhdCByZXByZXNlbnQ8YnI+DQo8YnI+DQpXaHkgZG8gd2UgbmVlZCB0byBy ZXByZXNlbnQgdGhlIHNpemUgb2YgdGhlIGNvbm5lY3Rpb24gaWQgYXMgYml0cyBpbiB0aGUgcGFj a2V0PyBXZSB1c3VhbGx5IHJlcHJlc2VudCB0aGUgbGVuZ3RocyBhcyBiaXRzIGluIHRoZSBwYWNr ZXQgZm9yIDIgcmVhc29uczo8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+dG8gYmUgYWJsZSB0byBjaGFuZ2UgdGhlbSBwZXIgcGFja2V0PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHls ZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PklmIHRoZXkgbmVlZCB0byBiZSBpbnRlcnByZXRlZCBieSB1bnJlbGF0ZWQgcGFydGllcy48L3Nw YW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5UaGlzIHNhbWUgdGhpbmcgY2FtZSBvdXQgaW4gdGhlIGRpc2N1c3Npb24gYXJvdW5k IGNvbm5lY3Rpb24taWQgaW4gRFRMUy4mbmJzcDsgSWYgdHJvdWJsZXNob290aW5nIGlzIGEgY29u Y2VybiAoYW5kIEkgdGhpbmsgaXQgc2hvdWxkKSwgdGhlbiBhbiDigJx1bnJlbGF0ZWTigJ0NCiBw YXJ0eSBtaWdodCBuZWVkIHRvIGRlY29kZSBDSUQgKGUuZy4sIHRvIHNpbmdsZSBvdXQgYSBmbG93 IGFtb25nIGdhemlsbGlvbiBvdGhlcnMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_C9597BA10DDF4572BF13D94DAA3B4812nokiacom_-- From nobody Wed Jan 24 06:20:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC9D12422F for ; Wed, 24 Jan 2018 06:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 Sf_ccWUgZG6y for ; Wed, 24 Jan 2018 06:20:23 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 450AD1243F6 for ; Wed, 24 Jan 2018 06:20:23 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id w17so2788626pgv.6 for ; Wed, 24 Jan 2018 06:20:23 -0800 (PST) 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=kQt5dd49/9yFsHVoNGO+walXXMQhSD2ACjDvNfzoicY=; b=Zy3fHNXZlGM6Ww4/5HQhYC4kNmyVeoZuqoJTNzMcPodthevVolylaGWdVxofrwGe4R hFX/f/pkpT96HWNfUcD946kfp76FnGcRlVfXEUZUjmopk4lNRgfNPJhe4V6JBphN/GZF XqlhQwW9bBueqVb7ZvkjPoCBggbQaDtG9Z5xN5wta00Z+P6JxrFTFemUbAGmxh5cJEnF A+BiXna7naqjwNvsQvieVw14GNyIYgcuX+wpdL0vLihH2bTtcf7kdCuz8NYEGcqEMJLD KSZ29r/56uPJmNvl5pyVqKvDminx/Eh5KpRAWmY6z/9gQIc21uU18AgCx8Dgu/w6jgNT a5vA== 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=kQt5dd49/9yFsHVoNGO+walXXMQhSD2ACjDvNfzoicY=; b=KXkPcaBP3FgUzmjvXWKlmIht40Iy2mup6o5pNdP3izVU8yAhcvKxZWoXKb0JF6X73Z NDZseclU2MTOmbNd0hEHSkfJLtPqlEOTsMkTm6teMoU2hfBKPlAitLE+6oS6elDqBmKe pS3OoQ8RCeIhl6tjBw7Z/lZdMLHWXGqnIV+ik1ksNcURSfw6JNq8MkxS/vjUds/mzbiL UQWGlEhuPomC4zBAYYXZr0Pa8BY8cpxyoTBew2RSMycDy/VdcCvy4EV5u3MiTl4i7NPQ GvY8vZ/a/+XbLfosPuj3Ggsd3e7bXXEf5IKj/52DJgGW2+2xdW3C+NWg26wwvZZ/OVd6 hjkQ== X-Gm-Message-State: AKwxytemS4Ocr4VThR/bH1MkoFh59dW59IW/9ANhs9ZGC2hCDra9p7S1 nGd6T5mtfHlCQHUMYBWZDYz9BIXfK7mWIJLVraY= X-Google-Smtp-Source: AH8x225JV7rZjvnNCRepLzFBnlxntE1Q+QsS9ceZd9w7YEylQ1CexobKcVEub695Ka+Ijtgm1G1jI3QGydJ7+ZIHYn0= X-Received: by 2002:a17:902:d217:: with SMTP id t23-v6mr8527397ply.303.1516803622499; Wed, 24 Jan 2018 06:20:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 24 Jan 2018 06:20:20 -0800 (PST) In-Reply-To: <6d7331bfb9e041e4a712f3edf99a3001@usma1ex-dag1mb5.msg.corp.akamai.com> References: <6d7331bfb9e041e4a712f3edf99a3001@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kazuho Oku Date: Thu, 25 Jan 2018 01:20:20 +1100 Message-ID: Subject: Re: A better way to do conn id? To: "Lubashev, Igor" Cc: Martin Duke , Martin Thomson , IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000001cfa620563865df2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 14:20:25 -0000 --0000000000001cfa620563865df2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018-01-24 16:34 GMT+11:00 Lubashev, Igor : > The two alternatives to allow for key rotation to =E2=80=9Cavoid=E2=80=9D= going over 16 > octets are: > > > > 1. (Victor voiced this today) Steal a code point from the packet type: > have 2 bits that represent: > > 0-byte connection id; > > 8-byte connection id; > > 16-byte connection id (key a); > > 16-byte connection id (key b) > > > > 1. =E2=80=9CTrial Encryption=E2=80=9D : Steal a bit from your 128 bit = connection ID > > Your bit 0 of your Connection ID will represent the key used for > encryption. > Since you have entropy in your Connection ID, keep generating new entropy > and encrypting, until bit 0 comes out just the way you want it. On > average, you will do 0.75 extra encryption operations. > Thank you for summarizing the two approaches. What I am bit afraid of using the bits in the packet type is that the approach hardcodes the relation between the frequency of key rotation and the maximum lifetime of a QUIC connection. Consider the case where you want to switch from key A to key B. Correct me if I am wrong, but IIUC there is no way for a server to enforce the client to switch to a new connection ID. Therefore, the server will be enforced to shutdown all the connections using the IDs generated by using key A before the key gets retired. For example, if you plan to do the rollover from key A to key B in 24 hours, the minimum maximum of the lifetime of a connection will be restricted to 24 hours. Do we want to bake such restriction into the protocol? If we use trial encryption, the issue between the sped of key rotation and the minimum maximum of a QUIC connection would be left to each server-side implementation, though you might end up being required to do more "mining" (i.e., find a connection ID that can survive _multiple_ generations of key rotations). Or, should we introduce a mechanism that allows a server to _enforce_ connection ID migration, considering the fact that the issue exists in both approaches? > > - Igor > > > > *From:* Martin Duke [mailto:martin.h.duke@gmail.com] > *Sent:* Wednesday, January 24, 2018 12:21 AM > *To:* Martin Thomson > *Cc:* IETF QUIC WG > *Subject:* Re: A better way to do conn id? > > > > Very well, replace 16 with whatever number you guys come up with. > > > > On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson > wrote: > > We have already concluded that if you want to do sane crypto, plus > some sort of key identification, then you need MORE than 16 octets > (though not much more). That makes things more complicated. ekr has > an outcome that he will write up. > > > On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke > wrote: > > Today's variable-length connection ID discussion made me realize some > > problems with the current architecture, while the new architecture > doesn't > > fix some of them and creates whole new ones. Issues: > > > > - The client desires unlinkability, but I suspect the market will > provide no > > incentives for servers to work very hard to be unlinkable. There were > > conflicting "layer 9" arguments that variable conn ID makes this proble= m > > worse or better. > > > > - 16 Bytes is more overhead than 8 bytes. > > > > - The severity of this remains to be seen, but variable length conn ids > will > > introduce more complexity in parsers and anything that utilizes the con= n > id > > (e.g. handshake key generation). It might make the invariants more > complex > > as well. The whole thing, frankly, makes my head hurt. > > > > I humbly suggest the following proposal might avoid or mitigate some of > > these problems: > > > > 1. Every connection has a long-lived Client-generated Connection ID > (CGCID) > > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and th= e > > SGCID is 16 bytes. > > > > 2. The CGCID is used to derive the handshake key. (unchanged from statu= s > > quo) > > > > 3. The initial packet uses the CGCID. All other handshake packets use > the > > SGCID. This is unchanged from the status quo. > > > > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT > packets > > sent by the server use the CGCID. This has two important properties: > > a) The server gets the 16 Bytes of entropy the load balancer > > needs > > b) The server->client direction, which in the usual case has > most > > of the data, has a lower-overhead CID. > > > > 5. The algorithm that generates SGCID MUST have different output given = a > > different CGCID. [We might strengthen this language further: you wouldn= 't > > want to simply add the NEW_CONN_ID sequence number to the existing SGCI= D, > > for instance]. > > > > 6. In advance of migration, the client sends a NEW_CONN_ID frame to > provide > > a new CGCID (possibly omitting the stateless reset token). The server > MUST > > respond with a NEW_CONN_ID that provides a new SGCID derived from the n= ew > > CGCID. All packets on the new path use these CIDs. > > > > If people like this, I can generate a PR. I am very open to various > tweaks > > to the general approach as well. I wanted to get this out there before > the > > variable-length CID team gets deep in the weeds. > > > > Martin Duke > > > > > > > --=20 Kazuho Oku --0000000000001cfa620563865df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    2018-01-24 16:34 GMT+11:00 Lubashev, Igor <ilubashe@akamai.com&g= t;:

    The two alternatives to allow for key rotation to = =E2=80=9Cavoid=E2=80=9D going over 16 octets are:

    =C2=A0

    1. (Victor voiced this today) Steal a code point from the packet type:= have 2 bits that represent:

    0-byte connection id;=

    8-byte connection id;=

    16-byte connection id (k= ey a);

    16-byte connection id (k= ey b)

    =C2=A0

    1. =E2=80=9CTrial Encryption=E2=80=9D : Steal a bit from your 128 bit = connection ID

    Your bit 0 of your = Connection ID will represent the key used for encryption.
    Since you have entropy in your Connection ID, keep generating new entropy a= nd encrypting, until bit 0 comes out just the way you want it.=C2=A0 On ave= rage, you will do 0.75 extra encryption operations.


    Thank you for summarizing the two approaches.

    What I am bit afraid of using the bits in the packet t= ype is that the approach hardcodes the relation between the frequency of ke= y rotation and the maximum lifetime of a QUIC connection.

    Consider the case where you want to switch from key A to key B. Cor= rect me if I am wrong, but IIUC there is no way for a server to enforce the= client to switch to a new connection ID. Therefore, the server will be enf= orced to shutdown all the connections using the IDs generated by using key = A before the key gets retired.

    For example, if you= plan to do the rollover from key A to key B in 24 hours, the minimum maxim= um of the lifetime of a connection will be restricted to 24 hours.

    Do we want to bake such restriction into the protocol?

    If we use trial encryption, the issue between the spe= d of key rotation and the minimum maximum of a QUIC connection would be lef= t to each server-side implementation, though you might end up being require= d to do more "mining" (i.e., find a connection ID that can surviv= e _multiple_ generations of key rotations).

    Or, sh= ould we introduce a mechanism that allows a server to _enforce_ connection = ID migration, considering the fact that the issue exists in both approaches= ?


    <= div class=3D"gmail-m_598407786438555612WordSection1">

    =C2=A0

    • Igor

    =C2=A0

    From: Martin Duke [mailto:martin.h.duke@gmail.com]=
    Sent: Wednesday, January 24, 2018 12:21 AM
    To: Martin Thomson <martin.thomson@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: A better way to do conn id?

    =C2=A0

    Very well, replace 16 with whatever number you guys = come up with.

    =C2=A0

    On Wed, Jan 24, 2018 at 4:19 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

    We have already concluded that if you want to do san= e crypto, plus
    some sort of key identification, then you need MORE than 16 octets
    (though not much more).=C2=A0 That makes things more complicated.=C2=A0 ekr= has
    an outcome that he will write up.


    On Wed, Jan 24, 2018 at 4:08 PM, Martin Duke <martin.h.duke@gmail.com> wrote: > Today's variable-length connection ID discussion made me realize s= ome
    > problems with the current architecture, while the new architecture doe= sn't
    > fix some of them and creates whole new ones. Issues:
    >
    > - The client desires unlinkability, but I suspect the market will prov= ide no
    > incentives for servers to work very hard to be unlinkable. There were<= br> > conflicting "layer 9" arguments that variable conn ID makes = this problem
    > worse or better.
    >
    > - 16 Bytes is more overhead than 8 bytes.
    >
    > - The severity of this remains to be seen, but variable length conn id= s will
    > introduce more complexity in parsers and anything that utilizes the co= nn id
    > (e.g. handshake key generation). It might make the invariants more com= plex
    > as well. The whole thing, frankly, makes my head hurt.
    >
    > I humbly suggest the following proposal might avoid or mitigate some o= f
    > these problems:
    >
    > 1. Every connection has a long-lived Client-generated Connection ID (C= GCID)
    > and Server-generated Connection ID (SGCID). The CGCID is 8 bytes and t= he
    > SGCID is 16 bytes.
    >
    > 2. The CGCID is used to derive the handshake key. (unchanged from stat= us
    > quo)
    >
    > 3. The initial packet uses the CGCID.=C2=A0 All other handshake packet= s use the
    > SGCID. This is unchanged from the status quo.
    >
    > 4. All 1-RTT packets by sent by the client use the SGCID. All 1-RTT pa= ckets
    > sent by the server use the CGCID. This has two important properties: >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a) The server gets the 16 Byt= es of entropy the load balancer
    > needs
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 b) The server->client dire= ction, which in the usual case has most
    > of the data, has a lower-overhead CID.
    >
    > 5. The algorithm that generates SGCID MUST have different output given= a
    > different CGCID. [We might strengthen this language further: you would= n't
    > want to simply add the NEW_CONN_ID sequence number to the existing SGC= ID,
    > for instance].
    >
    > 6. In advance of migration, the client sends a NEW_CONN_ID frame to pr= ovide
    > a new CGCID (possibly omitting the stateless reset token). The server = MUST
    > respond with a NEW_CONN_ID that provides a new SGCID derived from the = new
    > CGCID. All packets on the new path use these CIDs.
    >
    > If people like this, I can generate a PR. I am very open to various tw= eaks
    > to the general approach as well. I wanted to get this out there before= the
    > variable-length CID team gets deep in the weeds.
    >
    > Martin Duke
    >
    >

    =C2=A0




    --
    Kazuho Oku
    --0000000000001cfa620563865df2-- From nobody Wed Jan 24 06:23:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427961243F6 for ; Wed, 24 Jan 2018 06:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ea74DMJHuH1a for ; Wed, 24 Jan 2018 06:23:15 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 690F512422F for ; Wed, 24 Jan 2018 06:23:15 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id z11so10672459qtm.3 for ; Wed, 24 Jan 2018 06:23:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=SkKkgsLltAsBqCkcqWb/F+HqYRpzeSEu0JCTgpvr8xQ=; b=BaiQ2tOtGycpvQzbbwwFtmoZ/AebfqDUiioK/uF2ydlUqExpb2Lh34/C8o0rJDgOMb qorrhUCJsJpGxyQpd/8b/vrPq1P+CqQaHyAnqMEZj5Avr6F7UjsDh8nqxcBE7oCEn1ct K57VBTFAswIFbk8gB2ORqzhoz8YeQRjZr1czVMkpAS7rxC8LmXiqOsQnxCSoZcISq5BX HH5D+Qf9nzk+NYvY6CAow2eSczXogpUVqfNpv1N1G1Tk3T+4C0vWHNBrBERCo25SSNJm gcN32XmhQeDAp0D00utWt3giqLBm4KoWVpDz7c8Sfkpl82rjiziAkvYb31DvI2GpNhhp dnTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=SkKkgsLltAsBqCkcqWb/F+HqYRpzeSEu0JCTgpvr8xQ=; b=i1jvkXs+w/ZArF383l4LJ2G1/WYOa3sKCYl7FiJOpesZ/NYUagfDWRHI0ZfnGnlXRi UtLL9xcA4SRehcsqw1obYMJiz9+3BaWbHywF9TW5fchN6lm02tvCmfzAzKVviXbRxf6j 9nMcLhnDhdi7ZVnO9mtUgQu731OnvZsDwfMwsAoSYiH+de1LToZ0EdHq8XCCqtw9PIEd zANg5Ag8uLyQwsGiWvFup0HRDy8Hnw7BAYwAFmCLIV5AUMhe5MU3SRBlgzvpWEnVvtID Gy8DWXG4UpOORstHmvacqbgiC/azB+7DmUIrOiI+N7Ys6Ni0qFVbWGvRainl5OEZYaFL sOlA== X-Gm-Message-State: AKwxytc4C/iFN9QYRdv+LYIMBqZJqcS5U8prbBESj6kjJ/XkdDSLqGqD IEwQhKDUnA91yLkvjz0c34yNKA== X-Google-Smtp-Source: AH8x224GTNVWvfI5Md8DOce2oEhjbXhV5mUkHG5tBZDLw39QWQL9MSE4mol360RF9ZOwLku99f/Txg== X-Received: by 10.200.34.194 with SMTP id g2mr9588999qta.302.1516803794564; Wed, 24 Jan 2018 06:23:14 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id b75sm317879qkb.73.2018.01.24.06.23.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 06:23:14 -0800 (PST) Date: Wed, 24 Jan 2018 09:23:09 -0500 From: Dmitri Tikhonov To: Mike Bishop Cc: Martin Thomson , IETF QUIC WG , Spencer Dawkins at IETF Subject: Re: So how critical is header compression? Message-ID: <20180124142308.GA7729@ubuntu-dmitri> Mail-Followup-To: Mike Bishop , Martin Thomson , IETF QUIC WG , Spencer Dawkins at IETF References: <20180123063052.GA25014@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 14:23:17 -0000 On Tue, Jan 23, 2018 at 11:14:50AM +0000, Mike Bishop wrote: > I thought the last one was pretty clearly answered as well: I do not believe this question was explicitly stated in this form nor considered by itself. The notes do not capture any discussion regarding this issue. > The transport doesn't trust that the application will read. If HTTP > fails to read in certain cases, that's exactly what flow control is for. I am talking about the effect, not the cause. The implication of this in combination with moving table updates to a single control stream is that the current header compression proposal, QCRAM-04, is just a variant of HPACK/GQUIC with the same set of problems. I will expand on this in a reply to the recent QCRAM email thread. - Dmitri. From nobody Wed Jan 24 06:33:00 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1151267BB for ; Wed, 24 Jan 2018 06:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 ixcqrB_7cMVY for ; Wed, 24 Jan 2018 06:32:50 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E29D124E15 for ; Wed, 24 Jan 2018 06:32:50 -0800 (PST) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id E9F5C101302 for ; Wed, 24 Jan 2018 15:32:48 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id D052C6008B for ; Wed, 24 Jan 2018 15:32:48 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Wed, 24 Jan 2018 15:32:48 +0100 Message-ID: <32328_1516804368_5A689910_32328_63_1_5A689913.8060108@orange.com> Date: Wed, 24 Jan 2018 15:32:51 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Subject: Re: Re: what was yesterday's packet number decision? References: <2c53f35a0cc440cb98bfe1a99cd4ee72@usma1ex-dag1mb5.msg.corp.akamai.com> <7cd23614-338e-fabb-24e5-3f8902bf0368@huitema.net> <0E3192F8-F2B2-42BD-947D-DCD9F359139A@trammell.ch> In-Reply-To: <0E3192F8-F2B2-42BD-947D-DCD9F359139A@trammell.ch> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.2] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 14:32:52 -0000 On -10/01/-28163 20:59, Brian Trammell (IETF) wrote: > hi Christian, all, > > >> We may want to have a discussion about exposing a 1, 2 or 3 bit sequence >> number in clear text, so intermediaries can observe it and deduce issues >> like losses or reordering. But we should be deliberate about that, and >> follow pretty much the same process as for reserving the spin bit. > > > I will note that if we varint the packet number, or if encryption makes it fixed-length (either of which would > appear to be true), we can claw back the type bits in the short header, and can stick the subsequence number there, > i.e.: > > +-+-+-+-+-+-+-+-+ > |0|C|K|S| SSN | > +-+-+-+-+-+-+-+-+ > > unless we want to grab one of those bits for some other purpose. I suspect that four bits of subsequence are more > useful than three bits, but that's just intuition; data about common loss and reordering patterns seen in large HTTP > installations would be useful here. I confirm: four bits are more useful than three. But, as is obvious from tackling loss and reordering daily, it is still insufficient: it sure allows detection of loss, in a yes-or-no fashion (with a probability ~ 15/16), but gives very few quantitative hints (the size or pattern of loss). For example, this makes it hard to distinguish large contiguous losses (due to a tail drop on a per-flow queue) from sparser ones (due to losses on a shared resource like a backbone router interface). -Alex _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Wed Jan 24 06:53:02 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC78124D6C for ; Wed, 24 Jan 2018 06:53:00 -0800 (PST) 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 wKrUxgFgYpIn for ; Wed, 24 Jan 2018 06:52:57 -0800 (PST) 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 6CA76126C19 for ; Wed, 24 Jan 2018 06:52:57 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id m19so1563921ywh.12 for ; Wed, 24 Jan 2018 06:52:57 -0800 (PST) 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=qBDgvT+9tV7+v/F4HHiUEN8p+ICjKKFEUtSaUDEhLg0=; b=NGB/mdPtHrOlyKeEpOgJS5JTvlSSgnHyOdCzgYvzOktmDs8riot9oIZvtLLwdxeyEG pNt8DH2UW/7ZtS2jcVx0GN7i/0XZupqbO+sDEhqTf4hG/jiu+ZlrFF4HD5WmB0Z9jaRF CugqP9hxgOLn2Br2m3PhRdVC+8/LJ8vnaYcnTLK/KBS9DAA1Xm9/yXDJmJELvM/KCjs2 2puCDopcxd7FoeaOQ0V6auxl6SCqbNv3C51rHjp0TD4iwoUggg/j6eJV8AsdzeD1xoYH knnPPqCw8Z/Hjqvd3oxKgmNlA9KECLWn3JMCWRNIUD7vWST89tJdTEGggi95ckr6r4xg p2qQ== 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=qBDgvT+9tV7+v/F4HHiUEN8p+ICjKKFEUtSaUDEhLg0=; b=N4pIPgpIfR6cLQu2zND6HqvwNGmsKvEYSN72db4YqYsbz25ZSc0204PsRHvwC903Ql 9mQcNfuulGzEBLTSMYsLfCEL6DY6lEJGjFR4eZy4YjqnSMwDULbsg2ulEJFsICleyu8Y G1J0zquQD5WxKSgZK6sVt4Jdxz9bdZ/9kUlc7q5eh6yM5NboIyzRnkVkI0Pehll8eOVX u1lWqmk2vyKltHgq4xe7Xj0Tp+dbuprZxLR6ddXZLRkDS3+afc07J0waSXYFjs2I3UGE SEEnMWYQkUXJ0ZcOnV+Cg4PtyWo5P+elamtyl93bIzsECu1IZtY3Kz9OV2Jzuxn5s53U no9Q== X-Gm-Message-State: AKwxytekQjpUzlSVIlXKRA5uZh3EaF6j/mNZL7Vxt3i48qS7if6jtBug KRiWr3h++IxpE/m4uEJB4j5Wi2VJcbKj3Nxo+Jo= X-Google-Smtp-Source: AH8x2275YLK8lnDaGmFyKTcgBXEu3+Vx7EBGAT0sQzNt5rtReDZYzkDm63VNd1h4evnDGUbVuUU8Jx5w5IYtzbIUVlI= X-Received: by 10.129.216.11 with SMTP id d11mr5785307ywj.407.1516805576284; Wed, 24 Jan 2018 06:52:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.20.4 with HTTP; Wed, 24 Jan 2018 06:52:55 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 24 Jan 2018 08:52:55 -0600 Message-ID: Subject: Re: ECN in QUIC To: Ingemar Johansson S Cc: QUIC WG Content-Type: multipart/alternative; boundary="089e08222f74915fb8056386d12a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 14:53:00 -0000 --089e08222f74915fb8056386d12a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, On Wed, Jan 24, 2018 at 2:01 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > > > A few impressions on the ECN in QUIC discussions. The audio was so-so, > frequent interruptions and LARGE differences in audio level + badly > implemented ears =F0=9F=98=8A, so sometimes I missed the details and poss= ibly kick > in open doors. > > > > * Feedback format. I understand that the proposed proposal based on > ECT(0), ECT(1) and CE counters does not play well with connection > migration. I believe, but I am not 100% sure that I understand the proble= m. > I understand that there are two concerns (perhaps more?): > > 1. Counters are reset, this means that there will be a potentially very > large (negative?) difference in CE marked packets. I believe that this ca= n > be detected as false congestion signal and ignored by the congestion sign= al. > > 2. Difficulties to detect ECN bleaching. It is tricky to understand if > packets along the new path are bleached based on the ECT counters. This c= an > be a more complicated case. > > In any case it was suggested to indicate the ECN bits for the packets in > the ACK frame. Such a format was actually outlined in earlier proposal (s= ee > page 6, Figure 3 in https://tools.ietf.org/html/ > draft-johansson-quic-ecn-01 ). It is Ok with me to change to a format > similar to this if the group prefers that. > > * Congestion control for ECT(1), L4S : My feeling is that it is for now O= K > to leave this as future work. That does not mean that there are absolutel= y > no ideas on how to implement this, for short RTT environments DCTCP style > congestion control is quite OK. Furthermore I and recently worked on a L4= S > congestion control that is based on BBR, the results look quite promising > and the changes to the BBR algorithm are quite minimal. I am willing to > present this at ICCRG in London if there is any interest in this. > We deprecated existing use of ECT(1) to allow experiments, which is great, but (as AD) I'd be more comfortable if QUIC didn't slam some current idea about L4S into QUICv1, which is targeted as a proposed standard. So, if the working group is OK leaving that as future work, I'd be thrilled. I'm always willing to be convinced that I'm wrong, of course. Many of you have already had the pleasure of convincing me I was wrong on other topics :D ... Spencer * ECN in QUIC v1 or later : I would very much prefer that ECN support goes > into v1. On the technical side it makes it possible to experiment with EC= N, > potentially on a larger scale. On the political side it helps to make the > =E2=80=9Cchicken and egg=E2=80=9D problem become history. > > > > /Ingemar > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Ingemar Johansson M.Sc. > > Master Researcher > > > > Ericsson Research > > Network Protocols & E2E Performance > > Labratoriegr=C3=A4nd 11 > > 971 28, Lule=C3=A5, Sweden > > Phone +46-1071 43042 > > SMS/MMS +46-73 078 3289 <+46%2073%20078%2032%2089> > > ingemar.s.johansson@ericsson.com > > www.ericsson.com > > > > The world is full of magical things patiently > > waiting for our wits to grow sharper > > Bertrand Russell > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > --089e08222f74915fb8056386d12a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    FWIW,

    On Wed, Jan 24, 2018 at 2:01 AM, Ingemar Johansson S <= ingemar.s.johansson@ericsson.com> wrote:

    Hi

    =C2=A0

    A few impressions on the ECN in QUIC discussions. Th= e audio was so-so, frequent interruptions and LARGE differences in audio le= vel + badly implemented ears =F0=9F=98= =8A, so sometimes I missed the details and possibly kick in open doo= rs.

    =C2=A0

    * =C2=A0Feedback format. I understand that the propo= sed proposal based on ECT(0), ECT(1) and CE counters does not play well wit= h connection migration. I believe, but I am not 100% sure that I understand= the problem. I understand that there are two concerns (perhaps more?):

    =C2=A0 1. Counters are reset, this means that there = will be a potentially very large (negative?) difference in CE marked packet= s. I believe that this can be detected as false congestion signal and ignor= ed by the congestion signal.

    =C2=A0 2. Difficulties to detect ECN bleaching. It i= s tricky to understand if packets along the new path are bleached based on = the ECT counters. This can be a more complicated case.

    In any case it was suggested to indicate the ECN bit= s for the packets in the ACK frame. Such a format was actually outlined in = earlier proposal (see page 6, Figure 3 in https://tools.ietf.org/html/draft-johansson-quic-ecn-01 ). It is Ok with me to change to a format similar to this if the group pr= efers that.


    * Congestion control for ECT(1), L4S : My feeling is= that it is for now OK to leave this as future work. That does not mean tha= t there are absolutely no ideas on how to implement this, for short RTT env= ironments DCTCP style congestion control is quite OK. Furthermore I and recently worked on a L4S congestion control= that is based on BBR, the results look quite promising and the changes to = the BBR algorithm are quite minimal. I am willing to present this at ICCRG = in London if there is any interest in this.




    * ECN in QUIC v1 or later : I would very much prefer= that ECN support goes into v1. On the technical side it makes it possible = to experiment with ECN, potentially on a larger scale. On the political sid= e it helps to make the =E2=80=9Cchicken and egg=E2=80=9D problem become history.

    =C2=A0

    /Ingemar

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

    Ingemar Johansson=C2=A0= M.Sc.

    Master Researcher

    =C2=A0

    Ericsson Research

    Network Protocols &= E2E Performance

    Labratoriegr=C3=A4nd 11=

    971 28, Lule=C3=A5, Swe= den

    Phone +46-1071 43042=

    SMS/MMS +46-73 0= 78 3289

    i= ngemar.s.johansson@ericsson.com

    www.ericsson.com<= /span>

    <= /u>=C2=A0

    The world is full of magical things patiently

    =C2=A0=C2=A0=C2=A0=C2=A0waiting for our wits to grow sharper=

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Bertrand Russell
    =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=

    =C2=A0


    --089e08222f74915fb8056386d12a-- From nobody Wed Jan 24 07:27:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F5A126C22 for ; Wed, 24 Jan 2018 07:27:44 -0800 (PST) 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 nqIzQjfE9pLy for ; Wed, 24 Jan 2018 07:27:43 -0800 (PST) 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 E6E51126C0F for ; Wed, 24 Jan 2018 07:27:42 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id 23so3320088pfp.3 for ; Wed, 24 Jan 2018 07:27:42 -0800 (PST) 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=ttcXi75/Re87sfIMYQsufi6wP0j44cCKtRgr1uu+62s=; b=ny+xIMEzwZxBrDWvmnk0TrQWwY/fZl97YeUOOz/W9Ly8MHqw04DEZddulKbgf5dUJm rFeDQrnCKPIFvrYCcHBUETHCH0MiqVRURjRYf4jeT+W1LcDCA4HLRBG88DELIMYv2dqR +zSp6KICNF4mVW88578Fwem2H+BmwxcIZKWWeWdE81mlJB9da35l65mIXXsam0rJ0y2k O2ew7NNArBbBzWZsFX5Fm0bCUgYEZYhVYanNrWsWAOIxHaiPfvnjd/J3q2TyfPCGS6+V kRm0M5Q5HY4D2icXp1ulXV71/2QBtUcE9frx2Yh4IuK/U7liJlp6qfRyrQvy5tEIFTKD w/zA== 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=ttcXi75/Re87sfIMYQsufi6wP0j44cCKtRgr1uu+62s=; b=NWefqznvbDBGdlZpFKKu7AMZiiQzlcsheNo//ivxFBhKPodv3V6KoyxJJd/QZAlHEw j2XWRKolxD+76ufpzOirGKy0tQpSsZFxPzSa7xQr7QQVuqBkJwEnOAuIHFYz1o8zZBqJ a9RPwWQUbRSeKZ464aort5T9L1OUcIvew3eNtz6gdGxFzHHOgw2DZWKk/Zn0hXyQxDny S+OMRTuAsljB6V9Hl3GslWeESL7NxG5WIYimbl93QzN/YJR5kUJLKASAWAhYVgfK8o+w GCI/SU0BkBWwsekyOY8kMhSJT6i0JSj6yRS8DZJgPOyJnCEudu/g6TrQxPrPsx5qJRtn rc4A== X-Gm-Message-State: AKwxytfR09IgK+jN+dS2lCeJ5zRW93JJmubG8i2SrpkKJH1ht6LYorLC s/IHK5i33nmLuYnVvZtJtCE5aJ6/M1AHMdUr7V8= X-Google-Smtp-Source: AH8x226LzuwaV88kdELj16kwMImhnTvbxxvy24BY3l4e18J1sqUzNZ4LAsy0Ui/jkMwpShq6Ge8rvYu2Y4wXWuQ0orQ= X-Received: by 2002:a17:902:47c2:: with SMTP id d2-v6mr6299570plh.222.1516807662376; Wed, 24 Jan 2018 07:27:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 24 Jan 2018 07:27:41 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Thu, 25 Jan 2018 02:27:41 +1100 Message-ID: Subject: Re: Updated QCRAM Draft To: Jana Iyengar Cc: Mike Bishop , IETF QUIC WG , "Charles 'Buck' Krasic" 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, 24 Jan 2018 15:27:45 -0000 2018-01-24 23:10 GMT+11:00 Jana Iyengar : > > The draft outlines what I think the room converged on, and it seems fairl= y straightforward -- thanks for the quick turnaround! > > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but I = believe the "Base Index" is basically what I think of as the "generation ID= " of the table. It reflects the number of table operations that have happen= ed... this is important when you have evictions, since just a reference to = the largest index is ambiguous if there have been evictions. Jana, thank you for the response. Please correct me if I am wrong, but the below is my understanding. Modifications to the HPACK state only happens on the Control Stream. So we do not need to rely on the index to determine how the state needs to be changed. For HEADERS frames sent over non-control streams, the only information that the decoder needs is the absolute indices of the header table, which can be encoded as largest_index (or whatever you call) plus the deltas. > > > I don't understand however how the largest index is "Base Index - Depends= ". I would've thought the largest index would simply be "Depends". What am = I missing? > > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku wrote: >> >> Buck, >> >> Thank you for the draft. >> >> I like the approach and I think that it is not difficult to implement. >> >> Reading the spec, the question I have is why you need the BLOCKING flag = and two variables (i.e. base index and depends). Can't each HEADERS frame a= lways hold just one offset (i.e. largest index that the frame refers to)? >> >> Maybe I am missing something. >> >> >> 2018-01-24 16:53 GMT+11:00 Mike Bishop : >>> >>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/d= raft-krasic-quic-qcram-04 -- please read before tomorrow=E2=80=99s meeting = so we can have a useful discussion. Thanks! >> >> >> >> >> -- >> Kazuho Oku > > --=20 Kazuho Oku From nobody Wed Jan 24 08:33:35 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC00126DD9 for ; Wed, 24 Jan 2018 08:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JlaMHcmqAJZX for ; Wed, 24 Jan 2018 08:33:30 -0800 (PST) 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 736D8126C26 for ; Wed, 24 Jan 2018 08:33:30 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OGX7fx006639; Wed, 24 Jan 2018 16:33:29 GMT 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=yFvjLPiLdJtlwKq1lvNGnaKvfeEPYSKP2LuQAviuGk0=; b=cBtRDBg4VBMCiQ7XGGH7YVSMuE3cG7PgAuEOvx/P4INUut9R+G7Jhc6iRdbv6MbGS7l2 OpdJV7awdgdxU8NsHKS6cwjlC91tSCv5D+7nRT5nbpfGq6VitW9Aj0i4HOzGTw9B2SAE K9+EfERehMw4Zfnjr7BpTCGkT69Xkr+G2wz6hC+cvWodt/7fz6jozFQi9ji2nmXLoWey 7FRA9cn915CC9t7RJ7jq+KFASo0XyKJohHVB7PirramB4R2IQh6hETd662IHF/EAkQKX iu6AruRFm/W6qh7QUSv64eQwjq9ugdPtPauVlZFUjcsb8h1uMQa8+FtNpyBAfraZ0hlC qg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2fkxa1xfxu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 16:33:28 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0OGURkL030337; Wed, 24 Jan 2018 11:33:28 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fm1yyp22w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 11:33:27 -0500 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; Wed, 24 Jan 2018 11:33:26 -0500 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, 24 Jan 2018 11:33:26 -0500 From: "Lubashev, Igor" To: Kazuho Oku CC: Martin Duke , Martin Thomson , IETF QUIC WG Subject: RE: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNFo0y0NS2zYe0mRyyv7KOC+e6OC0AuAgAAAc4D//60wMIAA6W4A///MjIA= Date: Wed, 24 Jan 2018 16:33:26 +0000 Message-ID: <8303973f738a41e88d834a32fe1692ee@usma1ex-dag1mb5.msg.corp.akamai.com> References: <6d7331bfb9e041e4a712f3edf99a3001@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.239] Content-Type: multipart/alternative; boundary="_000_8303973f738a41e88d834a32fe1692eeusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240219 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240220 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 16:33:34 -0000 --_000_8303973f738a41e88d834a32fe1692eeusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBwb2ludGluZyBvdXQgdGhlIGhhemFyZCBvZiBrZXkgcm90YXRpb24gZnJlcXVl bmN5IHZzIGNvbm5lY3Rpb24gZHVyYXRpb24uDQoNCg0KICAqICAgRG8gd2Ugd2FudCB0byBiYWtl IHN1Y2ggcmVzdHJpY3Rpb24gaW50byB0aGUgcHJvdG9jb2w/DQoNClRoZSBleHRyYSBjb2RlcG9p bnQgcHJvcG9zYWwgaXMgYSBoZWxwZnVsIGNvbW1vbi1jYXNlIG9wdGltaXphdGlvbiwgaW4gY2Fz ZSB0aGUgZnJlcXVlbmN5IG9mIGtleSByb3RhdGlvbiBpcyBzdWZmaWNpZW50bHkgbG93LiAgSXQg aXMgZGVmaW5pdGVseSBub3QgYSBzb2x1dGlvbiBmb3IgYWxsIHBvc3NpYmxlIHVzZSBjYXNlcy4g IEhvd2V2ZXIsIHRoZXJlIGlzIG5vdGhpbmcgdG8gcHJldmVudCBhIHNlcnZlciB3aXRoIG1vcmUg ZnJlcXVlbnQga2V5IHJvdGF0aW9ucyB0byBkbyBzb21ldGhpbmcgZWxzZS4gIFRoZSDigJxzb21l dGhpbmcgZWxzZeKAnSBjb3VsZCBiZToNCg0KICAxLiAgRW5jb2RlIGFkZGl0aW9uYWwgYml0KHMp IGluIHRoZSBjb25uZWN0aW9uIElEDQogIDIuICBCZWZvcmUgZXhwaXJpbmcga2V5IEEsIGNyZWF0 ZSBzdGF0ZSBvbiB0aGUgbG9hZCBiYWxhbmNlcnMgZm9yIHRoZSBmZXcgdmVyeSBsb25nLWxhc3Rp bmcgY29ubmVjdGlvbnMgc3RpbGwgdXNpbmcgQS4NCiAgMy4gIFNvbWV0aGluZyBlbHNlDQoNCg0K WW91ciBpZGVhIG9mIGhhdmluZyBhIG1lY2hhbmlzbSB0byBmb3JjZSBhIHN3aXRjaCB0byB0aGUg bmV3IGNvbm5lY3Rpb24gSUQgaXMgYW4gaW50ZXJlc3RpbmcgYW5kIHNlcGFyYXRlIGlkZWEuICBJ IGFtIGluIGZhdm9yIG9mIHRoaXMsIGFzIGl0IG1heSBnaXZlIHVzIG1vcmUgZmxleGliaWxpdHku ICBEb27igJl0IHNlZSB0aGF0IHRoaXMgbXVzdCBiZSBhIHYxIGZlYXR1cmUuDQoNCg0KICAqICAg SWdvcg0KDQoNCkZyb206IEthenVobyBPa3UgW21haWx0bzprYXp1aG9va3VAZ21haWwuY29tXQ0K U2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IDk6MjAgQU0NClRvOiBMdWJhc2hldiwg SWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT4NCkNjOiBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVr ZUBnbWFpbC5jb20+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IEEgYmV0dGVyIHdheSB0 byBkbyBjb25uIGlkPw0KDQoNCg0KMjAxOC0wMS0yNCAxNjozNCBHTVQrMTE6MDAgTHViYXNoZXYs IElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PjoN ClRoZSB0d28gYWx0ZXJuYXRpdmVzIHRvIGFsbG93IGZvciBrZXkgcm90YXRpb24gdG8g4oCcYXZv aWTigJ0gZ29pbmcgb3ZlciAxNiBvY3RldHMgYXJlOg0KDQoNCiAgMS4gIChWaWN0b3Igdm9pY2Vk IHRoaXMgdG9kYXkpIFN0ZWFsIGEgY29kZSBwb2ludCBmcm9tIHRoZSBwYWNrZXQgdHlwZTogaGF2 ZSAyIGJpdHMgdGhhdCByZXByZXNlbnQ6DQowLWJ5dGUgY29ubmVjdGlvbiBpZDsNCjgtYnl0ZSBj b25uZWN0aW9uIGlkOw0KMTYtYnl0ZSBjb25uZWN0aW9uIGlkIChrZXkgYSk7DQoxNi1ieXRlIGNv bm5lY3Rpb24gaWQgKGtleSBiKQ0KDQoNCiAgMS4gIOKAnFRyaWFsIEVuY3J5cHRpb27igJ0gOiBT dGVhbCBhIGJpdCBmcm9tIHlvdXIgMTI4IGJpdCBjb25uZWN0aW9uIElEDQoNCllvdXIgYml0IDAg b2YgeW91ciBDb25uZWN0aW9uIElEIHdpbGwgcmVwcmVzZW50IHRoZSBrZXkgdXNlZCBmb3IgZW5j cnlwdGlvbi4NClNpbmNlIHlvdSBoYXZlIGVudHJvcHkgaW4geW91ciBDb25uZWN0aW9uIElELCBr ZWVwIGdlbmVyYXRpbmcgbmV3IGVudHJvcHkgYW5kIGVuY3J5cHRpbmcsIHVudGlsIGJpdCAwIGNv bWVzIG91dCBqdXN0IHRoZSB3YXkgeW91IHdhbnQgaXQuICBPbiBhdmVyYWdlLCB5b3Ugd2lsbCBk byAwLjc1IGV4dHJhIGVuY3J5cHRpb24gb3BlcmF0aW9ucy4NCg0KVGhhbmsgeW91IGZvciBzdW1t YXJpemluZyB0aGUgdHdvIGFwcHJvYWNoZXMuDQoNCldoYXQgSSBhbSBiaXQgYWZyYWlkIG9mIHVz aW5nIHRoZSBiaXRzIGluIHRoZSBwYWNrZXQgdHlwZSBpcyB0aGF0IHRoZSBhcHByb2FjaCBoYXJk Y29kZXMgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIGZyZXF1ZW5jeSBvZiBrZXkgcm90YXRpb24g YW5kIHRoZSBtYXhpbXVtIGxpZmV0aW1lIG9mIGEgUVVJQyBjb25uZWN0aW9uLg0KDQpDb25zaWRl ciB0aGUgY2FzZSB3aGVyZSB5b3Ugd2FudCB0byBzd2l0Y2ggZnJvbSBrZXkgQSB0byBrZXkgQi4g Q29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgSUlVQyB0aGVyZSBpcyBubyB3YXkgZm9yIGEg c2VydmVyIHRvIGVuZm9yY2UgdGhlIGNsaWVudCB0byBzd2l0Y2ggdG8gYSBuZXcgY29ubmVjdGlv biBJRC4gVGhlcmVmb3JlLCB0aGUgc2VydmVyIHdpbGwgYmUgZW5mb3JjZWQgdG8gc2h1dGRvd24g YWxsIHRoZSBjb25uZWN0aW9ucyB1c2luZyB0aGUgSURzIGdlbmVyYXRlZCBieSB1c2luZyBrZXkg QSBiZWZvcmUgdGhlIGtleSBnZXRzIHJldGlyZWQuDQoNCkZvciBleGFtcGxlLCBpZiB5b3UgcGxh biB0byBkbyB0aGUgcm9sbG92ZXIgZnJvbSBrZXkgQSB0byBrZXkgQiBpbiAyNCBob3VycywgdGhl IG1pbmltdW0gbWF4aW11bSBvZiB0aGUgbGlmZXRpbWUgb2YgYSBjb25uZWN0aW9uIHdpbGwgYmUg cmVzdHJpY3RlZCB0byAyNCBob3Vycy4NCg0KRG8gd2Ugd2FudCB0byBiYWtlIHN1Y2ggcmVzdHJp Y3Rpb24gaW50byB0aGUgcHJvdG9jb2w/DQoNCklmIHdlIHVzZSB0cmlhbCBlbmNyeXB0aW9uLCB0 aGUgaXNzdWUgYmV0d2VlbiB0aGUgc3BlZCBvZiBrZXkgcm90YXRpb24gYW5kIHRoZSBtaW5pbXVt IG1heGltdW0gb2YgYSBRVUlDIGNvbm5lY3Rpb24gd291bGQgYmUgbGVmdCB0byBlYWNoIHNlcnZl ci1zaWRlIGltcGxlbWVudGF0aW9uLCB0aG91Z2ggeW91IG1pZ2h0IGVuZCB1cCBiZWluZyByZXF1 aXJlZCB0byBkbyBtb3JlICJtaW5pbmciIChpLmUuLCBmaW5kIGEgY29ubmVjdGlvbiBJRCB0aGF0 IGNhbiBzdXJ2aXZlIF9tdWx0aXBsZV8gZ2VuZXJhdGlvbnMgb2Yga2V5IHJvdGF0aW9ucykuDQoN Ck9yLCBzaG91bGQgd2UgaW50cm9kdWNlIGEgbWVjaGFuaXNtIHRoYXQgYWxsb3dzIGEgc2VydmVy IHRvIF9lbmZvcmNlXyBjb25uZWN0aW9uIElEIG1pZ3JhdGlvbiwgY29uc2lkZXJpbmcgdGhlIGZh Y3QgdGhhdCB0aGUgaXNzdWUgZXhpc3RzIGluIGJvdGggYXBwcm9hY2hlcz8NCg0KDQoNCg0KICAq ICAgSWdvcg0KDQpGcm9tOiBNYXJ0aW4gRHVrZSBbbWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwu Y29tPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEph bnVhcnkgMjQsIDIwMTggMTI6MjEgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21z b25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KQ2M6IElFVEYg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBS ZTogQSBiZXR0ZXIgd2F5IHRvIGRvIGNvbm4gaWQ/DQoNClZlcnkgd2VsbCwgcmVwbGFjZSAxNiB3 aXRoIHdoYXRldmVyIG51bWJlciB5b3UgZ3V5cyBjb21lIHVwIHdpdGguDQoNCk9uIFdlZCwgSmFu IDI0LCAyMDE4IGF0IDQ6MTkgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFp bC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KV2UgaGF2ZSBh bHJlYWR5IGNvbmNsdWRlZCB0aGF0IGlmIHlvdSB3YW50IHRvIGRvIHNhbmUgY3J5cHRvLCBwbHVz DQpzb21lIHNvcnQgb2Yga2V5IGlkZW50aWZpY2F0aW9uLCB0aGVuIHlvdSBuZWVkIE1PUkUgdGhh biAxNiBvY3RldHMNCih0aG91Z2ggbm90IG11Y2ggbW9yZSkuICBUaGF0IG1ha2VzIHRoaW5ncyBt b3JlIGNvbXBsaWNhdGVkLiAgZWtyIGhhcw0KYW4gb3V0Y29tZSB0aGF0IGhlIHdpbGwgd3JpdGUg dXAuDQoNCk9uIFdlZCwgSmFuIDI0LCAyMDE4IGF0IDQ6MDggUE0sIE1hcnRpbiBEdWtlIDxtYXJ0 aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+PiB3cm90 ZToNCj4gVG9kYXkncyB2YXJpYWJsZS1sZW5ndGggY29ubmVjdGlvbiBJRCBkaXNjdXNzaW9uIG1h ZGUgbWUgcmVhbGl6ZSBzb21lDQo+IHByb2JsZW1zIHdpdGggdGhlIGN1cnJlbnQgYXJjaGl0ZWN0 dXJlLCB3aGlsZSB0aGUgbmV3IGFyY2hpdGVjdHVyZSBkb2Vzbid0DQo+IGZpeCBzb21lIG9mIHRo ZW0gYW5kIGNyZWF0ZXMgd2hvbGUgbmV3IG9uZXMuIElzc3VlczoNCj4NCj4gLSBUaGUgY2xpZW50 IGRlc2lyZXMgdW5saW5rYWJpbGl0eSwgYnV0IEkgc3VzcGVjdCB0aGUgbWFya2V0IHdpbGwgcHJv dmlkZSBubw0KPiBpbmNlbnRpdmVzIGZvciBzZXJ2ZXJzIHRvIHdvcmsgdmVyeSBoYXJkIHRvIGJl IHVubGlua2FibGUuIFRoZXJlIHdlcmUNCj4gY29uZmxpY3RpbmcgImxheWVyIDkiIGFyZ3VtZW50 cyB0aGF0IHZhcmlhYmxlIGNvbm4gSUQgbWFrZXMgdGhpcyBwcm9ibGVtDQo+IHdvcnNlIG9yIGJl dHRlci4NCj4NCj4gLSAxNiBCeXRlcyBpcyBtb3JlIG92ZXJoZWFkIHRoYW4gOCBieXRlcy4NCj4N Cj4gLSBUaGUgc2V2ZXJpdHkgb2YgdGhpcyByZW1haW5zIHRvIGJlIHNlZW4sIGJ1dCB2YXJpYWJs ZSBsZW5ndGggY29ubiBpZHMgd2lsbA0KPiBpbnRyb2R1Y2UgbW9yZSBjb21wbGV4aXR5IGluIHBh cnNlcnMgYW5kIGFueXRoaW5nIHRoYXQgdXRpbGl6ZXMgdGhlIGNvbm4gaWQNCj4gKGUuZy4gaGFu ZHNoYWtlIGtleSBnZW5lcmF0aW9uKS4gSXQgbWlnaHQgbWFrZSB0aGUgaW52YXJpYW50cyBtb3Jl IGNvbXBsZXgNCj4gYXMgd2VsbC4gVGhlIHdob2xlIHRoaW5nLCBmcmFua2x5LCBtYWtlcyBteSBo ZWFkIGh1cnQuDQo+DQo+IEkgaHVtYmx5IHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBwcm9wb3NhbCBt aWdodCBhdm9pZCBvciBtaXRpZ2F0ZSBzb21lIG9mDQo+IHRoZXNlIHByb2JsZW1zOg0KPg0KPiAx LiBFdmVyeSBjb25uZWN0aW9uIGhhcyBhIGxvbmctbGl2ZWQgQ2xpZW50LWdlbmVyYXRlZCBDb25u ZWN0aW9uIElEIChDR0NJRCkNCj4gYW5kIFNlcnZlci1nZW5lcmF0ZWQgQ29ubmVjdGlvbiBJRCAo U0dDSUQpLiBUaGUgQ0dDSUQgaXMgOCBieXRlcyBhbmQgdGhlDQo+IFNHQ0lEIGlzIDE2IGJ5dGVz Lg0KPg0KPiAyLiBUaGUgQ0dDSUQgaXMgdXNlZCB0byBkZXJpdmUgdGhlIGhhbmRzaGFrZSBrZXku ICh1bmNoYW5nZWQgZnJvbSBzdGF0dXMNCj4gcXVvKQ0KPg0KPiAzLiBUaGUgaW5pdGlhbCBwYWNr ZXQgdXNlcyB0aGUgQ0dDSUQuICBBbGwgb3RoZXIgaGFuZHNoYWtlIHBhY2tldHMgdXNlIHRoZQ0K PiBTR0NJRC4gVGhpcyBpcyB1bmNoYW5nZWQgZnJvbSB0aGUgc3RhdHVzIHF1by4NCj4NCj4gNC4g QWxsIDEtUlRUIHBhY2tldHMgYnkgc2VudCBieSB0aGUgY2xpZW50IHVzZSB0aGUgU0dDSUQuIEFs bCAxLVJUVCBwYWNrZXRzDQo+IHNlbnQgYnkgdGhlIHNlcnZlciB1c2UgdGhlIENHQ0lELiBUaGlz IGhhcyB0d28gaW1wb3J0YW50IHByb3BlcnRpZXM6DQo+ICAgICAgICAgICAgYSkgVGhlIHNlcnZl ciBnZXRzIHRoZSAxNiBCeXRlcyBvZiBlbnRyb3B5IHRoZSBsb2FkIGJhbGFuY2VyDQo+IG5lZWRz DQo+ICAgICAgICAgICAgYikgVGhlIHNlcnZlci0+Y2xpZW50IGRpcmVjdGlvbiwgd2hpY2ggaW4g dGhlIHVzdWFsIGNhc2UgaGFzIG1vc3QNCj4gb2YgdGhlIGRhdGEsIGhhcyBhIGxvd2VyLW92ZXJo ZWFkIENJRC4NCj4NCj4gNS4gVGhlIGFsZ29yaXRobSB0aGF0IGdlbmVyYXRlcyBTR0NJRCBNVVNU IGhhdmUgZGlmZmVyZW50IG91dHB1dCBnaXZlbiBhDQo+IGRpZmZlcmVudCBDR0NJRC4gW1dlIG1p Z2h0IHN0cmVuZ3RoZW4gdGhpcyBsYW5ndWFnZSBmdXJ0aGVyOiB5b3Ugd291bGRuJ3QNCj4gd2Fu dCB0byBzaW1wbHkgYWRkIHRoZSBORVdfQ09OTl9JRCBzZXF1ZW5jZSBudW1iZXIgdG8gdGhlIGV4 aXN0aW5nIFNHQ0lELA0KPiBmb3IgaW5zdGFuY2VdLg0KPg0KPiA2LiBJbiBhZHZhbmNlIG9mIG1p Z3JhdGlvbiwgdGhlIGNsaWVudCBzZW5kcyBhIE5FV19DT05OX0lEIGZyYW1lIHRvIHByb3ZpZGUN Cj4gYSBuZXcgQ0dDSUQgKHBvc3NpYmx5IG9taXR0aW5nIHRoZSBzdGF0ZWxlc3MgcmVzZXQgdG9r ZW4pLiBUaGUgc2VydmVyIE1VU1QNCj4gcmVzcG9uZCB3aXRoIGEgTkVXX0NPTk5fSUQgdGhhdCBw cm92aWRlcyBhIG5ldyBTR0NJRCBkZXJpdmVkIGZyb20gdGhlIG5ldw0KPiBDR0NJRC4gQWxsIHBh Y2tldHMgb24gdGhlIG5ldyBwYXRoIHVzZSB0aGVzZSBDSURzLg0KPg0KPiBJZiBwZW9wbGUgbGlr ZSB0aGlzLCBJIGNhbiBnZW5lcmF0ZSBhIFBSLiBJIGFtIHZlcnkgb3BlbiB0byB2YXJpb3VzIHR3 ZWFrcw0KPiB0byB0aGUgZ2VuZXJhbCBhcHByb2FjaCBhcyB3ZWxsLiBJIHdhbnRlZCB0byBnZXQg dGhpcyBvdXQgdGhlcmUgYmVmb3JlIHRoZQ0KPiB2YXJpYWJsZS1sZW5ndGggQ0lEIHRlYW0gZ2V0 cyBkZWVwIGluIHRoZSB3ZWVkcy4NCj4NCj4gTWFydGluIER1a2UNCj4NCj4NCg0KDQoNCg0KLS0N CkthenVobyBPa3UNCg== --_000_8303973f738a41e88d834a32fe1692eeusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnAuZ21haWwtbTU5ODQwNzc4NjQzODU1NTYxMm1zb2xpc3RwYXJhZ3JhcGgs IGxpLmdtYWlsLW01OTg0MDc3ODY0Mzg1NTU2MTJtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwt bTU5ODQwNzc4NjQzODU1NTYxMm1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6Z21h aWwtbV81OTg0MDc3ODY0Mzg1NTU2MTJtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA0ODg4NzE4Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxMDg4MzQ4OTkwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlk OjMxMjM3NTE1OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTE4Njg4MTc4OTAgLTIzNDk4ODM1MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjE2Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsN Cgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjg0ODgzMzQxMDsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTEyNTI4NzgxMjQ7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDoyOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDMNCgl7 bXNvLWxpc3QtaWQ6OTU1Njc2MTkxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotNDYyOTM1MTI4IDY3Njk4NzEzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4 NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0 IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwz OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw0 DQoJe21zby1saXN0LWlkOjEyOTcyOTg0MTg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjEyNDEzOTQxMTQgMTM3NzM2MzczMCA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9 DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0OmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE2OTY3Mjgy NTk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDYxMTU3NTk2O30NCkBsaXN0IGw1OmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgcG9p bnRpbmcgb3V0IHRoZSBoYXphcmQgb2Yga2V5IHJvdGF0aW9uIGZyZXF1ZW5jeSB2cyBjb25uZWN0 aW9uIGR1cmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28t bGlzdDpsMSBsZXZlbDEgbGZvNCI+RG8gd2Ugd2FudCB0byBiYWtlIHN1Y2ggcmVzdHJpY3Rpb24g aW50byB0aGUgcHJvdG9jb2w/PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBleHRy YSBjb2RlcG9pbnQgcHJvcG9zYWwgaXMgYSBoZWxwZnVsIGNvbW1vbi1jYXNlIG9wdGltaXphdGlv biwgaW4gY2FzZSB0aGUgZnJlcXVlbmN5IG9mIGtleSByb3RhdGlvbiBpcyBzdWZmaWNpZW50bHkg bG93LiZuYnNwOyBJdCBpcyBkZWZpbml0ZWx5IG5vdCBhIHNvbHV0aW9uIGZvciBhbGwgcG9zc2li bGUgdXNlIGNhc2VzLiAmbmJzcDtIb3dldmVyLCB0aGVyZSBpcyBub3RoaW5nIHRvIHByZXZlbnQg YSBzZXJ2ZXIgd2l0aA0KIG1vcmUgZnJlcXVlbnQga2V5IHJvdGF0aW9ucyB0byBkbyBzb21ldGhp bmcgZWxzZS4mbmJzcDsgVGhlIOKAnHNvbWV0aGluZyBlbHNl4oCdIGNvdWxkIGJlOjxvOnA+PC9v OnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0K PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwzIGxldmVsMSBsZm81Ij5FbmNvZGUgYWRkaXRpb25hbCBiaXQocykgaW4gdGhlIGNvbm5l Y3Rpb24gSUQ8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxldmVsMSBsZm81Ij5CZWZvcmUgZXhwaXJp bmcga2V5IEEsIGNyZWF0ZSBzdGF0ZSBvbiB0aGUgbG9hZCBiYWxhbmNlcnMgZm9yIHRoZSBmZXcg dmVyeSBsb25nLWxhc3RpbmcgY29ubmVjdGlvbnMgc3RpbGwgdXNpbmcgQS48bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwzIGxldmVsMSBsZm81Ij5Tb21ldGhpbmcgZWxzZTxvOnA+PC9vOnA+PC9saT48L29s Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv dXIgaWRlYSBvZiBoYXZpbmcgYSBtZWNoYW5pc20gdG8gZm9yY2UgYSBzd2l0Y2ggdG8gdGhlIG5l dyBjb25uZWN0aW9uIElEIGlzIGFuIGludGVyZXN0aW5nIGFuZCBzZXBhcmF0ZSBpZGVhLiZuYnNw OyBJIGFtIGluIGZhdm9yIG9mIHRoaXMsIGFzIGl0IG1heSBnaXZlIHVzIG1vcmUgZmxleGliaWxp dHkuJm5ic3A7IERvbuKAmXQgc2VlIHRoYXQgdGhpcyBtdXN0IGJlIGEgdjEgZmVhdHVyZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxm bzYiPklnb3I8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gS2F6dWhvIE9rdSBbbWFpbHRv OmthenVob29rdUBnbWFpbC5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEphbnVh cnkgMjQsIDIwMTggOToyMCBBTTxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3IgJmx0O2ls dWJhc2hlQGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gRHVrZSAmbHQ7bWFy dGluLmguZHVrZUBnbWFpbC5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21z b25AZ21haWwuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogQSBiZXR0ZXIgd2F5IHRvIGRvIGNvbm4gaWQ/PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4yMDE4LTAxLTI0IDE2OjM0IEdNVCYjNDM7MTE6MDAgTHViYXNoZXYsIElnb3Ig Jmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgdHdvIGFsdGVybmF0aXZl cyB0byBhbGxvdyBmb3Iga2V5IHJvdGF0aW9uIHRvIOKAnGF2b2lk4oCdIGdvaW5nIG92ZXIgMTYg b2N0ZXRzIGFyZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQooVmljdG9yIHZvaWNlZCB0aGlzIHRv ZGF5KSBTdGVhbCBhIGNvZGUgcG9pbnQgZnJvbSB0aGUgcGFja2V0IHR5cGU6IGhhdmUgMiBiaXRz IHRoYXQgcmVwcmVzZW50OjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KMC1ieXRlIGNvbm5lY3Rpb24gaWQ7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo4LWJ5dGUgY29u bmVjdGlvbiBpZDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDouNWluIj4NCjE2LWJ5dGUgY29ubmVjdGlvbiBpZCAoa2V5IGEpOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KMTYtYnl0ZSBjb25u ZWN0aW9uIGlkIChrZXkgYik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMiI+DQrigJxUcmlhbCBFbmNyeXB0 aW9u4oCdIDogU3RlYWwgYSBiaXQgZnJvbSB5b3VyIDEyOCBiaXQgY29ubmVjdGlvbiBJRDxvOnA+ PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9ImdtYWlsLW01OTg0MDc3ODY0Mzg1NTU2MTJtc29s aXN0cGFyYWdyYXBoIj5Zb3VyIGJpdCAwIG9mIHlvdXIgQ29ubmVjdGlvbiBJRCB3aWxsIHJlcHJl c2VudCB0aGUga2V5IHVzZWQgZm9yIGVuY3J5cHRpb24uPGJyPg0KU2luY2UgeW91IGhhdmUgZW50 cm9weSBpbiB5b3VyIENvbm5lY3Rpb24gSUQsIGtlZXAgZ2VuZXJhdGluZyBuZXcgZW50cm9weSBh bmQgZW5jcnlwdGluZywgdW50aWwgYml0IDAgY29tZXMgb3V0IGp1c3QgdGhlIHdheSB5b3Ugd2Fu dCBpdC4mbmJzcDsgT24gYXZlcmFnZSwgeW91IHdpbGwgZG8gMC43NSBleHRyYSBlbmNyeXB0aW9u IG9wZXJhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmsgeW91IGZvciBzdW1tYXJpemlu ZyB0aGUgdHdvIGFwcHJvYWNoZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgSSBhbSBiaXQgYWZyYWlkIG9mIHVzaW5nIHRoZSBiaXRz IGluIHRoZSBwYWNrZXQgdHlwZSBpcyB0aGF0IHRoZSBhcHByb2FjaCBoYXJkY29kZXMgdGhlIHJl bGF0aW9uIGJldHdlZW4gdGhlIGZyZXF1ZW5jeSBvZiBrZXkgcm90YXRpb24gYW5kIHRoZSBtYXhp bXVtIGxpZmV0aW1lIG9mIGEgUVVJQyBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zaWRlciB0aGUgY2FzZSB3aGVyZSB5 b3Ugd2FudCB0byBzd2l0Y2ggZnJvbSBrZXkgQSB0byBrZXkgQi4gQ29ycmVjdCBtZSBpZiBJIGFt IHdyb25nLCBidXQgSUlVQyB0aGVyZSBpcyBubyB3YXkgZm9yIGEgc2VydmVyIHRvIGVuZm9yY2Ug dGhlIGNsaWVudCB0byBzd2l0Y2ggdG8gYSBuZXcgY29ubmVjdGlvbiBJRC4gVGhlcmVmb3JlLCB0 aGUgc2VydmVyIHdpbGwgYmUgZW5mb3JjZWQgdG8gc2h1dGRvd24gYWxsDQogdGhlIGNvbm5lY3Rp b25zIHVzaW5nIHRoZSBJRHMgZ2VuZXJhdGVkIGJ5IHVzaW5nIGtleSBBIGJlZm9yZSB0aGUga2V5 IGdldHMgcmV0aXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGUsIGlmIHlvdSBwbGFuIHRvIGRvIHRoZSByb2xsb3ZlciBm cm9tIGtleSBBIHRvIGtleSBCIGluIDI0IGhvdXJzLCB0aGUgbWluaW11bSBtYXhpbXVtIG9mIHRo ZSBsaWZldGltZSBvZiBhIGNvbm5lY3Rpb24gd2lsbCBiZSByZXN0cmljdGVkIHRvIDI0IGhvdXJz LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5E byB3ZSB3YW50IHRvIGJha2Ugc3VjaCByZXN0cmljdGlvbiBpbnRvIHRoZSBwcm90b2NvbD88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2Ug dXNlIHRyaWFsIGVuY3J5cHRpb24sIHRoZSBpc3N1ZSBiZXR3ZWVuIHRoZSBzcGVkIG9mIGtleSBy b3RhdGlvbiBhbmQgdGhlIG1pbmltdW0gbWF4aW11bSBvZiBhIFFVSUMgY29ubmVjdGlvbiB3b3Vs ZCBiZSBsZWZ0IHRvIGVhY2ggc2VydmVyLXNpZGUgaW1wbGVtZW50YXRpb24sIHRob3VnaCB5b3Ug bWlnaHQgZW5kIHVwIGJlaW5nIHJlcXVpcmVkIHRvIGRvIG1vcmUgJnF1b3Q7bWluaW5nJnF1b3Q7 IChpLmUuLCBmaW5kDQogYSBjb25uZWN0aW9uIElEIHRoYXQgY2FuIHN1cnZpdmUgX211bHRpcGxl XyBnZW5lcmF0aW9ucyBvZiBrZXkgcm90YXRpb25zKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3IsIHNob3VsZCB3ZSBpbnRyb2R1Y2UgYSBt ZWNoYW5pc20gdGhhdCBhbGxvd3MgYSBzZXJ2ZXIgdG8gX2VuZm9yY2VfIGNvbm5lY3Rpb24gSUQg bWlncmF0aW9uLCBjb25zaWRlcmluZyB0aGUgZmFjdCB0aGF0IHRoZSBpc3N1ZSBleGlzdHMgaW4g Ym90aCBhcHByb2FjaGVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDUg bGV2ZWwxIGxmbzMiPg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+ RnJvbTo8L2I+IE1hcnRpbiBEdWtlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1 a2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNCwgMjAxOCAxMjoyMSBB TTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFp bC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJt YWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQSBiZXR0ZXIgd2F5IHRvIGRvIGNvbm4gaWQ/PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5WZXJ5IHdlbGws IHJlcGxhY2UgMTYgd2l0aCB3aGF0ZXZlciBudW1iZXIgeW91IGd1eXMgY29tZSB1cCB3aXRoLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwg SmFuIDI0LCAyMDE4IGF0IDQ6MTkgUE0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWls dG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21z b25AZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+V2UgaGF2ZSBhbHJlYWR5IGNvbmNsdWRlZCB0aGF0IGlmIHlvdSB3YW50IHRvIGRvIHNhbmUg Y3J5cHRvLCBwbHVzPGJyPg0Kc29tZSBzb3J0IG9mIGtleSBpZGVudGlmaWNhdGlvbiwgdGhlbiB5 b3UgbmVlZCBNT1JFIHRoYW4gMTYgb2N0ZXRzPGJyPg0KKHRob3VnaCBub3QgbXVjaCBtb3JlKS4m bmJzcDsgVGhhdCBtYWtlcyB0aGluZ3MgbW9yZSBjb21wbGljYXRlZC4mbmJzcDsgZWtyIGhhczxi cj4NCmFuIG91dGNvbWUgdGhhdCBoZSB3aWxsIHdyaXRlIHVwLjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCk9uIFdlZCwgSmFuIDI0LCAy MDE4IGF0IDQ6MDggUE0sIE1hcnRpbiBEdWtlICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLmgu ZHVrZUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgVG9kYXkncyB2YXJpYWJsZS1sZW5ndGggY29ubmVjdGlv biBJRCBkaXNjdXNzaW9uIG1hZGUgbWUgcmVhbGl6ZSBzb21lPGJyPg0KJmd0OyBwcm9ibGVtcyB3 aXRoIHRoZSBjdXJyZW50IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIG5ldyBhcmNoaXRlY3R1cmUg ZG9lc24ndDxicj4NCiZndDsgZml4IHNvbWUgb2YgdGhlbSBhbmQgY3JlYXRlcyB3aG9sZSBuZXcg b25lcy4gSXNzdWVzOjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gVGhlIGNsaWVudCBkZXNpcmVzIHVu bGlua2FiaWxpdHksIGJ1dCBJIHN1c3BlY3QgdGhlIG1hcmtldCB3aWxsIHByb3ZpZGUgbm88YnI+ DQomZ3Q7IGluY2VudGl2ZXMgZm9yIHNlcnZlcnMgdG8gd29yayB2ZXJ5IGhhcmQgdG8gYmUgdW5s aW5rYWJsZS4gVGhlcmUgd2VyZTxicj4NCiZndDsgY29uZmxpY3RpbmcgJnF1b3Q7bGF5ZXIgOSZx dW90OyBhcmd1bWVudHMgdGhhdCB2YXJpYWJsZSBjb25uIElEIG1ha2VzIHRoaXMgcHJvYmxlbTxi cj4NCiZndDsgd29yc2Ugb3IgYmV0dGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IC0gMTYgQnl0ZXMg aXMgbW9yZSBvdmVyaGVhZCB0aGFuIDggYnl0ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgLSBUaGUg c2V2ZXJpdHkgb2YgdGhpcyByZW1haW5zIHRvIGJlIHNlZW4sIGJ1dCB2YXJpYWJsZSBsZW5ndGgg Y29ubiBpZHMgd2lsbDxicj4NCiZndDsgaW50cm9kdWNlIG1vcmUgY29tcGxleGl0eSBpbiBwYXJz ZXJzIGFuZCBhbnl0aGluZyB0aGF0IHV0aWxpemVzIHRoZSBjb25uIGlkPGJyPg0KJmd0OyAoZS5n LiBoYW5kc2hha2Uga2V5IGdlbmVyYXRpb24pLiBJdCBtaWdodCBtYWtlIHRoZSBpbnZhcmlhbnRz IG1vcmUgY29tcGxleDxicj4NCiZndDsgYXMgd2VsbC4gVGhlIHdob2xlIHRoaW5nLCBmcmFua2x5 LCBtYWtlcyBteSBoZWFkIGh1cnQuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSBodW1ibHkgc3VnZ2Vz dCB0aGUgZm9sbG93aW5nIHByb3Bvc2FsIG1pZ2h0IGF2b2lkIG9yIG1pdGlnYXRlIHNvbWUgb2Y8 YnI+DQomZ3Q7IHRoZXNlIHByb2JsZW1zOjxicj4NCiZndDs8YnI+DQomZ3Q7IDEuIEV2ZXJ5IGNv bm5lY3Rpb24gaGFzIGEgbG9uZy1saXZlZCBDbGllbnQtZ2VuZXJhdGVkIENvbm5lY3Rpb24gSUQg KENHQ0lEKTxicj4NCiZndDsgYW5kIFNlcnZlci1nZW5lcmF0ZWQgQ29ubmVjdGlvbiBJRCAoU0dD SUQpLiBUaGUgQ0dDSUQgaXMgOCBieXRlcyBhbmQgdGhlPGJyPg0KJmd0OyBTR0NJRCBpcyAxNiBi eXRlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyAyLiBUaGUgQ0dDSUQgaXMgdXNlZCB0byBkZXJpdmUg dGhlIGhhbmRzaGFrZSBrZXkuICh1bmNoYW5nZWQgZnJvbSBzdGF0dXM8YnI+DQomZ3Q7IHF1byk8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAzLiBUaGUgaW5pdGlhbCBwYWNrZXQgdXNlcyB0aGUgQ0dDSUQu Jm5ic3A7IEFsbCBvdGhlciBoYW5kc2hha2UgcGFja2V0cyB1c2UgdGhlPGJyPg0KJmd0OyBTR0NJ RC4gVGhpcyBpcyB1bmNoYW5nZWQgZnJvbSB0aGUgc3RhdHVzIHF1by48YnI+DQomZ3Q7PGJyPg0K Jmd0OyA0LiBBbGwgMS1SVFQgcGFja2V0cyBieSBzZW50IGJ5IHRoZSBjbGllbnQgdXNlIHRoZSBT R0NJRC4gQWxsIDEtUlRUIHBhY2tldHM8YnI+DQomZ3Q7IHNlbnQgYnkgdGhlIHNlcnZlciB1c2Ug dGhlIENHQ0lELiBUaGlzIGhhcyB0d28gaW1wb3J0YW50IHByb3BlcnRpZXM6PGJyPg0KJmd0OyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGEpIFRoZSBzZXJ2ZXIgZ2V0 cyB0aGUgMTYgQnl0ZXMgb2YgZW50cm9weSB0aGUgbG9hZCBiYWxhbmNlcjxicj4NCiZndDsgbmVl ZHM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYikg VGhlIHNlcnZlci0mZ3Q7Y2xpZW50IGRpcmVjdGlvbiwgd2hpY2ggaW4gdGhlIHVzdWFsIGNhc2Ug aGFzIG1vc3Q8YnI+DQomZ3Q7IG9mIHRoZSBkYXRhLCBoYXMgYSBsb3dlci1vdmVyaGVhZCBDSUQu PGJyPg0KJmd0Ozxicj4NCiZndDsgNS4gVGhlIGFsZ29yaXRobSB0aGF0IGdlbmVyYXRlcyBTR0NJ RCBNVVNUIGhhdmUgZGlmZmVyZW50IG91dHB1dCBnaXZlbiBhPGJyPg0KJmd0OyBkaWZmZXJlbnQg Q0dDSUQuIFtXZSBtaWdodCBzdHJlbmd0aGVuIHRoaXMgbGFuZ3VhZ2UgZnVydGhlcjogeW91IHdv dWxkbid0PGJyPg0KJmd0OyB3YW50IHRvIHNpbXBseSBhZGQgdGhlIE5FV19DT05OX0lEIHNlcXVl bmNlIG51bWJlciB0byB0aGUgZXhpc3RpbmcgU0dDSUQsPGJyPg0KJmd0OyBmb3IgaW5zdGFuY2Vd Ljxicj4NCiZndDs8YnI+DQomZ3Q7IDYuIEluIGFkdmFuY2Ugb2YgbWlncmF0aW9uLCB0aGUgY2xp ZW50IHNlbmRzIGEgTkVXX0NPTk5fSUQgZnJhbWUgdG8gcHJvdmlkZTxicj4NCiZndDsgYSBuZXcg Q0dDSUQgKHBvc3NpYmx5IG9taXR0aW5nIHRoZSBzdGF0ZWxlc3MgcmVzZXQgdG9rZW4pLiBUaGUg c2VydmVyIE1VU1Q8YnI+DQomZ3Q7IHJlc3BvbmQgd2l0aCBhIE5FV19DT05OX0lEIHRoYXQgcHJv dmlkZXMgYSBuZXcgU0dDSUQgZGVyaXZlZCBmcm9tIHRoZSBuZXc8YnI+DQomZ3Q7IENHQ0lELiBB bGwgcGFja2V0cyBvbiB0aGUgbmV3IHBhdGggdXNlIHRoZXNlIENJRHMuPGJyPg0KJmd0Ozxicj4N CiZndDsgSWYgcGVvcGxlIGxpa2UgdGhpcywgSSBjYW4gZ2VuZXJhdGUgYSBQUi4gSSBhbSB2ZXJ5 IG9wZW4gdG8gdmFyaW91cyB0d2Vha3M8YnI+DQomZ3Q7IHRvIHRoZSBnZW5lcmFsIGFwcHJvYWNo IGFzIHdlbGwuIEkgd2FudGVkIHRvIGdldCB0aGlzIG91dCB0aGVyZSBiZWZvcmUgdGhlPGJyPg0K Jmd0OyB2YXJpYWJsZS1sZW5ndGggQ0lEIHRlYW0gZ2V0cyBkZWVwIGluIHRoZSB3ZWVkcy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBNYXJ0aW4gRHVrZTxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkthenVobyBPa3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8303973f738a41e88d834a32fe1692eeusma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 08:36:20 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E45D126D0C for ; Wed, 24 Jan 2018 08:36:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=armh.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 Sxbk36_vBsC4 for ; Wed, 24 Jan 2018 08:36:13 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20057.outbound.protection.outlook.com [40.107.2.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 770DA126C26 for ; Wed, 24 Jan 2018 08:36:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=43w7JuISTm9u3WlC03pxZPmLsYofpz3spieh53Kr8bo=; b=llAqpVWMer0NPVJjlIE/2B5orH9964I/uzlc7s2DaxUKxtDKOnXGXp9xWVtfTnrrvUsM90ycq0H5G66lzo2FMrqDizxbD5ykVqW2x0jRG7Uix9wcfScQWjcsx2aEi6EVT2XiwJJcrisRvV/zLwHq9p98CzuiiNlQxWpWUSGwynI= Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com (10.167.90.148) by AM4PR0801MB2707.eurprd08.prod.outlook.com (10.167.90.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 16:36:09 +0000 Received: from AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b863:80d:692b:e64b]) by AM4PR0801MB2706.eurprd08.prod.outlook.com ([fe80::b863:80d:692b:e64b%14]) with mapi id 15.20.0428.019; Wed, 24 Jan 2018 16:36:09 +0000 From: Hannes Tschofenig To: Martin Duke , IETF QUIC WG Subject: RE: A better way to do conn id? Thread-Topic: A better way to do conn id? Thread-Index: AQHTlNFoMLZkBBKfu0uRpO7W0psJBqODOH5Q Date: Wed, 24 Jan 2018 16:36:09 +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: [217.140.111.135] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM4PR0801MB2707; 7:HPs/r0S0zEbluVHkrn8XjUnwLHtl7/Mx6rb8snZ6wk/5oIBXsMkKNk7sIZMVYxgTpn7qBJ+11ENUbVkZf6/MZoZ+jfK+/0rs01vZxBPOuqjdQSOxP4vFIP80Yv7zuShimnsxWNhGXABHUhHE7lt/xCOSI2z0lnBj1XKmfVYZ8Fk1yi8Vb8tbj/pgF0M5XFislRzpM2Fs0ZCHuOJXa9lIVR4xqoqycuWFQVCvg8C3EsV7KEXfFO98X0VGH4qgtukR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8832d655-330e-442c-a7da-08d5634892ee x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(48565401081)(2017052603307)(7153060)(7193020); SRVR:AM4PR0801MB2707; x-ms-traffictypediagnostic: AM4PR0801MB2707: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231023)(2400081)(944501161)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:AM4PR0801MB2707; BCL:0; PCL:0; RULEID:; SRVR:AM4PR0801MB2707; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(366004)(376002)(396003)(39860400002)(40434004)(199004)(189003)(14454004)(106356001)(7736002)(6116002)(2950100002)(86362001)(790700001)(74316002)(25786009)(110136005)(2906002)(66066001)(53546011)(72206003)(316002)(39060400002)(3846002)(478600001)(9686003)(54896002)(6436002)(5250100002)(5890100001)(102836004)(6306002)(55016002)(6506007)(2900100001)(7696005)(68736007)(33656002)(97736004)(6346003)(9326002)(3660700001)(105586002)(5660300001)(81156014)(59450400001)(8936002)(81166006)(99286004)(76176011)(561944003)(6246003)(229853002)(26005)(53936002)(3280700002)(8676002)(43043002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR0801MB2707; H:AM4PR0801MB2706.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-microsoft-antispam-message-info: Z4QI379/jA0wUCQ5rAAiBTYB6SMUc/TiWE53sePE5sfMejo0afZ3SlGuujx6YoJdvzrAVobOqqOKgFs15N8SYg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM4PR0801MB270652B9DBDB5FBE93E9A6D2FAE20AM4PR0801MB2706_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8832d655-330e-442c-a7da-08d5634892ee X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 16:36:09.6389 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0801MB2707 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 16:36:19 -0000 --_000_AM4PR0801MB270652B9DBDB5FBE93E9A6D2FAE20AM4PR0801MB2706_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpZb3VyIGVudGlyZSBzdG9yeSBpcyBidWlsdCBvbiB0aGUgY2xhaW0gdGhh dCDigJx2YXJpYWJsZSBsZW5ndGggY29ubiBpZHMgd2lsbCBpbnRyb2R1Y2UgbW9yZSBjb21wbGV4 aXR5IGluIHBhcnNlcnPigJ0uDQoNCkhhdmluZyBpbXBsZW1lbnRlZCBwYXJzaW5nIG9mIHZhcmlh YmxlIGxlbmd0aCBmaWVsZHMgaW4gVExTIDEuMyBleHRlbnNpdmVseSBsYXN0IHllYXIgSSBoYXZl IHRvIHNheSB0aGF0IGl0IGlzIG5vdCBzdWNoIGEgYmlnIGRlYWwsIHBhcnRpY3VsYXJseSBjb21w YXJlZCB0byBhbGwgdGhlIGNvbXBsZXhpdHkgZm91bmQgZWxzZXdoZXJlICh3aGljaCBpcyBhbHNv IHRydWUgZm9yIFFVSUMpLg0KDQpJbiBlc3NlbmNlIHlvdSBhcmUgdGFsa2luZyBhYm91dCBhIGZl dyBsaW5lcyBvZiBjb2RlLiBZb3VyIHNvbHV0aW9uIHRoZW4gYWxzbyByZXF1aXJlcyBhZGRpdGlv bmFsIGxpbmVzIG9mIGNvZGUgZWxzZXdoZXJlLg0KDQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBEdWtl DQpTZW50OiAyMyBKYW51YXJ5IDIwMTggMjM6MDkNClRvOiBJRVRGIFFVSUMgV0cNClN1YmplY3Q6 IEEgYmV0dGVyIHdheSB0byBkbyBjb25uIGlkPw0KDQpUb2RheSdzIHZhcmlhYmxlLWxlbmd0aCBj b25uZWN0aW9uIElEIGRpc2N1c3Npb24gbWFkZSBtZSByZWFsaXplIHNvbWUgcHJvYmxlbXMgd2l0 aCB0aGUgY3VycmVudCBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBuZXcgYXJjaGl0ZWN0dXJlIGRv ZXNuJ3QgZml4IHNvbWUgb2YgdGhlbSBhbmQgY3JlYXRlcyB3aG9sZSBuZXcgb25lcy4gSXNzdWVz Og0KDQotIFRoZSBjbGllbnQgZGVzaXJlcyB1bmxpbmthYmlsaXR5LCBidXQgSSBzdXNwZWN0IHRo ZSBtYXJrZXQgd2lsbCBwcm92aWRlIG5vIGluY2VudGl2ZXMgZm9yIHNlcnZlcnMgdG8gd29yayB2 ZXJ5IGhhcmQgdG8gYmUgdW5saW5rYWJsZS4gVGhlcmUgd2VyZSBjb25mbGljdGluZyAibGF5ZXIg OSIgYXJndW1lbnRzIHRoYXQgdmFyaWFibGUgY29ubiBJRCBtYWtlcyB0aGlzIHByb2JsZW0gd29y c2Ugb3IgYmV0dGVyLg0KDQotIDE2IEJ5dGVzIGlzIG1vcmUgb3ZlcmhlYWQgdGhhbiA4IGJ5dGVz Lg0KDQotIFRoZSBzZXZlcml0eSBvZiB0aGlzIHJlbWFpbnMgdG8gYmUgc2VlbiwgYnV0IHZhcmlh YmxlIGxlbmd0aCBjb25uIGlkcyB3aWxsIGludHJvZHVjZSBtb3JlIGNvbXBsZXhpdHkgaW4gcGFy c2VycyBhbmQgYW55dGhpbmcgdGhhdCB1dGlsaXplcyB0aGUgY29ubiBpZCAoZS5nLiBoYW5kc2hh a2Uga2V5IGdlbmVyYXRpb24pLiBJdCBtaWdodCBtYWtlIHRoZSBpbnZhcmlhbnRzIG1vcmUgY29t cGxleCBhcyB3ZWxsLiBUaGUgd2hvbGUgdGhpbmcsIGZyYW5rbHksIG1ha2VzIG15IGhlYWQgaHVy dC4NCg0KSSBodW1ibHkgc3VnZ2VzdCB0aGUgZm9sbG93aW5nIHByb3Bvc2FsIG1pZ2h0IGF2b2lk IG9yIG1pdGlnYXRlIHNvbWUgb2YgdGhlc2UgcHJvYmxlbXM6DQoNCjEuIEV2ZXJ5IGNvbm5lY3Rp b24gaGFzIGEgbG9uZy1saXZlZCBDbGllbnQtZ2VuZXJhdGVkIENvbm5lY3Rpb24gSUQgKENHQ0lE KSBhbmQgU2VydmVyLWdlbmVyYXRlZCBDb25uZWN0aW9uIElEIChTR0NJRCkuIFRoZSBDR0NJRCBp cyA4IGJ5dGVzIGFuZCB0aGUgU0dDSUQgaXMgMTYgYnl0ZXMuDQoNCjIuIFRoZSBDR0NJRCBpcyB1 c2VkIHRvIGRlcml2ZSB0aGUgaGFuZHNoYWtlIGtleS4gKHVuY2hhbmdlZCBmcm9tIHN0YXR1cyBx dW8pDQoNCjMuIFRoZSBpbml0aWFsIHBhY2tldCB1c2VzIHRoZSBDR0NJRC4gIEFsbCBvdGhlciBo YW5kc2hha2UgcGFja2V0cyB1c2UgdGhlIFNHQ0lELiBUaGlzIGlzIHVuY2hhbmdlZCBmcm9tIHRo ZSBzdGF0dXMgcXVvLg0KDQo0LiBBbGwgMS1SVFQgcGFja2V0cyBieSBzZW50IGJ5IHRoZSBjbGll bnQgdXNlIHRoZSBTR0NJRC4gQWxsIDEtUlRUIHBhY2tldHMgc2VudCBieSB0aGUgc2VydmVyIHVz ZSB0aGUgQ0dDSUQuIFRoaXMgaGFzIHR3byBpbXBvcnRhbnQgcHJvcGVydGllczoNCiAgICAgICAg ICAgYSkgVGhlIHNlcnZlciBnZXRzIHRoZSAxNiBCeXRlcyBvZiBlbnRyb3B5IHRoZSBsb2FkIGJh bGFuY2VyIG5lZWRzDQogICAgICAgICAgIGIpIFRoZSBzZXJ2ZXItPmNsaWVudCBkaXJlY3Rpb24s IHdoaWNoIGluIHRoZSB1c3VhbCBjYXNlIGhhcyBtb3N0IG9mIHRoZSBkYXRhLCBoYXMgYSBsb3dl ci1vdmVyaGVhZCBDSUQuDQoNCjUuIFRoZSBhbGdvcml0aG0gdGhhdCBnZW5lcmF0ZXMgU0dDSUQg TVVTVCBoYXZlIGRpZmZlcmVudCBvdXRwdXQgZ2l2ZW4gYSBkaWZmZXJlbnQgQ0dDSUQuIFtXZSBt aWdodCBzdHJlbmd0aGVuIHRoaXMgbGFuZ3VhZ2UgZnVydGhlcjogeW91IHdvdWxkbid0IHdhbnQg dG8gc2ltcGx5IGFkZCB0aGUgTkVXX0NPTk5fSUQgc2VxdWVuY2UgbnVtYmVyIHRvIHRoZSBleGlz dGluZyBTR0NJRCwgZm9yIGluc3RhbmNlXS4NCg0KNi4gSW4gYWR2YW5jZSBvZiBtaWdyYXRpb24s IHRoZSBjbGllbnQgc2VuZHMgYSBORVdfQ09OTl9JRCBmcmFtZSB0byBwcm92aWRlIGEgbmV3IENH Q0lEIChwb3NzaWJseSBvbWl0dGluZyB0aGUgc3RhdGVsZXNzIHJlc2V0IHRva2VuKS4gVGhlIHNl cnZlciBNVVNUIHJlc3BvbmQgd2l0aCBhIE5FV19DT05OX0lEIHRoYXQgcHJvdmlkZXMgYSBuZXcg U0dDSUQgZGVyaXZlZCBmcm9tIHRoZSBuZXcgQ0dDSUQuIEFsbCBwYWNrZXRzIG9uIHRoZSBuZXcg cGF0aCB1c2UgdGhlc2UgQ0lEcy4NCg0KSWYgcGVvcGxlIGxpa2UgdGhpcywgSSBjYW4gZ2VuZXJh dGUgYSBQUi4gSSBhbSB2ZXJ5IG9wZW4gdG8gdmFyaW91cyB0d2Vha3MgdG8gdGhlIGdlbmVyYWwg YXBwcm9hY2ggYXMgd2VsbC4gSSB3YW50ZWQgdG8gZ2V0IHRoaXMgb3V0IHRoZXJlIGJlZm9yZSB0 aGUgdmFyaWFibGUtbGVuZ3RoIENJRCB0ZWFtIGdldHMgZGVlcCBpbiB0aGUgd2VlZHMuDQoNCk1h cnRpbiBEdWtlDQoNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1h aWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBw cml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29u dGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3Rv cmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM4PR0801MB270652B9DBDB5FBE93E9A6D2FAE20AM4PR0801MB2706_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIE1hcnRpbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WW91ciBlbnRpcmUg c3RvcnkgaXMgYnVpbHQgb24gdGhlIGNsYWltIHRoYXQg4oCcdmFyaWFibGUgbGVuZ3RoIGNvbm4g aWRzIHdpbGwgaW50cm9kdWNlIG1vcmUgY29tcGxleGl0eSBpbiBwYXJzZXJz4oCdLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IYXZpbmcgaW1wbGVtZW50ZWQgcGFyc2luZyBvZiB2YXJpYWJsZSBsZW5ndGggZmllbGRz IGluIFRMUyAxLjMgZXh0ZW5zaXZlbHkgbGFzdCB5ZWFyIEkgaGF2ZSB0byBzYXkgdGhhdCBpdCBp cyBub3Qgc3VjaCBhIGJpZyBkZWFsLCBwYXJ0aWN1bGFybHkgY29tcGFyZWQgdG8NCiBhbGwgdGhl IGNvbXBsZXhpdHkgZm91bmQgZWxzZXdoZXJlICh3aGljaCBpcyBhbHNvIHRydWUgZm9yIFFVSUMp LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkluIGVzc2VuY2UgeW91IGFyZSB0YWxraW5nIGFib3V0IGEgZmV3IGxpbmVz IG9mIGNvZGUuIFlvdXIgc29sdXRpb24gdGhlbiBhbHNvIHJlcXVpcmVzIGFkZGl0aW9uYWwgbGlu ZXMgb2YgY29kZSBlbHNld2hlcmUuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2lhbzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+TWFydGluIER1a2U8YnI+DQo8Yj5TZW50OjwvYj4gMjMgSmFudWFyeSAyMDE4IDIz OjA5PGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gQSBi ZXR0ZXIgd2F5IHRvIGRvIGNvbm4gaWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub2RheSdzIHZhcmlhYmxlLWxlbmd0aCBjb25uZWN0aW9uIElE IGRpc2N1c3Npb24gbWFkZSBtZSByZWFsaXplIHNvbWUgcHJvYmxlbXMgd2l0aCB0aGUgY3VycmVu dCBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBuZXcgYXJjaGl0ZWN0dXJlIGRvZXNuJ3QgZml4IHNv bWUgb2YgdGhlbSBhbmQgY3JlYXRlcyB3aG9sZSBuZXcgb25lcy4gSXNzdWVzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRoZSBjbGllbnQg ZGVzaXJlcyB1bmxpbmthYmlsaXR5LCBidXQgSSBzdXNwZWN0IHRoZSBtYXJrZXQgd2lsbCBwcm92 aWRlIG5vIGluY2VudGl2ZXMgZm9yIHNlcnZlcnMgdG8gd29yayB2ZXJ5IGhhcmQgdG8gYmUgdW5s aW5rYWJsZS4gVGhlcmUgd2VyZSBjb25mbGljdGluZyAmcXVvdDtsYXllciA5JnF1b3Q7IGFyZ3Vt ZW50cyB0aGF0IHZhcmlhYmxlIGNvbm4gSUQgbWFrZXMgdGhpcyBwcm9ibGVtIHdvcnNlIG9yIGJl dHRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSAxNiBCeXRlcyBpcyBtb3JlIG92ZXJoZWFkIHRoYW4gOCBieXRlcy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaGUgc2V2ZXJpdHkg b2YgdGhpcyByZW1haW5zIHRvIGJlIHNlZW4sIGJ1dCB2YXJpYWJsZSBsZW5ndGggY29ubiBpZHMg d2lsbCBpbnRyb2R1Y2UgbW9yZSBjb21wbGV4aXR5IGluIHBhcnNlcnMgYW5kIGFueXRoaW5nIHRo YXQgdXRpbGl6ZXMgdGhlIGNvbm4gaWQgKGUuZy4gaGFuZHNoYWtlIGtleSBnZW5lcmF0aW9uKS4g SXQgbWlnaHQgbWFrZSB0aGUgaW52YXJpYW50cyBtb3JlIGNvbXBsZXggYXMgd2VsbC4NCiBUaGUg d2hvbGUgdGhpbmcsIGZyYW5rbHksIG1ha2VzIG15IGhlYWQgaHVydC48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBodW1ibHkgc3VnZ2VzdCB0 aGUgZm9sbG93aW5nIHByb3Bvc2FsIG1pZ2h0IGF2b2lkIG9yIG1pdGlnYXRlIHNvbWUgb2YgdGhl c2UgcHJvYmxlbXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjEuIEV2ZXJ5IGNvbm5lY3Rpb24gaGFzIGEgbG9uZy1saXZlZCBDbGllbnQtZ2Vu ZXJhdGVkIENvbm5lY3Rpb24gSUQgKENHQ0lEKSBhbmQgU2VydmVyLWdlbmVyYXRlZCBDb25uZWN0 aW9uIElEIChTR0NJRCkuIFRoZSBDR0NJRCBpcyA4IGJ5dGVzIGFuZCB0aGUgU0dDSUQgaXMgMTYg Ynl0ZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjIuIFRoZSBDR0NJRCBpcyB1c2VkIHRvIGRlcml2ZSB0aGUgaGFuZHNoYWtlIGtleS4gKHVu Y2hhbmdlZCBmcm9tIHN0YXR1cyBxdW8pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMuIFRoZSBpbml0aWFsIHBhY2tldCB1c2VzIHRoZSBDR0NJ RC4mbmJzcDsgQWxsIG90aGVyIGhhbmRzaGFrZSBwYWNrZXRzIHVzZSB0aGUgU0dDSUQuIFRoaXMg aXMgdW5jaGFuZ2VkIGZyb20gdGhlIHN0YXR1cyBxdW8uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjQuIEFsbCAxLVJUVCBwYWNrZXRzIGJ5IHNl bnQgYnkgdGhlIGNsaWVudCB1c2UgdGhlIFNHQ0lELiBBbGwgMS1SVFQgcGFja2V0cyBzZW50IGJ5 IHRoZSBzZXJ2ZXIgdXNlIHRoZSBDR0NJRC4gVGhpcyBoYXMgdHdvIGltcG9ydGFudCBwcm9wZXJ0 aWVzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDthKSBUaGUgc2VydmVyIGdl dHMgdGhlIDE2IEJ5dGVzIG9mIGVudHJvcHkgdGhlIGxvYWQgYmFsYW5jZXIgbmVlZHM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YikgVGhlIHNlcnZlci0mZ3Q7Y2xpZW50IGRp cmVjdGlvbiwgd2hpY2ggaW4gdGhlIHVzdWFsIGNhc2UgaGFzIG1vc3Qgb2YgdGhlIGRhdGEsIGhh cyBhIGxvd2VyLW92ZXJoZWFkIENJRC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+NS4gVGhlIGFsZ29yaXRobSB0aGF0IGdlbmVyYXRlcyBTR0NJ RCBNVVNUIGhhdmUgZGlmZmVyZW50IG91dHB1dCBnaXZlbiBhIGRpZmZlcmVudCBDR0NJRC4gW1dl IG1pZ2h0IHN0cmVuZ3RoZW4gdGhpcyBsYW5ndWFnZSBmdXJ0aGVyOiB5b3Ugd291bGRuJ3Qgd2Fu dCB0byBzaW1wbHkgYWRkIHRoZSBORVdfQ09OTl9JRCBzZXF1ZW5jZSBudW1iZXIgdG8gdGhlIGV4 aXN0aW5nIFNHQ0lELCBmb3IgaW5zdGFuY2VdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj42LiBJbiBhZHZhbmNlIG9mIG1pZ3JhdGlvbiwgdGhl IGNsaWVudCBzZW5kcyBhIE5FV19DT05OX0lEIGZyYW1lIHRvIHByb3ZpZGUgYSBuZXcgQ0dDSUQg KHBvc3NpYmx5IG9taXR0aW5nIHRoZSBzdGF0ZWxlc3MgcmVzZXQgdG9rZW4pLiBUaGUgc2VydmVy IE1VU1QgcmVzcG9uZCB3aXRoIGEgTkVXX0NPTk5fSUQgdGhhdCBwcm92aWRlcyBhIG5ldyBTR0NJ RCBkZXJpdmVkIGZyb20gdGhlIG5ldyBDR0NJRC4gQWxsDQogcGFja2V0cyBvbiB0aGUgbmV3IHBh dGggdXNlIHRoZXNlIENJRHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIHBlb3BsZSBsaWtlIHRoaXMsIEkgY2FuIGdlbmVyYXRlIGEgUFIu IEkgYW0gdmVyeSBvcGVuIHRvIHZhcmlvdXMgdHdlYWtzIHRvIHRoZSBnZW5lcmFsIGFwcHJvYWNo IGFzIHdlbGwuIEkgd2FudGVkIHRvIGdldCB0aGlzIG91dCB0aGVyZSBiZWZvcmUgdGhlIHZhcmlh YmxlLWxlbmd0aCBDSUQgdGVhbSBnZXRzIGRlZXAgaW4gdGhlIHdlZWRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ0aW4gRHVrZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM4PR0801MB270652B9DBDB5FBE93E9A6D2FAE20AM4PR0801MB2706_-- From nobody Wed Jan 24 08:45:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B961126D45 for ; Wed, 24 Jan 2018 08:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 pSYnE8DQ0JZo for ; Wed, 24 Jan 2018 08:45:06 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001: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 7E0D0126E3A for ; Wed, 24 Jan 2018 08:44:49 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id 25so5479422ioj.9 for ; Wed, 24 Jan 2018 08:44:49 -0800 (PST) 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=sYHvYLqLKyuI0kOwnt+ZF8c/12rJk2GoSb3LOIXzF3Y=; b=fu9y58l7MGA9qDPTiadJq4EbyPqwf7pmn3FRTQRI6JSBk5q4hTC3hdM2PCfciOf/+O wrGkwd7Abj1spqwwaBKbQiTqPRne/YfWN5bklYdofPmW3w5FwQw37Sph3ZqMcMk9BV+o ioLambaloWFfnGeJDHhUsrcEvXSWA6N06PM2x9ioSskFHyos9EMi3ZnTlWioYmR1SBRy xDPyLHWTw6117iwIy2U7IIRFfYeZ6tkr7l41krtHDZWDADbbA8pVaRnw4mgkG6dUImPx lVbUTlOVX0OLcMc+ai+jqHLIfJQRcSqp8fBG/nqNn6wA0wxtJYj/iRzItgc+4zUdg5QK 06jQ== 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=sYHvYLqLKyuI0kOwnt+ZF8c/12rJk2GoSb3LOIXzF3Y=; b=X/ekZp51tgTo6lSU9gztPl+Ql0HAHIN9xxZEpf+UWo3I89kiVdw1nsIuxuA0DIAfLG X6csXWTHzwI4X9MUFLHOS+ctaw1jkoDOdAkPqBKZDxYM0CqSnaxHKl0/MdLrHvKf0L74 KbJIYe7up87UJ3mdCZJKKxLNiOz5Kt414zIqvVBwepw8mGSwAbeUaLTU5SfrXj6UwOLB zf7+5Jc56VZrs2sIMgFm39jgZoXMIefpb/6oHnSKbfQYTU92sSUZUxerKTTxSOt/DeM1 JeqfWJR0d1jLRhd8eO4XtA4B4Wt+c3AlQzZoJCGg2C0ECCcb7MZc0M51PaKAo4EqdH/G DsOA== X-Gm-Message-State: AKwxytdF9zCYh3ckdWtLqoH4COwlL/tfDh1AE2ZV7jO0phe5J2YkIZLS p9159V+RUdsh2fDivvQDoPV23Acbbcb8bVo4BtzU X-Google-Smtp-Source: AH8x227f7U85mtKkZfB9GKXRGGKcZH7tmH/DAq+7j1LJF+iV8CJN8OfZXHQWe3ZhLbcu5SDGllshs8Kvn5B1ZyXGDdE= X-Received: by 10.107.3.160 with SMTP id e32mr4424047ioi.51.1516812288184; Wed, 24 Jan 2018 08:44:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.156.203 with HTTP; Wed, 24 Jan 2018 08:44:27 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Wed, 24 Jan 2018 08:44:27 -0800 Message-ID: Subject: Re: Updated QCRAM Draft To: Kazuho Oku Cc: Jana Iyengar , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113ea692a1c6700563886158" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 16:45:09 -0000 --001a113ea692a1c6700563886158 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku wrote: > 2018-01-24 23:10 GMT+11:00 Jana Iyengar : > > > > The draft outlines what I think the room converged on, and it seems > fairly straightforward -- thanks for the quick turnaround! > > > > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but = I > believe the "Base Index" is basically what I think of as the "generation > ID" of the table. It reflects the number of table operations that have > happened... this is important when you have evictions, since just a > reference to the largest index is ambiguous if there have been evictions. > > Jana, thank you for the response. > > Please correct me if I am wrong, but the below is my understanding. > > Modifications to the HPACK state only happens on the Control Stream. > So we do not need to rely on the index to determine how the state > needs to be changed. > Great point. The prefix is not needed for the modifications to HPACK state, i.e. for the blocks delivered on the Control Stream. > > For HEADERS frames sent over non-control streams, the only information > that the decoder needs is the absolute indices of the header table, > which can be encoded as largest_index (or whatever you call) plus the > deltas. > > > > > > > I don't understand however how the largest index is "Base Index - > Depends". I would've thought the largest index would simply be "Depends". > What am I missing? > Alan F. also made a similar point. Base index is for interpreting indexed representations correctly regardless of re-ordering. It is basically the total number of insertions that happened before the current block has processed. Depends is for ensuring that the decoder blocks if necessary to wait for table updates the current block depends on. The 'Base Index - Depends' is poorly written and needs an example, sorry about that. The point I was trying (badly) to make was that depends is encoded relative to Base Index so that it's size stays bounded, it's just an optimization to save bytes for the case of very long lived connections. Note that Base Index does not have such bound right now. Maybe a change to specify wrap-around might be a reasonable way to also bound Base Index. Alternatively, and maybe this is what you just said (?), the two could be combined into one number. I think that is tricky because one does not naturally know "depends" yet while emitting indexed entries. It could be in practice that either the depends flag is false, or it is true and the Depends value is the same as Base Index. This was definitely not true with QCRAM-03, but it might well be with QCRAM-04. That's what I hope to sort out ASAP with updates to the simulator. =F0=9F=A4=94 > > > > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku wrote= : > >> > >> Buck, > >> > >> Thank you for the draft. > >> > >> I like the approach and I think that it is not difficult to implement. > >> > >> Reading the spec, the question I have is why you need the BLOCKING fla= g > and two variables (i.e. base index and depends). Can't each HEADERS frame > always hold just one offset (i.e. largest index that the frame refers to)= ? > >> > >> Maybe I am missing something. > >> > >> > >> 2018-01-24 16:53 GMT+11:00 Mike Bishop : > >>> > >>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html= / > draft-krasic-quic-qcram-04 -- please read before tomorrow=E2=80=99s meeti= ng so we > can have a useful discussion. Thanks! > >> > >> > >> > >> > >> -- > >> Kazuho Oku > > > > > > > > -- > Kazuho Oku > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a113ea692a1c6700563886158 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku <kazuhooku@gmail.com= > wrote:
    2018-= 01-24 23:10 GMT+11:00 Jana Iyengar <jr= i@google.com>:
    >
    > The draft outlines what I think the room converged on, and it seems fa= irly straightforward -- thanks for the quick turnaround!
    >
    > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but= I believe the "Base Index" is basically what I think of as the &= quot;generation ID" of the table. It reflects the number of table oper= ations that have happened... this is important when you have evictions, sin= ce just a reference to the largest index is ambiguous if there have been ev= ictions.

    Jana, thank you for the response.

    Please correct me if I am wrong, but the below is my understanding.

    Modifications to the HPACK state only happens on the Control Stream.
    So we do not need to rely on the index to determine how the state
    needs to be changed.

    Great point.=C2=A0= The prefix is not needed for the modifications to HPACK state, i.e. for th= e blocks delivered on the Control Stream.
    =C2=A0

    For HEADERS frames sent over non-control streams, the only information
    that the decoder needs is the absolute indices of the header table,
    which can be encoded as largest_index (or whatever you call) plus the
    deltas.

    >
    >
    > I don't understand however how the largest index is "Base Ind= ex - Depends". I would've thought the largest index would simply b= e "Depends". What am I missing?
    =
    Alan F.=C2=A0 also made a similar point.

    Base index is for interpreting indexed representations correctly rega= rdless of re-ordering.=C2=A0 It is basically the total number of insertions= that happened before the current block has processed.

    =
    Depends is for ensuring that the decoder blocks if necessary to wait f= or table updates the current block depends on.=C2=A0=C2=A0

    The 'Base Index - Depends' is poorly written and needs an = example, sorry about that.=C2=A0 =C2=A0The point I was trying (badly) to ma= ke was that depends is encoded relative to Base Index so that it's size= stays bounded, it's just an optimization to save bytes for the case of= very long lived connections.=C2=A0 Note that Base Index does not have such= bound right now.=C2=A0 Maybe a change to specify wrap-around=C2=A0 might b= e a reasonable way to also bound Base Index.

    Alter= natively, and maybe this is what you just said (?), the two could be combin= ed into one number.=C2=A0 =C2=A0I think that is tricky because one does not= naturally know "depends" yet while emitting indexed entries.=C2= =A0 =C2=A0 It could be in practice that either the depends flag is false, o= r it is true and the Depends value is the same as Base Index.=C2=A0 =C2=A0T= his was definitely not true with QCRAM-03, but it might well be with QCRAM-= 04.=C2=A0 =C2=A0 That's what I hope to sort out ASAP with updates to th= e simulator.=C2=A0=F0=9F=A4=94



    =

    =C2=A0
    >
    > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
    >>
    >> Buck,
    >>
    >> Thank you for the draft.
    >>
    >> I like the approach and I think that it is not difficult to implem= ent.
    >>
    >> Reading the spec, the question I have is why you need the BLOCKING= flag and two variables (i.e. base index and depends). Can't each HEADE= RS frame always hold just one offset (i.e. largest index that the frame ref= ers to)?
    >>
    >> Maybe I am missing something.
    >>
    >>
    >> 2018-01-24 16:53 GMT+11:00 Mike Bishop <mbishop@evequefou.be>:
    >>>
    >>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 --= please read before tomorrow=E2=80=99s meeting so we can have a useful disc= ussion.=C2=A0 Thanks!
    >>
    >>
    >>
    >>
    >> --
    >> Kazuho Oku
    >
    >



    --
    Kazuho Oku



    --
    = Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

    --001a113ea692a1c6700563886158-- From nobody Wed Jan 24 08:49:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D34127010 for ; Wed, 24 Jan 2018 08:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz2yh8GaHUxV for ; Wed, 24 Jan 2018 08:49:55 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9DFB126DCA for ; Wed, 24 Jan 2018 08:49:54 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id o35so11912534qtj.13 for ; Wed, 24 Jan 2018 08:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=NckQ/hrDS4DXIzq2ct3TFyn+4QH9yfhgwLGlEyIZflk=; b=P4tRPnHT2/bkghXDIfXIIBYayE8RGq+QyhVM3V4mpWdE5/2GCGUf2OdF9oY6wbUDp+ +bk5Op7KVeMOrUWCWGdjcWMakU3gt1K7SKX4w+ll7wiCV4fgT1NC5EIEtTirNSK3FRNl /ohxoqO0jGmln3xu5P5/yNi9o3U48s1L/KQa01zb+9yYIcYighx2mTqtK3NHU1J8IoDB xDb3b7am0Cax+M/lVU/BYqw47pG2kPiImVKFdDWIFARDdXAt/wHTMilhLV2Ly2qXVqgW mxpj64Y70cOZZ4zHjIz8+NZHewxtJI1epD3Q8Kapgl3pn3UzKOJzUvd/bmlCPoyWBPur zl2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=NckQ/hrDS4DXIzq2ct3TFyn+4QH9yfhgwLGlEyIZflk=; b=ua6wN3HpLTE99SYXBwK3esnaCCx50fK+UMVQO/lrFNW/1oYGeUpm8XQnx0Bj7+c/l6 hcZkkRLUqLBub5sIHPqLcVYYjeG7aEhtub8sh1Cl5Bj/P35aJ5tZYzjGa5T/zenChwxu OuAztddo8DJJ3j+8S/F8EyjcX9IjZXVyX+uatVoHLu+bZHte7P78QNzU7H9ic/OSWuuj GpEp5fjwz9umhDRL7C2tj+/tr7d56BtXfJwBs8nuMtkW8DdTw/1JXtOriqrepFgauIHa 5WKcB5kY51cQ4elw87EgwI0CdFj0YnMsDsPVr2STaj3M0IAd744WgQc/bVAuVYzhV5Hy NSOQ== X-Gm-Message-State: AKwxytd/ChzM28eo09rBbijmwZPyxQVlraM3zrFOGXn0IE0EaJJiLtT6 i6pLv1onUu/MdLWnPFVVqaX0Hg== X-Google-Smtp-Source: AH8x227mcuJHkxGkAOvtH9310rSR8DLmL/SgyJ/8XxfEc0a8bWD+C02DibVtmmuHFRXy0pQUeuGC3w== X-Received: by 10.55.207.156 with SMTP id v28mr10014152qkl.36.1516812593662; Wed, 24 Jan 2018 08:49:53 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id x79sm586325qkg.38.2018.01.24.08.49.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jan 2018 08:49:53 -0800 (PST) Date: Wed, 24 Jan 2018 11:49:51 -0500 From: Dmitri Tikhonov To: Mike Bishop Cc: IETF QUIC WG , Charles 'Buck' Krasic Subject: Re: Updated QCRAM Draft Message-ID: <20180124164950.GC7729@ubuntu-dmitri> Mail-Followup-To: Mike Bishop , IETF QUIC WG , Charles 'Buck' Krasic References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 16:49:58 -0000 On Wed, Jan 24, 2018 at 05:53:55AM +0000, Mike Bishop wrote: > Buck has posted an updated QCRAM draft at > https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read > before tomorrow's meeting so we can have a useful discussion. Thanks! Single Control Stream Prevents QCRAM-04 from Solving HoLB ========================================================= Abstract: A consice overview of the HoLB problem is presented. The QCRAM-04 approach to solving this problem is analyzed. A problematic design choice is identified and its impact assessed. An alternative design is suggested. Problem Statement ----------------- QCRAM-04 is a version of QCRAM in which all table updates occur on a dedicated control stream. This restriction has a negative effect on the protocol's ability to minimize HoLB. There exists a class of applications for which QCRAM-04 does not solve HoLB, solely as a result of introducing ordering to otherwise independent operations. The Original HoLB Problem ------------------------- The original HoLB problem that we are trying to solve is as follows. HPACK/GQUIC delivers all HTTP message headers as header blocks on a separate control stream. HTTP message payload (bodies) are sent on different streams, one message per stream. The application (HTTP) cannot process message bodies without the headers; it must have the headers before it starts reading from the message stream. +----------------+----------------+ | Header Block A | Header Block B | +----------------+----------------+ +----------------+ | Message A Body | +----------------+ +--------------------------------+ | Message B Body | +--------------------------------+ Figure 1: HPACK/GQUIC: Control stream carrying two header blocks and two streams carrying message bodies. If a packet carrying part of the Header Block A is lost, Header Block B and, therefore, the whole of Message B cannot be processed, even if all of the packets carrying Header Block B and Message B Body have arrived. Message B is stalled until the lost packet is retransmitted successfully and the control stream is unblocked. This is the HoLB problem. Proposed Solutions ------------------ The solutions to the HoLB problem fall into two categories: 1. Avoidance: Disallow vulnerable references. This approach is robust and simple to implement, but carries a compression performance penalty. 2. Minimization: Allow vulnerable references, but minimize their impact. This approach looks to achieve maximum compression at the cost of protocol and implementation complexity. QCRAM and QPACK belong to the second category. Until QCRAM-04, both carried table updates on multiple streams, for the following reason: Coping with False Dependencies ------------------------------ (Refer to Figure 1 again). If Header Block B uses a dynamic entry inserted by Header Block A, then B cannot be processed until A has been processed; this is a true dependency. If, however, Header Block B does not depend on any insertions performed by Header Block A, placing them in order on a single control stream introduces a false dependency. The design choice of placing dynamic table updates on separate streams is driven by desire to eliminate false dependencies and, thereby, to minimize HoLB. How QCRAM-04 is Different From HPACK/GQUIC ------------------------------------------ QCRAM-04 moves parts of header blocks from the control stream to the individual message streams. This means that if a particular message's headers do not cause an insertion into the dynamic table, this message does not have to write to the control stream. This eliminates some false dependencies and is an improvement over HPACK/GQUIC. +---------------------------+ | Updates Associated with A | +---------------------------+ +----------------+----------------+ | Header Block A | Message A Body | +----------------+----------------+ +----------------+--------------------------------+ | Header Block B | Message B Body | +----------------+--------------------------------+ Figure 2: QCRAM-04: control stream carrying table modifications upon which Header Block A depends and message streams for messages A and B. Message B can be processed if parts of message A are lost. False Dependencies Remain ------------------------- If messages A and B cause independent updates to the dynamic table, they are written to the control stream. This fact makes message B depend on message A: a false dependency. +-----------------------+-----------------------+ | Updates Assoc. with A | Updates Assoc. with B | +-----------------------+-----------------------+ +----------------+----------------+ | Header Block A | Message A Body | +----------------+----------------+ +----------------+--------------------------------+ | Header Block B | Message B Body | +----------------+--------------------------------+ Figure 3: QCRAM-04: control stream carrying independent table modifications which, nevertheless, make Message B depend on Message A: a false dependency. Note that Figure 3 and Figure 1 are quite similar. Three Application Classes ------------------------- To analyze how QCRAM-04 improves over HPACK/GQUIC, we should consider three application classes (basically, usage patterns): I. Dependent header blocks; II. Independent header blocks without table modification; and III. Independent header blocks with table modification. I. Dependent Header Blocks -------------------------- If Header Block B uses table entries added by Header Block A, there is not much one can do about that: A must be processed before B, no matter how the header blocks are transmitted. QCRAM-04 and HPACK/GQUIC do not introduce HoLB: this is the property of the application itself. II. Independent header blocks without table modification -------------------------------------------------------- Header blocks that do not modify the dynamic table do not require the use of the control stream in QCRAM-04 (see Figure 2). This is a clear improvement over HPACK/GQUIC, which introduces a false dependency and risks HoLB by delivering all header blocks over the same stream. III. Independent header blocks with table modification ------------------------------------------------------ If Header Blocks A and B insert different entries into the dynamic table and Header Block B does not use any entries inserted by A, both QCRAM-04 and HPACK/GQUIC introduce a false dependency by delivering unrelated table updates associated with A and B on the same stream (see Figure 3). Quantitatively, QCRAM-04 is a little better than HPACK/GQUIC here. This is because it sends less data on the control stream, which means that the chances of packet loss are smaller. However, the improvement is small: the control stream carries table updates, which is most of the header block data. Summary ------- QCRAM-04 achieves HoLB minimization in one class of applications, but not in the other, where it introduces a false dependency. This means that the answer to the question "Will my application suffer from protocol-induced HoLB were I to switch to HTTP/QUIC?" is "It depends." That is not good enough. In the HoLB minimization approach, independent dynamic table updates must be sent on different streams. - Dmitri. From nobody Wed Jan 24 09:06:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82980127077 for ; Wed, 24 Jan 2018 09:06:13 -0800 (PST) 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 kwP7d4yHPuB4 for ; Wed, 24 Jan 2018 09:06:10 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 5A9A7126FDC for ; Wed, 24 Jan 2018 09:06:10 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id m26so3546296pfj.11 for ; Wed, 24 Jan 2018 09:06:10 -0800 (PST) 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=iIWP66doa9uFyIG+HS/rGC6Zm6Zj9eBeFgXjL71Mufw=; b=tisNYAKAE2Hl9LSY9mbgyKk5qQvYbcHUZeTwqLLcyPBMWeJKhyoFbLqXVDiJBd929W qEG1PjZ675vkKKIZL4awfwChO4zPhbGbjVbclkypliCR7S0tN+Gbb45+ximUGxgLmyzT hCa0xFvLzobXVjpRexCsA9xmBab8EpPbtdpIToQ+hoEbV0EUNIo4s4+TpuuivcXpF0P9 ALC7LBLfMzSCHzFZrm17pm4hUCcRl2xrFjfyAwVulxjZEe4iuXYckoxGnm0TL053rCBo /UUY0fIXJwE8dtRnpi+zGgmD08mXbv+OrI+Jf4xo09xTTjXM8KwdnsPeOFH65VoH38Z2 qbYw== 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=iIWP66doa9uFyIG+HS/rGC6Zm6Zj9eBeFgXjL71Mufw=; b=FwuznuPvAn4U3HYgVTisumlUsGb4JlX1I7LZbHDyST+exBQ6IQGhUn2dtEcu58wsNF fy5HYryJb6ajr6TOGFRtjEf6p/zGgWuGh1zApUsgz/XDjS9hphs8zxSHRDZvn7JawZpl oc2M+TkTMc3D7jVaNe+h+RzJZe9YcBt2tdEv3UHtn5G6eS4mLq5P4iIp7x3bcg9oPNkC dKiCpaQU0gAvRjVfx9Larn1k5kS2GcSar6HwJ28MCgFybupSO/dx9Oj1WhQU0i/gsPKp lCq96cEkNi++PJUWTsI+RuHSh4p56IG6tSe0ZABgF7AanF0dYoh7/0FUaZNQIy/7YpDa pp9g== X-Gm-Message-State: AKwxytcHhYA3vGFBFlo7zQKewJTY3Fi6SJT0xIWgjNi4z/Cbd9PABc/F 984UDmDZZ2cCcjTei0349h7949y7p5Ra8nP0aUqtHVR+ X-Google-Smtp-Source: AH8x226APHIoQrFAdGW+XFDOw/Bj4hCxO0YGPRuOMDeoBBV9nPrZIuCvfYtArq+f/baU7nhDFiLCaC0Ijq9gF75s10E= X-Received: by 10.99.96.199 with SMTP id u190mr11183526pgb.290.1516813569865; Wed, 24 Jan 2018 09:06:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 24 Jan 2018 09:06:09 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Thu, 25 Jan 2018 04:06:09 +1100 Message-ID: Subject: Re: Updated QCRAM Draft To: "Charles 'Buck' Krasic" Cc: Jana Iyengar , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c1109f205be30056388aec3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 17:06:13 -0000 --94eb2c1109f205be30056388aec3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thank you for the response. 2018-01-25 3:44 GMT+11:00 Charles 'Buck' Krasic : > > > On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku wrote: > >> 2018-01-24 23:10 GMT+11:00 Jana Iyengar : >> > >> > The draft outlines what I think the room converged on, and it seems >> fairly straightforward -- thanks for the quick turnaround! >> > >> > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but >> I believe the "Base Index" is basically what I think of as the "generati= on >> ID" of the table. It reflects the number of table operations that have >> happened... this is important when you have evictions, since just a >> reference to the largest index is ambiguous if there have been evictions= . >> >> Jana, thank you for the response. >> >> Please correct me if I am wrong, but the below is my understanding. >> >> Modifications to the HPACK state only happens on the Control Stream. >> So we do not need to rely on the index to determine how the state >> needs to be changed. >> > > Great point. The prefix is not needed for the modifications to HPACK > state, i.e. for the blocks delivered on the Control Stream. > > >> >> For HEADERS frames sent over non-control streams, the only information >> that the decoder needs is the absolute indices of the header table, >> which can be encoded as largest_index (or whatever you call) plus the >> deltas. >> >> > >> > >> > I don't understand however how the largest index is "Base Index - >> Depends". I would've thought the largest index would simply be "Depends"= . >> What am I missing? >> > > Alan F. also made a similar point. > > Base index is for interpreting indexed representations correctly > regardless of re-ordering. It is basically the total number of insertion= s > that happened before the current block has processed. > > Depends is for ensuring that the decoder blocks if necessary to wait for > table updates the current block depends on. > > The 'Base Index - Depends' is poorly written and needs an example, sorry > about that. The point I was trying (badly) to make was that depends is > encoded relative to Base Index so that it's size stays bounded, it's just > an optimization to save bytes for the case of very long lived connections= . > Note that Base Index does not have such bound right now. Maybe a change = to > specify wrap-around might be a reasonable way to also bound Base Index. > > Alternatively, and maybe this is what you just said (?), the two could be > combined into one number. > Yes. That is what I have been thinking of. > I think that is tricky because one does not naturally know "depends" yet > while emitting indexed entries. > I think that the encoder needs to do a two-pass operation regardless of if we encode two numbers (i.e. base_index, depends) or just one. This is because since base_index and depends cannot be determined until the encoder iterate through all the headers. So to me it seems that it is not tricker for an encoder to use an unified value; in the first pass the encoder determines the absolute index, and then in the second pass emit the unified "base index" plus the deltas. > It could be in practice that either the depends flag is false, or it > is true and the Depends value is the same as Base Index. This was > definitely not true with QCRAM-03, but it might well be with QCRAM-04. > That's what I hope to sort out ASAP with updates to the simulator. =F0=9F= =A4=94 > I understand that it's hard to update all the related code as we adjust the approach. Thank you for your efforts! > > > > > >> > >> > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku >> wrote: >> >> >> >> Buck, >> >> >> >> Thank you for the draft. >> >> >> >> I like the approach and I think that it is not difficult to implement= . >> >> >> >> Reading the spec, the question I have is why you need the BLOCKING >> flag and two variables (i.e. base index and depends). Can't each HEADERS >> frame always hold just one offset (i.e. largest index that the frame ref= ers >> to)? >> >> >> >> Maybe I am missing something. >> >> >> >> >> >> 2018-01-24 16:53 GMT+11:00 Mike Bishop : >> >>> >> >>> Buck has posted an updated QCRAM draft at >> https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read >> before tomorrow=E2=80=99s meeting so we can have a useful discussion. T= hanks! >> >> >> >> >> >> >> >> >> >> -- >> >> Kazuho Oku >> > >> > >> >> >> >> -- >> Kazuho Oku >> > > > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 <(408)%20412-1141> > > --=20 Kazuho Oku --94eb2c1109f205be30056388aec3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi,=C2=A0

    Thank you for the = response.

    2018-01-25 3:44 GMT+11:00 Charles 'Buck' Krasic <ckrasic@google= .com>:


    On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku <kazuh= ooku@gmail.com> wrote:
    2018-01-24 2= 3:10 GMT+11:00 Jana Iyengar <jri@google.com>:
    >
    > The draft outlines what I think the room converged on, and it seems fa= irly straightforward -- thanks for the quick turnaround!
    >
    > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but= I believe the "Base Index" is basically what I think of as the &= quot;generation ID" of the table. It reflects the number of table oper= ations that have happened... this is important when you have evictions, sin= ce just a reference to the largest index is ambiguous if there have been ev= ictions.

    Jana, thank you for the response.

    Please correct me if I am wrong, but the below is my understanding.

    Modifications to the HPACK state only happens on the Control Stream.
    So we do not need to rely on the index to determine how the state
    needs to be changed.

    Great point= .=C2=A0 The prefix is not needed for the modifications to HPACK state, i.e.= for the blocks delivered on the Control Stream.
    =C2=A0

    For HEADERS frames sent over non-control streams, the only information
    that the decoder needs is the absolute indices of the header table,
    which can be encoded as largest_index (or whatever you call) plus the
    deltas.

    >
    >
    > I don't understand however how the largest index is "Base Ind= ex - Depends". I would've thought the largest index would simply b= e "Depends". What am I missing?
    =
    Alan F.=C2=A0 also made a similar point.
    Base index is for interpreting indexed representations correct= ly regardless of re-ordering.=C2=A0 It is basically the total number of ins= ertions that happened before the current block has processed.
    Depends is for ensuring that the decoder blocks if necessary to= wait for table updates the current block depends on.=C2=A0=C2=A0

    The 'Base Index - Depends' is poorly written and ne= eds an example, sorry about that.=C2=A0 =C2=A0The point I was trying (badly= ) to make was that depends is encoded relative to Base Index so that it'= ;s size stays bounded, it's just an optimization to save bytes for the = case of very long lived connections.=C2=A0 Note that Base Index does not ha= ve such bound right now.=C2=A0 Maybe a change to specify wrap-around=C2=A0 = might be a reasonable way to also bound Base Index.

    Alternatively, and maybe this is what you just said (?), the two could be= combined into one number.

    Yes. That is what I have been thinking of.
    =C2=A0
    I think that is tricky because one does not naturally know = "depends" yet while emitting indexed entries.

    I think that the encoder needs to do a= two-pass operation regardless of if we encode two numbers (i.e. base_index= , depends) or just one. This is because since base_index and depends cannot= be determined until the encoder iterate through all the headers.

    So to me it seems that it is not tricker for an encoder to = use an unified value; in the first pass the encoder determines the absolute= index, and then in the second pass emit the unified "base index"= plus the deltas.
    =C2=A0
    <= div class=3D"gmail_extra">
    =C2=A0 =C2=A0 It = could be in practice that either the depends flag is false, or it is true a= nd the Depends value is the same as Base Index.=C2=A0 =C2=A0This was defini= tely not true with QCRAM-03, but it might well be with QCRAM-04.=C2=A0 =C2= =A0 That's what I hope to sort out ASAP with updates to the simulator.= =C2=A0=F0=9F=A4=94

    = I understand that it's hard to update all the related code as we adjust= the approach. Thank you for your efforts!




    <= /div>

    =C2=A0
    >
    > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
    >>
    >> Buck,
    >>
    >> Thank you for the draft.
    >>
    >> I like the approach and I think that it is not difficult to implem= ent.
    >>
    >> Reading the spec, the question I have is why you need the BLOCKING= flag and two variables (i.e. base index and depends). Can't each HEADE= RS frame always hold just one offset (i.e. largest index that the frame ref= ers to)?
    >>
    >> Maybe I am missing something.
    >>
    >>
    >> 2018-01-24 16:53 GMT+11:00 Mike Bishop <mbishop@evequefou.be>:
    >>>
    >>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 --= please read before tomorrow=E2=80=99s meeting so we can have a useful disc= ussion.=C2=A0 Thanks!
    >>
    >>
    >>
    >>
    >> --
    >> Kazuho Oku
    >
    >



    --
    Kazuho Oku



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



    --
    Kazuho Oku
    --94eb2c1109f205be30056388aec3-- From nobody Wed Jan 24 10:02:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACEE512DFE0 for ; Wed, 24 Jan 2018 10:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMEhWqVziXKQ for ; Wed, 24 Jan 2018 10:01:45 -0800 (PST) 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 76A6D12DA72 for ; Wed, 24 Jan 2018 10:01:44 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OHuwZH011278; Wed, 24 Jan 2018 18:01:40 GMT 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=bFVdhBqzW2Lvg8FBQzCGsJ2rNeqUiYcDgxK0610r8uw=; b=KoNb9pZCt3J60G/Q+lSGQ9PJmh3863s60s+hwTbWgmZJB8REpocmACE84qttRVt1pPv6 MeiHal2SzCwRqdkMtL62Y5jmTnqCzif7omTixfiaMwgJlT09D3YymwnZHFyixBf05qwy 5+0kODpAvVUpRoWC8Ze0atq4BWiJk6PYT2vvKnUy4wy3IHnZLnsto8RxvvVzhjL/qLei qgZXn04u4HgepwvDpFiNQ7LEtxndqNruYc2tdovIikO8MX6zCZTjH3OXj9SgqA50B4NH NL4eCdn+4WnAUZlvKbGWxIt9af+ysk5hnpH/+6qvKY2qOnK5tyImkTEZyM0w7JVL3pXf dQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2fkuqg823c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 18:01:39 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0OI1Mn1031193; Wed, 24 Jan 2018 13:01:39 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200m2ca-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 13:01:38 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 Jan 2018 13:01:36 -0500 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, 24 Jan 2018 13:01:36 -0500 From: "Lubashev, Igor" To: Ingemar Johansson S , QUIC WG , "huitema (huitema@huitema.net)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQ Date: Wed, 24 Jan 2018 18:01:36 +0000 Message-ID: <660743ab697443f4ac5500e649a80285@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.33.239] Content-Type: multipart/alternative; boundary="_000_660743ab697443f4ac5500e649a80285usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240238 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240237 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 18:01:50 -0000 --_000_660743ab697443f4ac5500e649a80285usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoZSBwcmltYXJ5IGNvbmNlcm4gZHVyaW5nIHRoZSBtZWV0aW5nIHllc3RlcmRh eSB3YXMgdGhlIEVDTiBmZWVkYmFjayBmb3JtYXQgKGNvdW50ZXJzKS4gIEhlcmUgaXMgdGhlIGFs dGVybmF0aXZlLCBzaW1pbGFyIHRvIHdoYXQgQ2hyaXN0aWFuIHZvaWNlZC4NCg0KSSBhbSBtYWtp bmcgdGhlc2UgYXNzdW1wdGlvbnM6DQoNCiAgKiAgIENFIGlzIG5vdCBnb2luZyB0byBiZSBhIHZl cnkgY29tbW9uIG9jY3VycmVuY2UNCiAgKiAgIFRoZSBlbmRwb2ludCB3aWxsIHVzdWFsbHkgZWl0 aGVyIHNlbmQgKGFsbW9zdCkgYWxsIHBhY2tldHMgd2l0aCBubyBFQ1QgbWFya2luZ3MsIG9yIGl0 IHdpbGwgc2VuZCAoYWxtb3N0KSBhbGwgcGFja2V0cyB3aXRoIGEgc3BlY2lmaWMgRUNUIChFQ1Rb MF0gb3IgRUNUWzFdKS4NCk5vbmUgb2YgdGhlc2UgYXNzdW1wdGlvbnMgYXJlIHJlcXVpcmVkLiAg VGhleSBhcmUganVzdCB1c2VkIHRvIGlkZW50aWZ5IOKAnGNvbW1vbiBjYXNlc+KAnSBhbmQgc2F2 ZSBhIGZldyBieXRlcyBwZXIgQUNLIGZyYW1lLiAgV2UgbWF5IGRpc2NhcmQgdGhlc2UgYXNzdW1w dGlvbnMgYW5kIHRoZSBvcHRpbWl6YXRpb25zLg0KVGhlIHdvcnN0IGNhc2UgZm9yIHRoaXMgcHJv cG9zYWwgaXMgYSBjYXNlIHdoZW4gRUNUWzBdIGFuZCBFQ1RbMV0gbWFya2luZyBhbHRlcm5hdGUs IGJlY2F1c2UgdGhhdCBwcmV2ZW50cyBhY2tub3dsZWRnaW5nIGNvbnNlY3V0aXZlIHBhY2tldHMg YXMgYSBibG9jay4gIE15IGluY2xpbmF0aW9uIGlzIHRvIGRpcmVjdCB0aGUgc2VuZGVyIHRvIGp1 c3Qgbm90IGRvIHRoaXMuDQoNCg0KDQpQYXJ0IDEuIFByaW1hcnkgRUNUDQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KRHVyaW5nIHRoZSBoYW5kc2hha2UsIGVhY2ggZW5kcG9pbnQgbm90aWZp ZXMgdGhlIG90aGVyIG9mIHRoZSBFQ1QgY29kZXBvaW50IChFQ1RbMF0gb3IgRUNUWzFdKSB0aGF0 IGlzIGludGVuZHMgdG8gdXNlIHByaW1hcmlseS4gIFRoaXMgaXMga25vd24gdGhlIFByaW1hcnkg RUNULiAgQnkgZGVmYXVsdCwgRUNUWzBdIGlzIHRoZSBQcmltYXJ5IEVDVC4NCg0KDQpQYXJ0IDIu ICBUd28gQUNLIHZhcmlldGllcw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQpJbiBhZGRpdGlvbiB0byBBQ0sgRnJhbWUsIHdlIGludHJvZHVjZSBhIG5ldyBBQ0stRUNUIGZy YW1lLiAgVGhlIGNvbnRlbnRzIG9mIHRoZSBmcmFtZXMgYXJlIGlkZW50aWNhbCBhbmQgdW5jaGFu Z2VkIGZyb20gdGhlIGN1cnJlbnQgQUNLIGZyYW1lIGNvbnRlbnRzLg0KQWxsIHBhY2tldHMgYWNr bm93bGVkZ2VkIGJ5IHRoZSBBQ0sgRnJhbWUgYXJlIHBhY2tldHMgdGhhdCBoYXZlIG5vIEVDTiBi aXRzIHNldCBhdCBhbGwuICBBbGwgcGFja2V0cyBhY2tub3dsZWRnZWQgYnkgdGhlIEFDSy1FQ1Qg RnJhbWUgYXJlIHBhY2tldHMgdGhhdCBoYXZlIFByaW1hcnkgRUNUIGNvZGUgcG9pbnQuICBJdCBp cyBleHBlY3RlZCB0aGF0IGluIHRoZSBjb21tb24gY2FzZSwgYWxsIHBhY2tldHMgd2lsbCBiZSBh Y2tub3dsZWRnZWQgYnkgQUNLIG9yIEFDSy1FQ1QuDQoNCg0KUGFydCAzLiAgQUNLLUVDTi1CSVRN QVANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KVGhlIG5ldyBBQ0stRUNO LUJJVE1BUCBmcmFtZSBpcyB1c2VkIHdoZW4gQUNLIG9yIEFDSy1FQ1QgZnJhbWVzIGNhbm5vdCBi ZSB1c2VkLiAgSXRzIGZvcm1hdCBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIGZvcm1hdCBvZiB0aGUg QUNLIGZyYW1lLCBleGNlcHQgdGhlcmUgaXMgYSBuZXcgRUNOIEJpdG1hcCBmaWVsZC4NCg0Kfn5+ DQowICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgTGFyZ2VzdCBB Y2tub3dsZWRnZWQgKGkpICAgICAgICAgICAgICAgIC4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAg ICAgICAgICAgICAgICAgIEFDSyBEZWxheSAoaSkgICAgICAgICAgICAgICAgICAgICAgLi4uDQor LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgQUNLIEJsb2NrIENvdW50IChpKSAgICAg ICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICBF Q04gQml0bWFwICgqKSAgICAgICAgICAgICAgICAgICAgIC4uLg0KKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAg ICAgICAgICAgICAgICAgICAgIEFDSyBCbG9ja3MgKCopICAgICAgICAgICAgICAgICAgICAgLi4u DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0Kfn5+DQp7OiAjYWNrLWVjbi1iaXRtYXAgZm9ybWF0IHRpdGxlPSJBQ0stRUNO LUJJVE1BUCBGcmFtZSBGb3JtYXQifQ0KDQpUaGUgZmllbGRzIGluIHRoZSBBQ0stRUNOLUJJVE1B UCBmcmFtZSBhcmUgYXMgZm9sbG93czoNCg0KTGFyZ2VzdCBBY2tub3dsZWRnZWQ6ICAoU0FNRSBB UyBJTiBBQ0sgRlJBTUUpDQoNCkFDSyBEZWxheTogIChTQU1FIEFTIElOIEFDSyBGUkFNRSkNCg0K QUNLIEJsb2NrIENvdW50Og0KU0FNRSBBUyBJTiBBQ0sgRlJBTUUsIGV4Y2VwdCBwYWNrZXRzIGlu IGVhY2ggQUNLIEJsb2NrIE1VU1QgaGF2ZSB0aGUgc2FtZSBFQ04gbWFya2luZy4gIFRoaXMgbWF5 IGNhdXNlIGJsb2NrcyBvZiBjb25zZWN1dGl2ZSBwYWNrZXRzIHRvIGJlIHNwbGl0IGludG8gbXVs dGlwbGUgQUNLIEJsb2NrcyAod2l0aCBHYXA9MCBpbiBiZXR3ZWVuKSwgaWYgdGhvc2UgcGFja2V0 cyBoYXZlIGRpZmZlcmVudCBFQ04gbWFya2luZ3MuDQoNCkVDTiBCaXRtYXA6DQpBIHNlcXVlbmNl IG9mIEFDSyBCbG9jayBDb3VudCBwYWlycyBvZiBiaXRzIHRoYXQgaW5kaWNhdGUgRUNOIG1hcmtp bmdzIGZvciB0aGUgY29ycmVzcG9uZGluZyBBQ0sgQmxvY2suICBUaGUgc2l6ZSBvZiB0aGUgRUNO IEJpdG1hcCBmaWVsZCBpcyBDZWlsaW5nKCgxK+KAnEFDSyBCbG9jayBDb3VudOKAnSkvNCkgb2N0 ZXRzLiAgVGhlIHVudXNlZCBiaXRzIHNob3VsZCBiZSBzZXQgdG8gMC4NCkZvciBleGFtcGxlOg0K fn5+DQowICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQowIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8QUF8QkJ8Q0N8RER84oCmDQorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K DQpCaXRzIEFBIHJlcHJlc2VudCBFQ04gYml0cyBmb3IgcGFja2V0cyBhY2tub3dsZWRnZWQgaW4g dGhlIEZpcnN0IEFDSyBCbG9jay4NCkJpdHMgQkIgcmVwcmVzZW50IEVDTiBiaXRzIGZvciBwYWNr ZXRzIGFja25vd2xlZGdlZCBpbiBBZGRpdGlvbmFsIEFDSyBCbG9jayAwLg0KQml0cyBDQyByZXBy ZXNlbnQgRUNOIGJpdHMgZm9yIHBhY2tldHMgYWNrbm93bGVkZ2VkIGluIEFkZGl0aW9uYWwgQUNL IEJsb2NrIDENCuKApg0KDQpBQ0sgQmxvY2tzOiAoU0FNRSBBUyBJTiBBQ0sgRlJBTUUpDQoNCg0K DQogICogICBJZ29yDQoNCg0KRnJvbTogSW5nZW1hciBKb2hhbnNzb24gUyBbbWFpbHRvOmluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI0 LCAyMDE4IDM6MDEgQU0NClRvOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogRUNO IGluIFFVSUMNCg0KSGkNCg0KQSBmZXcgaW1wcmVzc2lvbnMgb24gdGhlIEVDTiBpbiBRVUlDIGRp c2N1c3Npb25zLiBUaGUgYXVkaW8gd2FzIHNvLXNvLCBmcmVxdWVudCBpbnRlcnJ1cHRpb25zIGFu ZCBMQVJHRSBkaWZmZXJlbmNlcyBpbiBhdWRpbyBsZXZlbCArIGJhZGx5IGltcGxlbWVudGVkIGVh cnMg8J+Yiiwgc28gc29tZXRpbWVzIEkgbWlzc2VkIHRoZSBkZXRhaWxzIGFuZCBwb3NzaWJseSBr aWNrIGluIG9wZW4gZG9vcnMuDQoNCiogIEZlZWRiYWNrIGZvcm1hdC4gSSB1bmRlcnN0YW5kIHRo YXQgdGhlIHByb3Bvc2VkIHByb3Bvc2FsIGJhc2VkIG9uIEVDVCgwKSwgRUNUKDEpIGFuZCBDRSBj b3VudGVycyBkb2VzIG5vdCBwbGF5IHdlbGwgd2l0aCBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gSSBi ZWxpZXZlLCBidXQgSSBhbSBub3QgMTAwJSBzdXJlIHRoYXQgSSB1bmRlcnN0YW5kIHRoZSBwcm9i bGVtLiBJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBhcmUgdHdvIGNvbmNlcm5zIChwZXJoYXBzIG1v cmU/KToNCiAgMS4gQ291bnRlcnMgYXJlIHJlc2V0LCB0aGlzIG1lYW5zIHRoYXQgdGhlcmUgd2ls bCBiZSBhIHBvdGVudGlhbGx5IHZlcnkgbGFyZ2UgKG5lZ2F0aXZlPykgZGlmZmVyZW5jZSBpbiBD RSBtYXJrZWQgcGFja2V0cy4gSSBiZWxpZXZlIHRoYXQgdGhpcyBjYW4gYmUgZGV0ZWN0ZWQgYXMg ZmFsc2UgY29uZ2VzdGlvbiBzaWduYWwgYW5kIGlnbm9yZWQgYnkgdGhlIGNvbmdlc3Rpb24gc2ln bmFsLg0KICAyLiBEaWZmaWN1bHRpZXMgdG8gZGV0ZWN0IEVDTiBibGVhY2hpbmcuIEl0IGlzIHRy aWNreSB0byB1bmRlcnN0YW5kIGlmIHBhY2tldHMgYWxvbmcgdGhlIG5ldyBwYXRoIGFyZSBibGVh Y2hlZCBiYXNlZCBvbiB0aGUgRUNUIGNvdW50ZXJzLiBUaGlzIGNhbiBiZSBhIG1vcmUgY29tcGxp Y2F0ZWQgY2FzZS4NCkluIGFueSBjYXNlIGl0IHdhcyBzdWdnZXN0ZWQgdG8gaW5kaWNhdGUgdGhl IEVDTiBiaXRzIGZvciB0aGUgcGFja2V0cyBpbiB0aGUgQUNLIGZyYW1lLiBTdWNoIGEgZm9ybWF0 IHdhcyBhY3R1YWxseSBvdXRsaW5lZCBpbiBlYXJsaWVyIHByb3Bvc2FsIChzZWUgcGFnZSA2LCBG aWd1cmUgMyBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtam9oYW5zc29uLXF1 aWMtZWNuLTAxPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGpvaGFuc3Nvbi0yRHF1aWMtMkRlY24t MkQwMSZkPUR3TUdhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJz a2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09eFZ6SUE5ZjdXaks4Q1ZJUTNCLXY5Wk5sLVVm OEhDWTRuWVBiMGZNUk8tNCZzPVM5YXFjOFVJR2FURFgzWk1zMVZUeVdpTFNTRzAxbmRGaGhyX1pn MDFIMVkmZT0+ICkuIEl0IGlzIE9rIHdpdGggbWUgdG8gY2hhbmdlIHRvIGEgZm9ybWF0IHNpbWls YXIgdG8gdGhpcyBpZiB0aGUgZ3JvdXAgcHJlZmVycyB0aGF0Lg0KDQoqIENvbmdlc3Rpb24gY29u dHJvbCBmb3IgRUNUKDEpLCBMNFMgOiBNeSBmZWVsaW5nIGlzIHRoYXQgaXQgaXMgZm9yIG5vdyBP SyB0byBsZWF2ZSB0aGlzIGFzIGZ1dHVyZSB3b3JrLiBUaGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0 aGVyZSBhcmUgYWJzb2x1dGVseSBubyBpZGVhcyBvbiBob3cgdG8gaW1wbGVtZW50IHRoaXMsIGZv ciBzaG9ydCBSVFQgZW52aXJvbm1lbnRzIERDVENQIHN0eWxlIGNvbmdlc3Rpb24gY29udHJvbCBp cyBxdWl0ZSBPSy4gRnVydGhlcm1vcmUgSSBhbmQgcmVjZW50bHkgd29ya2VkIG9uIGEgTDRTIGNv bmdlc3Rpb24gY29udHJvbCB0aGF0IGlzIGJhc2VkIG9uIEJCUiwgdGhlIHJlc3VsdHMgbG9vayBx dWl0ZSBwcm9taXNpbmcgYW5kIHRoZSBjaGFuZ2VzIHRvIHRoZSBCQlIgYWxnb3JpdGhtIGFyZSBx dWl0ZSBtaW5pbWFsLiBJIGFtIHdpbGxpbmcgdG8gcHJlc2VudCB0aGlzIGF0IElDQ1JHIGluIExv bmRvbiBpZiB0aGVyZSBpcyBhbnkgaW50ZXJlc3QgaW4gdGhpcy4NCiogRUNOIGluIFFVSUMgdjEg b3IgbGF0ZXIgOiBJIHdvdWxkIHZlcnkgbXVjaCBwcmVmZXIgdGhhdCBFQ04gc3VwcG9ydCBnb2Vz IGludG8gdjEuIE9uIHRoZSB0ZWNobmljYWwgc2lkZSBpdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBl eHBlcmltZW50IHdpdGggRUNOLCBwb3RlbnRpYWxseSBvbiBhIGxhcmdlciBzY2FsZS4gT24gdGhl IHBvbGl0aWNhbCBzaWRlIGl0IGhlbHBzIHRvIG1ha2UgdGhlIOKAnGNoaWNrZW4gYW5kIGVnZ+KA nSBwcm9ibGVtIGJlY29tZSBoaXN0b3J5Lg0KDQovSW5nZW1hcg0KPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQpNYXN0ZXIgUmVzZWFy Y2hlcg0KDQpFcmljc3NvbiBSZXNlYXJjaA0KTmV0d29yayBQcm90b2NvbHMgJiBFMkUgUGVyZm9y bWFuY2UNCkxhYnJhdG9yaWVncsOkbmQgMTENCjk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NClBob25l ICs0Ni0xMDcxIDQzMDQyDQpTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0KaW5nZW1hci5zLmpvaGFu c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t Pg0Kd3d3LmVyaWNzc29uLmNvbTxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cC0zQV9fd3d3LmVyaWNzc29uLmNvbSZkPUR3TUdhUSZjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09 eFZ6SUE5ZjdXaks4Q1ZJUTNCLXY5Wk5sLVVmOEhDWTRuWVBiMGZNUk8tNCZzPXR5U2lNbGdUeUlU OElKbWFLWVMteU1ZQk5qMFlVd19NMjQ2aFg0c3pLWjQmZT0+DQoNClRoZSB3b3JsZCBpcyBmdWxs IG9mIG1hZ2ljYWwgdGhpbmdzIHBhdGllbnRseQ0KICAgIHdhaXRpbmcgZm9yIG91ciB3aXRzIHRv IGdyb3cgc2hhcnBlcg0KICAgICAgICAgICAgICAgQmVydHJhbmQgUnVzc2VsbA0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQo= --_000_660743ab697443f4ac5500e649a80285usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBF bW9qaSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjEN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg NzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjU4Nzc3 Mjc0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MzAz Mzk5MDYgMTYxMTAyMTc4NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ bWFyZ2luLWxlZnQ6MjAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDo1Ni4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5Mi4yNXB0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEyOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxNjQu MjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAwLjI1cHQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJbWFyZ2luLWxlZnQ6MjM2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjI3Mi4yNXB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozMDguMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE4 NzkzOTQwNDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0yMjE5ODE0ODggMTM1NDM5MzA3MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5 MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGJlbGlldmUgdGhlIHByaW1hcnkgY29uY2VybiBkdXJpbmcgdGhlIG1lZXRpbmcgeWVzdGVyZGF5 IHdhcyB0aGUgRUNOIGZlZWRiYWNrIGZvcm1hdCAoY291bnRlcnMpLiZuYnNwOyBIZXJlIGlzIHRo ZSBhbHRlcm5hdGl2ZSwgc2ltaWxhciB0byB3aGF0IENocmlzdGlhbiB2b2ljZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gbWFraW5nIHRoZXNlIGFzc3VtcHRpb25zOjxvOnA+PC9vOnA+ PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuNzVwdDttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+DQpDRSBpcyBub3QgZ29pbmcgdG8gYmUgYSB2ZXJ5IGNvbW1vbiBvY2N1 cnJlbmNlPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi0xNS43NXB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBlbmRw b2ludCB3aWxsIHVzdWFsbHkgZWl0aGVyIHNlbmQgKGFsbW9zdCkgYWxsIHBhY2tldHMgd2l0aCBu byBFQ1QgbWFya2luZ3MsIG9yIGl0IHdpbGwgc2VuZCAoYWxtb3N0KSBhbGwgcGFja2V0cyB3aXRo IGEgc3BlY2lmaWMgRUNUIChFQ1RbMF0gb3IgRUNUWzFdKS48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQiPk5vbmUgb2Yg dGhlc2UgYXNzdW1wdGlvbnMgYXJlIHJlcXVpcmVkLiZuYnNwOyBUaGV5IGFyZSBqdXN0IHVzZWQg dG8gaWRlbnRpZnkg4oCcY29tbW9uIGNhc2Vz4oCdIGFuZCBzYXZlIGEgZmV3IGJ5dGVzIHBlciBB Q0sgZnJhbWUuJm5ic3A7IFdlIG1heSBkaXNjYXJkIHRoZXNlIGFzc3VtcHRpb25zIGFuZCB0aGUg b3B0aW1pemF0aW9ucy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoyLjI1cHQiPlRoZSB3b3JzdCBjYXNlIGZvciB0aGlzIHByb3Bvc2FsIGlz IGEgY2FzZSB3aGVuIEVDVFswXSBhbmQgRUNUWzFdIG1hcmtpbmcgYWx0ZXJuYXRlLCBiZWNhdXNl IHRoYXQgcHJldmVudHMgYWNrbm93bGVkZ2luZyBjb25zZWN1dGl2ZSBwYWNrZXRzIGFzIGEgYmxv Y2suJm5ic3A7IE15IGluY2xpbmF0aW9uIGlzIHRvIGRpcmVjdCB0aGUgc2VuZGVyIHRvIGp1c3Qg bm90IGRvIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6Mi4yNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4y NXB0Ij5QYXJ0IDEuIFByaW1hcnkgRUNUPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RHVyaW5nIHRoZSBoYW5kc2hha2UsIGVhY2ggZW5kcG9pbnQgbm90aWZpZXMg dGhlIG90aGVyIG9mIHRoZSBFQ1QgY29kZXBvaW50IChFQ1RbMF0gb3IgRUNUWzFdKSB0aGF0IGlz IGludGVuZHMgdG8gdXNlIHByaW1hcmlseS4mbmJzcDsgVGhpcyBpcyBrbm93biB0aGUgUHJpbWFy eSBFQ1QuJm5ic3A7IEJ5IGRlZmF1bHQsIEVDVFswXSBpcyB0aGUgUHJpbWFyeSBFQ1QuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGFydCAyLiZuYnNwOyBUd28gQUNLIHZhcmlldGllczxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byBBQ0sgRnJhbWUsIHdlIGludHJvZHVj ZSBhIG5ldyBBQ0stRUNUIGZyYW1lLiZuYnNwOyBUaGUgY29udGVudHMgb2YgdGhlIGZyYW1lcyBh cmUgaWRlbnRpY2FsIGFuZCB1bmNoYW5nZWQgZnJvbSB0aGUgY3VycmVudCBBQ0sgZnJhbWUgY29u dGVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgcGFja2V0cyBh Y2tub3dsZWRnZWQgYnkgdGhlIEFDSyBGcmFtZSBhcmUgcGFja2V0cyB0aGF0IGhhdmUgbm8gRUNO IGJpdHMgc2V0IGF0IGFsbC4mbmJzcDsgQWxsIHBhY2tldHMgYWNrbm93bGVkZ2VkIGJ5IHRoZSBB Q0stRUNUIEZyYW1lIGFyZSBwYWNrZXRzIHRoYXQgaGF2ZSBQcmltYXJ5IEVDVCBjb2RlIHBvaW50 LiZuYnNwOyBJdCBpcyBleHBlY3RlZCB0aGF0IGluIHRoZSBjb21tb24gY2FzZSwgYWxsIHBhY2tl dHMgd2lsbA0KIGJlIGFja25vd2xlZGdlZCBieSBBQ0sgb3IgQUNLLUVDVC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q YXJ0IDMuJm5ic3A7IEFDSy1FQ04tQklUTUFQPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBuZXcgQUNLLUVDTi1CSVRNQVAgZnJhbWUgaXMgdXNlZCB3aGVuIEFDSyBv ciBBQ0stRUNUIGZyYW1lcyBjYW5ub3QgYmUgdXNlZC4mbmJzcDsgSXRzIGZvcm1hdCBpcyB2ZXJ5 IHNpbWlsYXIgdG8gdGhlIGZvcm1hdCBvZiB0aGUgQUNLIGZyYW1lLCBleGNlcHQgdGhlcmUgaXMg YSBuZXcgRUNOIEJpdG1hcCBmaWVsZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fn5+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IExhcmdlc3QgQWNrbm93bGVkZ2VkIChpKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFDSyBEZWxheSAoaSkmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Li4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBQ0sgQmxvY2sgQ291bnQgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg RUNOIEJpdG1hcCAoKikmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBQ0sgQmxv Y2tzICgqKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5+fn48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPns6ICNhY2stZWNu LWJpdG1hcCBmb3JtYXQgdGl0bGU9JnF1b3Q7QUNLLUVDTi1CSVRNQVAgRnJhbWUgRm9ybWF0JnF1 b3Q7fTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmllbGRzIGluIHRoZSBBQ0stRUNOLUJJ VE1BUCBmcmFtZSBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFyZ2Vz dCBBY2tub3dsZWRnZWQ6Jm5ic3A7IChTQU1FIEFTIElOIEFDSyBGUkFNRSk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QUNLIERlbGF5OiZuYnNwOyAoU0FNRSBBUyBJTiBBQ0sgRlJBTUUpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFDSyBCbG9jayBDb3VudDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNBTUUgQVMgSU4gQUNLIEZSQU1FLCBleGNlcHQgcGFja2V0cyBpbiBl YWNoIEFDSyBCbG9jayBNVVNUIGhhdmUgdGhlIHNhbWUgRUNOIG1hcmtpbmcuJm5ic3A7IFRoaXMg bWF5IGNhdXNlIGJsb2NrcyBvZiBjb25zZWN1dGl2ZSBwYWNrZXRzIHRvIGJlIHNwbGl0IGludG8g bXVsdGlwbGUgQUNLIEJsb2NrcyAod2l0aCBHYXA9MCBpbiBiZXR3ZWVuKSwgaWYgdGhvc2UgcGFj a2V0cyBoYXZlIGRpZmZlcmVudCBFQ04gbWFya2luZ3MuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkVDTiBCaXRtYXA6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHNlcXVl bmNlIG9mIEFDSyBCbG9jayBDb3VudCBwYWlycyBvZiBiaXRzIHRoYXQgaW5kaWNhdGUgRUNOIG1h cmtpbmdzIGZvciB0aGUgY29ycmVzcG9uZGluZyBBQ0sgQmxvY2suJm5ic3A7IFRoZSBzaXplIG9m IHRoZSBFQ04gQml0bWFwIGZpZWxkIGlzIENlaWxpbmcoKDEmIzQzO+KAnEFDSyBCbG9jayBDb3Vu dOKAnSkvNCkgb2N0ZXRzLiZuYnNwOyBUaGUgdW51c2VkIGJpdHMgc2hvdWxkIGJlIHNldCB0byAw LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGV4YW1wbGU6PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5+fn48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgMSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IDM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnxBQXxCQnxDQ3xERHzigKY8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpdHMgQUEgcmVwcmVzZW50IEVDTiBiaXRzIGZv ciBwYWNrZXRzIGFja25vd2xlZGdlZCBpbiB0aGUgRmlyc3QgQUNLIEJsb2NrLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Qml0cyBCQiByZXByZXNlbnQgRUNOIGJpdHMgZm9y IHBhY2tldHMgYWNrbm93bGVkZ2VkIGluIEFkZGl0aW9uYWwgQUNLIEJsb2NrIDAuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaXRzIENDIHJlcHJlc2VudCBFQ04gYml0cyBm b3IgcGFja2V0cyBhY2tub3dsZWRnZWQgaW4gQWRkaXRpb25hbCBBQ0sgQmxvY2sgMTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFDSyBCbG9ja3M6IChTQU1FIEFTIElOIEFDSyBGUkFNRSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+SWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSW5nZW1hciBKb2hhbnNz b24gUyBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNCwgMjAxOCAzOjAxIEFNPGJyPg0KPGI+VG86 PC9iPiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBF Q04gaW4gUVVJQzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBmZXcgaW1wcmVzc2lvbnMgb24gdGhlIEVDTiBpbiBRVUlD IGRpc2N1c3Npb25zLiBUaGUgYXVkaW8gd2FzIHNvLXNvLCBmcmVxdWVudCBpbnRlcnJ1cHRpb25z IGFuZCBMQVJHRSBkaWZmZXJlbmNlcyBpbiBhdWRpbyBsZXZlbCAmIzQzOyBiYWRseSBpbXBsZW1l bnRlZCBlYXJzDQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkm cXVvdDssc2Fucy1zZXJpZiI+JiMxMjg1MjI7PC9zcGFuPiwgc28gc29tZXRpbWVzIEkgbWlzc2Vk IHRoZSBkZXRhaWxzIGFuZCBwb3NzaWJseSBraWNrIGluIG9wZW4gZG9vcnMuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+KiAmbmJzcDtGZWVkYmFjayBmb3JtYXQuIEkgdW5kZXJzdGFuZCB0aGF0 IHRoZSBwcm9wb3NlZCBwcm9wb3NhbCBiYXNlZCBvbiBFQ1QoMCksIEVDVCgxKSBhbmQgQ0UgY291 bnRlcnMgZG9lcyBub3QgcGxheSB3ZWxsIHdpdGggY29ubmVjdGlvbiBtaWdyYXRpb24uIEkgYmVs aWV2ZSwgYnV0IEkgYW0gbm90IDEwMCUgc3VyZSB0aGF0IEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxl bS4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgYXJlDQogdHdvIGNvbmNlcm5zIChwZXJoYXBzIG1v cmU/KTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAxLiBDb3Vu dGVycyBhcmUgcmVzZXQsIHRoaXMgbWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIGEgcG90ZW50aWFs bHkgdmVyeSBsYXJnZSAobmVnYXRpdmU/KSBkaWZmZXJlbmNlIGluIENFIG1hcmtlZCBwYWNrZXRz LiBJIGJlbGlldmUgdGhhdCB0aGlzIGNhbiBiZSBkZXRlY3RlZCBhcyBmYWxzZSBjb25nZXN0aW9u IHNpZ25hbCBhbmQgaWdub3JlZCBieSB0aGUgY29uZ2VzdGlvbiBzaWduYWwuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMi4gRGlmZmljdWx0aWVzIHRvIGRldGVj dCBFQ04gYmxlYWNoaW5nLiBJdCBpcyB0cmlja3kgdG8gdW5kZXJzdGFuZCBpZiBwYWNrZXRzIGFs b25nIHRoZSBuZXcgcGF0aCBhcmUgYmxlYWNoZWQgYmFzZWQgb24gdGhlIEVDVCBjb3VudGVycy4g VGhpcyBjYW4gYmUgYSBtb3JlIGNvbXBsaWNhdGVkIGNhc2UuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiBhbnkgY2FzZSBpdCB3YXMgc3VnZ2VzdGVkIHRvIGluZGljYXRl IHRoZSBFQ04gYml0cyBmb3IgdGhlIHBhY2tldHMgaW4gdGhlIEFDSyBmcmFtZS4gU3VjaCBhIGZv cm1hdCB3YXMgYWN0dWFsbHkgb3V0bGluZWQgaW4gZWFybGllciBwcm9wb3NhbCAoc2VlIHBhZ2Ug NiwgRmlndXJlIDMgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGpvaGFuc3Nv bi0yRHF1aWMtMkRlY24tMkQwMSZhbXA7ZD1Ed01HYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFt cDttPXhWeklBOWY3V2pLOENWSVEzQi12OVpObC1VZjhIQ1k0bllQYjBmTVJPLTQmYW1wO3M9Uzlh cWM4VUlHYVREWDNaTXMxVlR5V2lMU1NHMDFuZEZoaHJfWmcwMUgxWSZhbXA7ZT0iPg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMTwvYT4gKS4g SXQgaXMgT2sgd2l0aCBtZSB0byBjaGFuZ2UgdG8gYSBmb3JtYXQgc2ltaWxhciB0byB0aGlzIGlm IHRoZSBncm91cCBwcmVmZXJzIHRoYXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogQ29uZ2Vz dGlvbiBjb250cm9sIGZvciBFQ1QoMSksIEw0UyA6IE15IGZlZWxpbmcgaXMgdGhhdCBpdCBpcyBm b3Igbm93IE9LIHRvIGxlYXZlIHRoaXMgYXMgZnV0dXJlIHdvcmsuIFRoYXQgZG9lcyBub3QgbWVh biB0aGF0IHRoZXJlIGFyZSBhYnNvbHV0ZWx5IG5vIGlkZWFzIG9uIGhvdyB0byBpbXBsZW1lbnQg dGhpcywgZm9yIHNob3J0IFJUVCBlbnZpcm9ubWVudHMgRENUQ1Agc3R5bGUgY29uZ2VzdGlvbiBj b250cm9sDQogaXMgcXVpdGUgT0suIEZ1cnRoZXJtb3JlIEkgYW5kIHJlY2VudGx5IHdvcmtlZCBv biBhIEw0UyBjb25nZXN0aW9uIGNvbnRyb2wgdGhhdCBpcyBiYXNlZCBvbiBCQlIsIHRoZSByZXN1 bHRzIGxvb2sgcXVpdGUgcHJvbWlzaW5nIGFuZCB0aGUgY2hhbmdlcyB0byB0aGUgQkJSIGFsZ29y aXRobSBhcmUgcXVpdGUgbWluaW1hbC4gSSBhbSB3aWxsaW5nIHRvIHByZXNlbnQgdGhpcyBhdCBJ Q0NSRyBpbiBMb25kb24gaWYgdGhlcmUgaXMgYW55IGludGVyZXN0DQogaW4gdGhpcy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiogRUNOIGluIFFVSUMgdjEgb3IgbGF0ZXIg OiBJIHdvdWxkIHZlcnkgbXVjaCBwcmVmZXIgdGhhdCBFQ04gc3VwcG9ydCBnb2VzIGludG8gdjEu IE9uIHRoZSB0ZWNobmljYWwgc2lkZSBpdCBtYWtlcyBpdCBwb3NzaWJsZSB0byBleHBlcmltZW50 IHdpdGggRUNOLCBwb3RlbnRpYWxseSBvbiBhIGxhcmdlciBzY2FsZS4gT24gdGhlIHBvbGl0aWNh bCBzaWRlIGl0IGhlbHBzIHRvIG1ha2UgdGhlIOKAnGNoaWNrZW4gYW5kDQogZWdn4oCdIHByb2Js ZW0gYmVjb21lIGhpc3RvcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9u ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9z cGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JbmdlbWFyIEpvaGFuc3NvbiZuYnNwOyBNLlNjLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hc3RlciBSZXNlYXJjaGVyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNl Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Fcmljc3NvbiBSZXNlYXJjaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5OZXR3b3Jr IFByb3RvY29scyAmYW1wOyBFMkUgUGVyZm9ybWFuY2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+TGFicmF0b3JpZWdyw6RuZCAxMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj45 NzEgMjgsIEx1bGXDpSwgU3dlZGVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBob25l ICYjNDM7NDYtMTA3MSA0MzA0Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TTVMvTU1T ICYjNDM7NDYtNzMgMDc4IDMyODk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJl Zj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X3d3dy5lcmljc3Nvbi5jb20mYW1wO2Q9RHdNR2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZM WmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7 bT14VnpJQTlmN1dqSzhDVklRM0ItdjlaTmwtVWY4SENZNG5ZUGIwZk1STy00JmFtcDtzPXR5U2lN bGdUeUlUOElKbWFLWVMteU1ZQk5qMFlVd19NMjQ2aFg0c3pLWjQmYW1wO2U9Ij53d3cuZXJpY3Nz b24uY29tPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tncm91bmQ6I0NDQ0NE RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMztiYWNr Z3JvdW5kOndoaXRlIj5UaGUgd29ybGQgaXMgZnVsbCBvZiBtYWdpY2FsIHRoaW5ncyBwYXRpZW50 bHkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0 ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzM7YmFja2dyb3Vu ZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2FpdGluZyBmb3Igb3VyIHdpdHMgdG8g Z3JvdyBzaGFycGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMzti YWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVydHJhbmQgUnVz c2VsbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_660743ab697443f4ac5500e649a80285usma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 12:52:11 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83EC129966 for ; Wed, 24 Jan 2018 12:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 LwYuNJVX7hFn for ; Wed, 24 Jan 2018 12:52:05 -0800 (PST) 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 6D5CF129511 for ; Wed, 24 Jan 2018 12:52:04 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-e3-5a68f1f2ddbd Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.F5.13339.2F1F86A5; Wed, 24 Jan 2018 21:52:02 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 24 Jan 2018 21:52:02 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O4cQnEUF7hrH3CmjdAoWqnpo4wQoaDNMSUQuewWWbvI=; b=bIWNRgVmxl+5R1It6fH+haXQzkLwOB+mf7ARvMBPNvF4ilH990oJ1h3gmSRtrhHishhaZJ0tmNlZVDVkEBVhfmCLrX9DBvOBZg2yBK025FXD7MjVcOq+V7o/9O4ax7gpOWY7eUCPB2Uhn/1hYJ8xz+GZaD+346+vjIZdzZ8LKNM= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3769.eurprd07.prod.outlook.com (52.133.7.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 20:51:59 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c%13]) with mapi id 15.20.0444.016; Wed, 24 Jan 2018 20:51:59 +0000 From: Ingemar Johansson S To: "Lubashev, Igor" , QUIC WG , "huitema (huitema@huitema.net)" CC: "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" , Ingemar Johansson S Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1A= Date: Wed, 24 Jan 2018 20:51:59 +0000 Message-ID: References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.226.2.151] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3769; 7:aukLFUXUwB9qmA5rqYxnQKeVYKz5y1LkgWwPuMhSfdlg3Q0UR+ToxSHrP6zpAREtXqWuUhYZBWCfFhAfBwXX+ewDPPvHvwlcb941Gz3FZcUQ+dvmrmuU2ttdJ5Es7uuokUGAs6tEN+wOo3mYiReCUllDWBHlSownGZuX7Ai638iEYKblRA7PtuaUVwE3JxWitRlWlys1da9GZVXQsF/y0m+ZBYyp8mU0+EWZOQYwBeA3zRrVSbTrSvKolWLBsWYD x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(39380400002)(346002)(366004)(396003)(39860400002)(199004)(189003)(68736007)(7736002)(9326002)(8676002)(81166006)(81156014)(3480700004)(8936002)(74316002)(14454004)(3660700001)(76176011)(6506007)(53546011)(19609705001)(478600001)(99286004)(7116003)(55016002)(7696005)(5250100002)(59450400001)(9686003)(54896002)(186003)(102836004)(106356001)(3280700002)(26005)(6246003)(107886003)(6306002)(53936002)(5660300001)(6436002)(6346003)(33656002)(966005)(2906002)(229853002)(66066001)(2950100002)(561944003)(110136005)(105586002)(2900100001)(6116002)(316002)(3846002)(790700001)(4326008)(236005)(54906003)(606006)(25786009)(97736004)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3769; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 95dc6228-0491-4b00-1464-08d5636c5023 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3769; x-ms-traffictypediagnostic: HE1PR0702MB3769: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(10436049006162)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231046)(2400081)(944501161)(3002001)(6041288)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0702MB3769; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3769; x-forefront-prvs: 056297E276 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-microsoft-antispam-message-info: +he0wus8Yme1OamvcS6yNYo1kq+UY14MW2oGeynDmz6jr0rVeNc3X7kVX3nvqxn4mnw6/WTJVc5y6v4FZ/NWDA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB3625648A6943055201D46DCEC2E20HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 95dc6228-0491-4b00-1464-08d5636c5023 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 20:51:59.3168 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3769 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfSzUcRzH9/093P2OTr885INs3KawQmntFkN/WKdWaz1Yu61x+MUtjt3J urR5GAlneV7EXDqJlBWOmi2OkYee0ArrbhaKXCsrJku5+/3a/Pf6fN7vz9N3Xwq3HyVdKbki lVEqZIking1Rdb7Td9/yjwRpQPO8i7gs6zZfnJ15HxcPrDRgYo3WVjxTmY3CSElZvxaXLJre kJKpW8OERKdbwyTZK/W8U6TUJjiOSZSnMUr/kGibBN2qnp9yrwW/0jU/QWai8jt4ARJQQB+E 778WsQJkQ9nTfQiMtWaCDV4gmKrIswYEvYyBsWgSsUolBq2T+ZztM4LGhRt8SzMeHQxNhlVk YUf6Guhahq0VOD2G4OWjFZ5FcKABtAOlGGtygW8/cwmWD4N5ZNrKBO0F84anVo+QjoaVinmc ndaEoEQzTloEAX0G2jrN1jMQ7Q6mVaO1GKedYWq2DmPPo0HX/Zo71QkWPm2QLHvAx1Itx+4w Vldo3RRoPQazpg6uOBAKirtJVnjLgwfvcrhOJ2Cp8TrOCsMI3s994Sr2Ql7bQ46ToaC6HrGc Ds39PdyIGhzWX1VznXaBYe0DUYz8qresznIyPF/KIqqtb7ADhqpmN5nazPtA6zN/1uIJ5YUz fJa9Ibemlr81r0X8ZuSkYlQxSfEHAv0YpTxWpUpW+CmY1Cdo84/1tq97daHxpSMGRFNItE3Y N50gtSdlaSp1kgEBhYscheN5mylhnEx9lVEmRykvJzIqA3KjCJGzcChCKLWn42WpzCWGSWGU /1WMErhmIvEFPfU4I0hXkt47mW4XYwxpkJefDY3WC46V3wx1+N0So1HYbbh5qVtEHkepwRud x8N2iuyUHZF/9kh2j4SLAooybM2u0xq/2PX+uxNizVy4adC70Gt7YYg5MmKDrG9vO9R1Wlc3 kt/jGXTx70L9SfW5qByf8eWu0eivw8YmzENEqBJk+31xpUr2DxhKSrxfAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 20:52:09 -0000 --_000_HE1PR0702MB3625648A6943055201D46DCEC2E20HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KQ29tbWVudCBvbiDigJxDRSBpcyBub3QgZ29pbmcgdG8gYmUgYSB2ZXJ5IGNvbW1vbiBv Y2N1cnJlbmNl4oCdLg0KV2hpbGUgdGhhdCBtYXkgYmUgdHJ1ZSBmb3IgKGFsbW9zdCkgZHJvcCBl cXVpdmFsZW50IEVDTiAoYS5rLmEuIGNsYXNzaWMpLCBpdCBkb2VzIHVuZm9ydHVuYXRlbHkgbm90 IGhvbGQgYXQgYWxsIGZvciBMNFMuIFR5cGljYWwgdmFsdWVzIG9mIEVDTiBtYXJraW5nIHJhdGlv IHdpdGggTDRTIGlzIGluIHRoZSBvcmRlciBvZiAxMCB0byA1MCUuIEluIGFkZGl0aW9uIHRoZSBD RSBtYXJrcyBjYW4gYmUgc3ByZWFkIHJhbmRvbWx5IChmb3IgaW5zdGFuY2Ugd2l0aCBwaGFudG9t IHF1ZXVlcykuDQpUaGlzIG1lYW5zIHRoYXQgdGhlIEFDSyBibG9ja3MgaW4gdGhlIHN1Z2dlc3Rl ZCBmb3JtYXQgYmVsb3cgY2FuIGJlY29tZSB2ZXJ5IHNob3J0LCBpbiB0aGUgd29yc3QgY2FzZSBy ZXByZXNlbnRpbmcgb25seSBvbmUgcGFja2V0IHBlciBBQ0sgYmxvY2sgaWYgd2UgaGF2ZSBhbiBh bHRlcm5hdGluZyBFQ1QtQ0UtRUNULUNF4oCmIHBhdHRlcm4gaW4gdGhlIHJlY2VpdmVkIHBhY2tl dHMuDQoNClNvIG15IHRha2UgaXMgdGhhdCBpZiBhbiBFQ04gYml0IHBhdHRlcm4gaXMgcmVhbGx5 IG5lY2Vzc2FyeSB0aGVuIGl0IGlzIGJldHRlciB0byBoYXZlIGl0IGFzIGFuIGJpdG1hcCB0aGF0 IHJlcHJlc2VudHMgYWxsIHBhY2tldHMgdGhhdCBhcmUgbGlzdGVkIGluIHRoZSBBQ0sgYmxvY2su IElmIG9uZSBtYWtlIGFuIGFzc3VtcHRpb24gdGhhdCBhbiBBQ0sgZnJhbWUgY29udGFpbnMgdHdv IEFDSyBibG9ja3MgdGhhdCBBQ0tzIDUgYW5kIDcgcGFja2V0cyB0aGVuIHRoZSBFQ04gYmxvY2sg d2lsbCBiZWNvbWUgKDUrNykqMiA9IDI0Yml0cyAsIGkuZS4gMyBvY3RldHMuDQoNCkJ1dCB3aXRo IHRoYXQgc2FpZCBJIGFtIHN0aWxsIG5vdCBjb252aW5jZWQgdGhhdCB0aGUgcGFja2V0IGNvdW50 ZXIgYXBwcm9hY2ggaXMgZmxhd2VkIChJ4oCZbSBhbSBoYXBweSB0byBiZSBlbmxpZ2h0ZW5lZCDw n5iKKSAuDQpUYWtpbmcgbXVsdGlwYXRoIGFzIGFuIGV4YW1wbGUgOiBJc27igJl0IGl0IHRoZSBj YXNlIHRoYXQgdHdvIGNvbm5lY3Rpb25zIGFyZSBzZXR1cCwgZWFjaCB3aXRoIGl0cyBvd24gY29u Z2VzdGlvbiBjb250cm9sIGNvbnRleHQgKEkgb21pdCBjb3VwbGVkIENDIGZvciB0aGUgbW9tZW50 KS4gSWYgdGhhdCBpcyB0aGUgY2FzZSB0aGVuIEkgZG9u4oCZdCBzZWUgYW55IHByb2JsZW0gd2l0 aCB0aGUgcGFja2V0IGNvdW50ZXJzLg0KQXMgcmVnYXJkcyB0byBjb25uZWN0aW9uIG1pZ3JhdGlv bi4gT25lIHBvc3NpYmxlIG1hdHRlciBpcyB0aGF0IGl0IGNhbiBiZWNvbWUgdHJpY2t5IHRvIGRl dGVjdCBFQ04gYmxlYWNoaW5nIG9yIEVDTiBiaXQgYWNjZXNzIHByb2JsZW1zIGluIE9TIGltbWVk aWF0ZWx5ICwgaG93ZXZlciBkdXJpbmcgdGhlIGNvdXJzZSBvZiAxIFJUVCBvciBldmVuIGxlc3Ms IHRoaXMgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRldGVjdCBhcyBlLmcuIEVDTiBibGVhY2hpbmcg d2lsbCByZXN1bHQgaW4gdGhhdCB0aGUgbmVpdGhlciBvbiB0aGUgRUNUKDApLEVDVCgxKSBhbmQg Q0UgY291bnRlcnMgaW5jcmVhc2UuIEJ1dCBJIGFtIGZ1bGx5IGF3YXJlIHRoYXQgSSBtYXkgbWlz cyB0aGluZ3MgaGVyZS4NCg0KDQovSW5nZW1hcg0KDQoNCg0KRnJvbTogTHViYXNoZXYsIElnb3Ig W21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXQ0KU2VudDogZGVuIDI0IGphbnVhcmkgMjAxOCAx OTowMg0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz b24uY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IGh1aXRlbWEgKGh1aXRlbWFAaHVpdGVt YS5uZXQpIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUkU6IEVDTiBpbiBRVUlDDQoN CkkgYmVsaWV2ZSB0aGUgcHJpbWFyeSBjb25jZXJuIGR1cmluZyB0aGUgbWVldGluZyB5ZXN0ZXJk YXkgd2FzIHRoZSBFQ04gZmVlZGJhY2sgZm9ybWF0IChjb3VudGVycykuICBIZXJlIGlzIHRoZSBh bHRlcm5hdGl2ZSwgc2ltaWxhciB0byB3aGF0IENocmlzdGlhbiB2b2ljZWQuDQoNCkkgYW0gbWFr aW5nIHRoZXNlIGFzc3VtcHRpb25zOg0KDQogICogICBDRSBpcyBub3QgZ29pbmcgdG8gYmUgYSB2 ZXJ5IGNvbW1vbiBvY2N1cnJlbmNlDQogICogICBUaGUgZW5kcG9pbnQgd2lsbCB1c3VhbGx5IGVp dGhlciBzZW5kIChhbG1vc3QpIGFsbCBwYWNrZXRzIHdpdGggbm8gRUNUIG1hcmtpbmdzLCBvciBp dCB3aWxsIHNlbmQgKGFsbW9zdCkgYWxsIHBhY2tldHMgd2l0aCBhIHNwZWNpZmljIEVDVCAoRUNU WzBdIG9yIEVDVFsxXSkuDQpOb25lIG9mIHRoZXNlIGFzc3VtcHRpb25zIGFyZSByZXF1aXJlZC4g IFRoZXkgYXJlIGp1c3QgdXNlZCB0byBpZGVudGlmeSDigJxjb21tb24gY2FzZXPigJ0gYW5kIHNh dmUgYSBmZXcgYnl0ZXMgcGVyIEFDSyBmcmFtZS4gIFdlIG1heSBkaXNjYXJkIHRoZXNlIGFzc3Vt cHRpb25zIGFuZCB0aGUgb3B0aW1pemF0aW9ucy4NClRoZSB3b3JzdCBjYXNlIGZvciB0aGlzIHBy b3Bvc2FsIGlzIGEgY2FzZSB3aGVuIEVDVFswXSBhbmQgRUNUWzFdIG1hcmtpbmcgYWx0ZXJuYXRl LCBiZWNhdXNlIHRoYXQgcHJldmVudHMgYWNrbm93bGVkZ2luZyBjb25zZWN1dGl2ZSBwYWNrZXRz IGFzIGEgYmxvY2suICBNeSBpbmNsaW5hdGlvbiBpcyB0byBkaXJlY3QgdGhlIHNlbmRlciB0byBq dXN0IG5vdCBkbyB0aGlzLg0KDQoNCg0KUGFydCAxLiBQcmltYXJ5IEVDVA0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCkR1cmluZyB0aGUgaGFuZHNoYWtlLCBlYWNoIGVuZHBvaW50IG5vdGlm aWVzIHRoZSBvdGhlciBvZiB0aGUgRUNUIGNvZGVwb2ludCAoRUNUWzBdIG9yIEVDVFsxXSkgdGhh dCBpcyBpbnRlbmRzIHRvIHVzZSBwcmltYXJpbHkuICBUaGlzIGlzIGtub3duIHRoZSBQcmltYXJ5 IEVDVC4gIEJ5IGRlZmF1bHQsIEVDVFswXSBpcyB0aGUgUHJpbWFyeSBFQ1QuDQoNCg0KUGFydCAy LiAgVHdvIEFDSyB2YXJpZXRpZXMNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cg0KSW4gYWRkaXRpb24gdG8gQUNLIEZyYW1lLCB3ZSBpbnRyb2R1Y2UgYSBuZXcgQUNLLUVDVCBm cmFtZS4gIFRoZSBjb250ZW50cyBvZiB0aGUgZnJhbWVzIGFyZSBpZGVudGljYWwgYW5kIHVuY2hh bmdlZCBmcm9tIHRoZSBjdXJyZW50IEFDSyBmcmFtZSBjb250ZW50cy4NCkFsbCBwYWNrZXRzIGFj a25vd2xlZGdlZCBieSB0aGUgQUNLIEZyYW1lIGFyZSBwYWNrZXRzIHRoYXQgaGF2ZSBubyBFQ04g Yml0cyBzZXQgYXQgYWxsLiAgQWxsIHBhY2tldHMgYWNrbm93bGVkZ2VkIGJ5IHRoZSBBQ0stRUNU IEZyYW1lIGFyZSBwYWNrZXRzIHRoYXQgaGF2ZSBQcmltYXJ5IEVDVCBjb2RlIHBvaW50LiAgSXQg aXMgZXhwZWN0ZWQgdGhhdCBpbiB0aGUgY29tbW9uIGNhc2UsIGFsbCBwYWNrZXRzIHdpbGwgYmUg YWNrbm93bGVkZ2VkIGJ5IEFDSyBvciBBQ0stRUNULg0KDQoNClBhcnQgMy4gIEFDSy1FQ04tQklU TUFQDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClRoZSBuZXcgQUNLLUVD Ti1CSVRNQVAgZnJhbWUgaXMgdXNlZCB3aGVuIEFDSyBvciBBQ0stRUNUIGZyYW1lcyBjYW5ub3Qg YmUgdXNlZC4gIEl0cyBmb3JtYXQgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBmb3JtYXQgb2YgdGhl IEFDSyBmcmFtZSwgZXhjZXB0IHRoZXJlIGlzIGEgbmV3IEVDTiBCaXRtYXAgZmllbGQuDQoNCn5+ fg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAg ICAgICAgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgIExhcmdlc3Qg QWNrbm93bGVkZ2VkIChpKSAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAg ICAgICAgICAgICAgICAgICBBQ0sgRGVsYXkgKGkpICAgICAgICAgICAgICAgICAgICAgIC4uLg0K Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCnwgICAgICAgICAgICAgICAgICAgICAgIEFDSyBCbG9jayBDb3VudCAoaSkgICAg ICAgICAgICAgICAgICAgLi4uDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAg RUNOIEJpdG1hcCAoKikgICAgICAgICAgICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAg ICAgICAgICAgICAgICAgICAgICBBQ0sgQmxvY2tzICgqKSAgICAgICAgICAgICAgICAgICAgIC4u Lg0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCn5+fg0KezogI2Fjay1lY24tYml0bWFwIGZvcm1hdCB0aXRsZT0iQUNLLUVD Ti1CSVRNQVAgRnJhbWUgRm9ybWF0In0NCg0KVGhlIGZpZWxkcyBpbiB0aGUgQUNLLUVDTi1CSVRN QVAgZnJhbWUgYXJlIGFzIGZvbGxvd3M6DQoNCkxhcmdlc3QgQWNrbm93bGVkZ2VkOiAgKFNBTUUg QVMgSU4gQUNLIEZSQU1FKQ0KDQpBQ0sgRGVsYXk6ICAoU0FNRSBBUyBJTiBBQ0sgRlJBTUUpDQoN CkFDSyBCbG9jayBDb3VudDoNClNBTUUgQVMgSU4gQUNLIEZSQU1FLCBleGNlcHQgcGFja2V0cyBp biBlYWNoIEFDSyBCbG9jayBNVVNUIGhhdmUgdGhlIHNhbWUgRUNOIG1hcmtpbmcuICBUaGlzIG1h eSBjYXVzZSBibG9ja3Mgb2YgY29uc2VjdXRpdmUgcGFja2V0cyB0byBiZSBzcGxpdCBpbnRvIG11 bHRpcGxlIEFDSyBCbG9ja3MgKHdpdGggR2FwPTAgaW4gYmV0d2VlbiksIGlmIHRob3NlIHBhY2tl dHMgaGF2ZSBkaWZmZXJlbnQgRUNOIG1hcmtpbmdzLg0KDQpFQ04gQml0bWFwOg0KQSBzZXF1ZW5j ZSBvZiBBQ0sgQmxvY2sgQ291bnQgcGFpcnMgb2YgYml0cyB0aGF0IGluZGljYXRlIEVDTiBtYXJr aW5ncyBmb3IgdGhlIGNvcnJlc3BvbmRpbmcgQUNLIEJsb2NrLiAgVGhlIHNpemUgb2YgdGhlIEVD TiBCaXRtYXAgZmllbGQgaXMgQ2VpbGluZygoMSvigJxBQ0sgQmxvY2sgQ291bnTigJ0pLzQpIG9j dGV0cy4gIFRoZSB1bnVzZWQgYml0cyBzaG91bGQgYmUgc2V0IHRvIDAuDQpGb3IgZXhhbXBsZToN Cn5+fg0KMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxDQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfEFBfEJCfENDfEREfOKApg0KKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cg0KQml0cyBBQSByZXByZXNlbnQgRUNOIGJpdHMgZm9yIHBhY2tldHMgYWNrbm93bGVkZ2VkIGlu IHRoZSBGaXJzdCBBQ0sgQmxvY2suDQpCaXRzIEJCIHJlcHJlc2VudCBFQ04gYml0cyBmb3IgcGFj a2V0cyBhY2tub3dsZWRnZWQgaW4gQWRkaXRpb25hbCBBQ0sgQmxvY2sgMC4NCkJpdHMgQ0MgcmVw cmVzZW50IEVDTiBiaXRzIGZvciBwYWNrZXRzIGFja25vd2xlZGdlZCBpbiBBZGRpdGlvbmFsIEFD SyBCbG9jayAxDQrigKYNCg0KQUNLIEJsb2NrczogKFNBTUUgQVMgSU4gQUNLIEZSQU1FKQ0KDQoN Cg0KICAqICAgSWdvcg0KDQoNCkZyb206IEluZ2VtYXIgSm9oYW5zc29uIFMgW21haWx0bzppbmdl bWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAy NCwgMjAxOCAzOjAxIEFNDQpUbzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBFQ04gaW4gUVVJQw0KDQpIaQ0KDQpBIGZldyBpbXByZXNzaW9u cyBvbiB0aGUgRUNOIGluIFFVSUMgZGlzY3Vzc2lvbnMuIFRoZSBhdWRpbyB3YXMgc28tc28sIGZy ZXF1ZW50IGludGVycnVwdGlvbnMgYW5kIExBUkdFIGRpZmZlcmVuY2VzIGluIGF1ZGlvIGxldmVs ICsgYmFkbHkgaW1wbGVtZW50ZWQgZWFycyDwn5iKLCBzbyBzb21ldGltZXMgSSBtaXNzZWQgdGhl IGRldGFpbHMgYW5kIHBvc3NpYmx5IGtpY2sgaW4gb3BlbiBkb29ycy4NCg0KKiAgRmVlZGJhY2sg Zm9ybWF0LiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcHJvcG9zZWQgcHJvcG9zYWwgYmFzZWQgb24g RUNUKDApLCBFQ1QoMSkgYW5kIENFIGNvdW50ZXJzIGRvZXMgbm90IHBsYXkgd2VsbCB3aXRoIGNv bm5lY3Rpb24gbWlncmF0aW9uLiBJIGJlbGlldmUsIGJ1dCBJIGFtIG5vdCAxMDAlIHN1cmUgdGhh dCBJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0uIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGFyZSB0 d28gY29uY2VybnMgKHBlcmhhcHMgbW9yZT8pOg0KICAxLiBDb3VudGVycyBhcmUgcmVzZXQsIHRo aXMgbWVhbnMgdGhhdCB0aGVyZSB3aWxsIGJlIGEgcG90ZW50aWFsbHkgdmVyeSBsYXJnZSAobmVn YXRpdmU/KSBkaWZmZXJlbmNlIGluIENFIG1hcmtlZCBwYWNrZXRzLiBJIGJlbGlldmUgdGhhdCB0 aGlzIGNhbiBiZSBkZXRlY3RlZCBhcyBmYWxzZSBjb25nZXN0aW9uIHNpZ25hbCBhbmQgaWdub3Jl ZCBieSB0aGUgY29uZ2VzdGlvbiBzaWduYWwuDQogIDIuIERpZmZpY3VsdGllcyB0byBkZXRlY3Qg RUNOIGJsZWFjaGluZy4gSXQgaXMgdHJpY2t5IHRvIHVuZGVyc3RhbmQgaWYgcGFja2V0cyBhbG9u ZyB0aGUgbmV3IHBhdGggYXJlIGJsZWFjaGVkIGJhc2VkIG9uIHRoZSBFQ1QgY291bnRlcnMuIFRo aXMgY2FuIGJlIGEgbW9yZSBjb21wbGljYXRlZCBjYXNlLg0KSW4gYW55IGNhc2UgaXQgd2FzIHN1 Z2dlc3RlZCB0byBpbmRpY2F0ZSB0aGUgRUNOIGJpdHMgZm9yIHRoZSBwYWNrZXRzIGluIHRoZSBB Q0sgZnJhbWUuIFN1Y2ggYSBmb3JtYXQgd2FzIGFjdHVhbGx5IG91dGxpbmVkIGluIGVhcmxpZXIg cHJvcG9zYWwgKHNlZSBwYWdlIDYsIEZpZ3VyZSAzIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDE8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJE am9oYW5zc29uLTJEcXVpYy0yRGVjbi0yRDAxJmQ9RHdNR2FRJmM9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT14VnpJ QTlmN1dqSzhDVklRM0ItdjlaTmwtVWY4SENZNG5ZUGIwZk1STy00JnM9UzlhcWM4VUlHYVREWDNa TXMxVlR5V2lMU1NHMDFuZEZoaHJfWmcwMUgxWSZlPT4gKS4gSXQgaXMgT2sgd2l0aCBtZSB0byBj aGFuZ2UgdG8gYSBmb3JtYXQgc2ltaWxhciB0byB0aGlzIGlmIHRoZSBncm91cCBwcmVmZXJzIHRo YXQuDQoNCiogQ29uZ2VzdGlvbiBjb250cm9sIGZvciBFQ1QoMSksIEw0UyA6IE15IGZlZWxpbmcg aXMgdGhhdCBpdCBpcyBmb3Igbm93IE9LIHRvIGxlYXZlIHRoaXMgYXMgZnV0dXJlIHdvcmsuIFRo YXQgZG9lcyBub3QgbWVhbiB0aGF0IHRoZXJlIGFyZSBhYnNvbHV0ZWx5IG5vIGlkZWFzIG9uIGhv dyB0byBpbXBsZW1lbnQgdGhpcywgZm9yIHNob3J0IFJUVCBlbnZpcm9ubWVudHMgRENUQ1Agc3R5 bGUgY29uZ2VzdGlvbiBjb250cm9sIGlzIHF1aXRlIE9LLiBGdXJ0aGVybW9yZSBJIGFuZCByZWNl bnRseSB3b3JrZWQgb24gYSBMNFMgY29uZ2VzdGlvbiBjb250cm9sIHRoYXQgaXMgYmFzZWQgb24g QkJSLCB0aGUgcmVzdWx0cyBsb29rIHF1aXRlIHByb21pc2luZyBhbmQgdGhlIGNoYW5nZXMgdG8g dGhlIEJCUiBhbGdvcml0aG0gYXJlIHF1aXRlIG1pbmltYWwuIEkgYW0gd2lsbGluZyB0byBwcmVz ZW50IHRoaXMgYXQgSUNDUkcgaW4gTG9uZG9uIGlmIHRoZXJlIGlzIGFueSBpbnRlcmVzdCBpbiB0 aGlzLg0KKiBFQ04gaW4gUVVJQyB2MSBvciBsYXRlciA6IEkgd291bGQgdmVyeSBtdWNoIHByZWZl ciB0aGF0IEVDTiBzdXBwb3J0IGdvZXMgaW50byB2MS4gT24gdGhlIHRlY2huaWNhbCBzaWRlIGl0 IG1ha2VzIGl0IHBvc3NpYmxlIHRvIGV4cGVyaW1lbnQgd2l0aCBFQ04sIHBvdGVudGlhbGx5IG9u IGEgbGFyZ2VyIHNjYWxlLiBPbiB0aGUgcG9saXRpY2FsIHNpZGUgaXQgaGVscHMgdG8gbWFrZSB0 aGUg4oCcY2hpY2tlbiBhbmQgZWdn4oCdIHByb2JsZW0gYmVjb21lIGhpc3RvcnkuDQoNCi9Jbmdl bWFyDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpJbmdlbWFyIEpvaGFuc3Nv biAgTS5TYy4NCk1hc3RlciBSZXNlYXJjaGVyDQoNCkVyaWNzc29uIFJlc2VhcmNoDQpOZXR3b3Jr IFByb3RvY29scyAmIEUyRSBQZXJmb3JtYW5jZQ0KTGFicmF0b3JpZWdyw6RuZCAxMQ0KOTcxIDI4 LCBMdWxlw6UsIFN3ZWRlbg0KUGhvbmUgKzQ2LTEwNzEgNDMwNDINClNNUy9NTVMgKzQ2LTczIDA3 OCAzMjg5DQppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5z LmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQp3d3cuZXJpY3Nzb24uY29tPGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX193d3cuZXJpY3Nzb24uY29tJmQ9 RHdNR2FRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8mbT14VnpJQTlmN1dqSzhDVklRM0ItdjlaTmwtVWY4SENZNG5Z UGIwZk1STy00JnM9dHlTaU1sZ1R5SVQ4SUptYUtZUy15TVlCTmowWVV3X00yNDZoWDRzektaNCZl PT4NCg0KVGhlIHdvcmxkIGlzIGZ1bGwgb2YgbWFnaWNhbCB0aGluZ3MgcGF0aWVudGx5DQogICAg d2FpdGluZyBmb3Igb3VyIHdpdHMgdG8gZ3JvdyBzaGFycGVyDQogICAgICAgICAgICAgICBCZXJ0 cmFuZCBSdXNzZWxsDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg== --_000_HE1PR0702MB3625648A6943055201D46DCEC2E20HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBF bW9qaSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdp bi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBj bTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5F bWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUy MQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NjU4Nzc3Mjc0Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MzAzMzk5MDYgMTYxMTAyMTc4 NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjAu MjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDsNCgltc28t ZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTYuMjVwdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjEyOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MTY0LjI1cHQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyMDAuMjVwdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MjM2LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoyNzIuMjVwdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMwOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEwNzA0MjU4 NjQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMjI5Njc0OTc0O30NCkBsaXN0IGwxOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MjE2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxODc5Mzk0MDQ3Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjIxOTgxNDg4 IDEzNTQzOTMwNzAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoyMDk2NjMyNTkzOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxMjcwNzYzNTU2O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgw LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzI0LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q29tbWVudCBvbiDigJxDRSBpcyBub3QgZ29pbmcgdG8gYmUgYSB2 ZXJ5IGNvbW1vbiBvY2N1cnJlbmNl4oCdLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGlsZSB0aGF0IG1heSBiZSB0cnVlIGZvciAoYWxtb3N0KSBkcm9wIGVxdWl2YWxl bnQgRUNOIChhLmsuYS4gY2xhc3NpYyksIGl0IGRvZXMgdW5mb3J0dW5hdGVseSBub3QgaG9sZCBh dCBhbGwgZm9yIEw0Uy4gVHlwaWNhbCB2YWx1ZXMgb2YgRUNOIG1hcmtpbmcgcmF0aW8gd2l0aCBM NFMgaXMgaW4gdGhlIG9yZGVyIG9mIDEwIHRvIDUwJS4gSW4gYWRkaXRpb24gdGhlIENFIG1hcmtz IGNhbiBiZSBzcHJlYWQgcmFuZG9tbHkNCiAoZm9yIGluc3RhbmNlIHdpdGggcGhhbnRvbSBxdWV1 ZXMpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtZWFucyB0aGF0 IHRoZSBBQ0sgYmxvY2tzIGluIHRoZSBzdWdnZXN0ZWQgZm9ybWF0IGJlbG93IGNhbiBiZWNvbWUg dmVyeSBzaG9ydCwgaW4gdGhlIHdvcnN0IGNhc2UgcmVwcmVzZW50aW5nIG9ubHkgb25lIHBhY2tl dCBwZXIgQUNLIGJsb2NrIGlmIHdlIGhhdmUgYW4gYWx0ZXJuYXRpbmcgRUNULUNFLUVDVC1DReKA piBwYXR0ZXJuIGluIHRoZSByZWNlaXZlZCBwYWNrZXRzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5TbyBteSB0YWtlIGlzIHRoYXQgaWYgYW4gRUNOIGJpdCBwYXR0ZXJuIGlzIHJlYWxseSBuZWNl c3NhcnkgdGhlbiBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBpdCBhcyBhbiBiaXRtYXAgdGhhdCByZXBy ZXNlbnRzIGFsbCBwYWNrZXRzIHRoYXQgYXJlIGxpc3RlZCBpbiB0aGUgQUNLIGJsb2NrLiBJZiBv bmUgbWFrZSBhbiBhc3N1bXB0aW9uIHRoYXQgYW4gQUNLIGZyYW1lIGNvbnRhaW5zIHR3byBBQ0sg YmxvY2tzIHRoYXQNCiBBQ0tzIDUgYW5kIDcgcGFja2V0cyB0aGVuIHRoZSBFQ04gYmxvY2sgd2ls bCBiZWNvbWUgKDUmIzQzOzcpKjIgPSAyNGJpdHMgLCBpLmUuIDMgb2N0ZXRzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CdXQgd2l0aCB0aGF0IHNhaWQgSSBhbSBzdGlsbCBub3QgY29udmluY2Vk IHRoYXQgdGhlIHBhY2tldCBjb3VudGVyIGFwcHJvYWNoIGlzIGZsYXdlZCAoSeKAmW0gYW0gaGFw cHkgdG8gYmUgZW5saWdodGVuZWQNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMjs8L3NwYW4+KSAuIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFraW5nIG11bHRpcGF0aCBhcyBhbiBleGFt cGxlIDogSXNu4oCZdCBpdCB0aGUgY2FzZSB0aGF0IHR3byBjb25uZWN0aW9ucyBhcmUgc2V0dXAs IGVhY2ggd2l0aCBpdHMgb3duIGNvbmdlc3Rpb24gY29udHJvbCBjb250ZXh0IChJIG9taXQgY291 cGxlZCBDQyBmb3IgdGhlIG1vbWVudCkuIElmIHRoYXQgaXMgdGhlIGNhc2UgdGhlbiBJIGRvbuKA mXQgc2VlIGFueSBwcm9ibGVtIHdpdGggdGhlIHBhY2tldCBjb3VudGVycy4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgcmVnYXJkcyB0byBjb25uZWN0aW9uIG1pZ3Jh dGlvbi4gT25lIHBvc3NpYmxlIG1hdHRlciBpcyB0aGF0IGl0IGNhbiBiZWNvbWUgdHJpY2t5IHRv IGRldGVjdCBFQ04gYmxlYWNoaW5nIG9yIEVDTiBiaXQgYWNjZXNzIHByb2JsZW1zIGluIE9TIGlt bWVkaWF0ZWx5ICwgaG93ZXZlciBkdXJpbmcgdGhlIGNvdXJzZSBvZiAxIFJUVCBvciBldmVuIGxl c3MsIHRoaXMgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRldGVjdA0KIGFzIGUuZy4gRUNOIGJsZWFj aGluZyB3aWxsIHJlc3VsdCBpbiB0aGF0IHRoZSBuZWl0aGVyIG9uIHRoZSBFQ1QoMCksRUNUKDEp IGFuZCBDRSBjb3VudGVycyBpbmNyZWFzZS4gQnV0IEkgYW0gZnVsbHkgYXdhcmUgdGhhdCBJIG1h eSBtaXNzIHRoaW5ncyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gTHViYXNoZXYsIElnb3IgW21haWx0bzppbHViYXNoZUBha2FtYWkuY29tXSA8YnI+DQo8Yj5T ZW50OjwvYj4gZGVuIDI0IGphbnVhcmkgMjAxOCAxOTowMjxicj4NCjxiPlRvOjwvYj4gSW5nZW1h ciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7OyBR VUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgaHVpdGVtYSAoaHVpdGVtYUBodWl0ZW1hLm5l dCkgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBF Q04gaW4gUVVJQzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxp ZXZlIHRoZSBwcmltYXJ5IGNvbmNlcm4gZHVyaW5nIHRoZSBtZWV0aW5nIHllc3RlcmRheSB3YXMg dGhlIEVDTiBmZWVkYmFjayBmb3JtYXQgKGNvdW50ZXJzKS4mbmJzcDsgSGVyZSBpcyB0aGUgYWx0 ZXJuYXRpdmUsIHNpbWlsYXIgdG8gd2hhdCBDaHJpc3RpYW4gdm9pY2VkLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGFtIG1ha2luZyB0aGVzZSBhc3N1bXB0aW9uczo8bzpwPjwvbzpwPjwvcD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDotMTUuNzVwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MyI+Q0UgaXMgbm90IGdvaW5nIHRvIGJlIGEgdmVyeSBjb21tb24gb2NjdXJyZW5jZTxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi0xNS43NXB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5UaGUgZW5kcG9pbnQgd2lsbCB1c3VhbGx5IGVpdGhl ciBzZW5kIChhbG1vc3QpIGFsbCBwYWNrZXRzIHdpdGggbm8gRUNUIG1hcmtpbmdzLCBvciBpdCB3 aWxsIHNlbmQgKGFsbW9zdCkgYWxsIHBhY2tldHMgd2l0aCBhIHNwZWNpZmljIEVDVCAoRUNUWzBd IG9yIEVDVFsxXSkuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNXB0Ij5Ob25lIG9mIHRoZXNlIGFzc3VtcHRpb25zIGFyZSBy ZXF1aXJlZC4mbmJzcDsgVGhleSBhcmUganVzdCB1c2VkIHRvIGlkZW50aWZ5IOKAnGNvbW1vbiBj YXNlc+KAnSBhbmQgc2F2ZSBhIGZldyBieXRlcyBwZXIgQUNLIGZyYW1lLiZuYnNwOyBXZSBtYXkg ZGlzY2FyZCB0aGVzZSBhc3N1bXB0aW9ucyBhbmQgdGhlIG9wdGltaXphdGlvbnMuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6Mi4yNXB0Ij5U aGUgd29yc3QgY2FzZSBmb3IgdGhpcyBwcm9wb3NhbCBpcyBhIGNhc2Ugd2hlbiBFQ1RbMF0gYW5k IEVDVFsxXSBtYXJraW5nIGFsdGVybmF0ZSwgYmVjYXVzZSB0aGF0IHByZXZlbnRzIGFja25vd2xl ZGdpbmcgY29uc2VjdXRpdmUgcGFja2V0cyBhcyBhIGJsb2NrLiZuYnNwOyBNeSBpbmNsaW5hdGlv biBpcyB0byBkaXJlY3QgdGhlIHNlbmRlciB0byBqdXN0IG5vdCBkbyB0aGlzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6Mi4yNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoyLjI1cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjIuMjVwdCI+UGFydCAxLiBQcmltYXJ5IEVD VDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkR1cmluZyB0aGUg aGFuZHNoYWtlLCBlYWNoIGVuZHBvaW50IG5vdGlmaWVzIHRoZSBvdGhlciBvZiB0aGUgRUNUIGNv ZGVwb2ludCAoRUNUWzBdIG9yIEVDVFsxXSkgdGhhdCBpcyBpbnRlbmRzIHRvIHVzZSBwcmltYXJp bHkuJm5ic3A7IFRoaXMgaXMga25vd24gdGhlIFByaW1hcnkgRUNULiZuYnNwOyBCeSBkZWZhdWx0 LCBFQ1RbMF0gaXMgdGhlIFByaW1hcnkgRUNULjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhcnQgMi4mbmJzcDsgVHdv IEFDSyB2YXJpZXRpZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4g YWRkaXRpb24gdG8gQUNLIEZyYW1lLCB3ZSBpbnRyb2R1Y2UgYSBuZXcgQUNLLUVDVCBmcmFtZS4m bmJzcDsgVGhlIGNvbnRlbnRzIG9mIHRoZSBmcmFtZXMgYXJlIGlkZW50aWNhbCBhbmQgdW5jaGFu Z2VkIGZyb20gdGhlIGN1cnJlbnQgQUNLIGZyYW1lIGNvbnRlbnRzLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHBhY2tldHMgYWNrbm93bGVkZ2VkIGJ5IHRoZSBBQ0sg RnJhbWUgYXJlIHBhY2tldHMgdGhhdCBoYXZlIG5vIEVDTiBiaXRzIHNldCBhdCBhbGwuJm5ic3A7 IEFsbCBwYWNrZXRzIGFja25vd2xlZGdlZCBieSB0aGUgQUNLLUVDVCBGcmFtZSBhcmUgcGFja2V0 cyB0aGF0IGhhdmUgUHJpbWFyeSBFQ1QgY29kZSBwb2ludC4mbmJzcDsgSXQgaXMgZXhwZWN0ZWQg dGhhdCBpbiB0aGUgY29tbW9uIGNhc2UsIGFsbCBwYWNrZXRzIHdpbGwNCiBiZSBhY2tub3dsZWRn ZWQgYnkgQUNLIG9yIEFDSy1FQ1QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFydCAzLiZuYnNwOyBBQ0stRUNOLUJJ VE1BUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbmV3IEFDSy1F Q04tQklUTUFQIGZyYW1lIGlzIHVzZWQgd2hlbiBBQ0sgb3IgQUNLLUVDVCBmcmFtZXMgY2Fubm90 IGJlIHVzZWQuJm5ic3A7IEl0cyBmb3JtYXQgaXMgdmVyeSBzaW1pbGFyIHRvIHRoZSBmb3JtYXQg b2YgdGhlIEFDSyBmcmFtZSwgZXhjZXB0IHRoZXJlIGlzIGEgbmV3IEVDTiBCaXRtYXAgZmllbGQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPn5+fjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+MCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMYXJnZXN0IEFja25vd2xlZGdl ZCAoaSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLi4uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBBQ0sgRGVsYXkgKGkpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUNLIEJsb2Nr IENvdW50IChpKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj58Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVDTiBCaXRtYXAgKCopJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQUNLIEJsb2NrcyAoKikmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Li4uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+fn5+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj57OiAjYWNrLWVjbi1iaXRtYXAgZm9ybWF0IHRpdGxlPSZx dW90O0FDSy1FQ04tQklUTUFQIEZyYW1lIEZvcm1hdCZxdW90O308bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGZpZWxkcyBpbiB0aGUgQUNLLUVDTi1CSVRNQVAgZnJhbWUgYXJlIGFzIGZvbGxv d3M6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhcmdlc3QgQWNrbm93bGVkZ2VkOiZuYnNwOyAo U0FNRSBBUyBJTiBBQ0sgRlJBTUUpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFDSyBEZWxheTom bmJzcDsgKFNBTUUgQVMgSU4gQUNLIEZSQU1FKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BQ0sg QmxvY2sgQ291bnQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TQU1FIEFT IElOIEFDSyBGUkFNRSwgZXhjZXB0IHBhY2tldHMgaW4gZWFjaCBBQ0sgQmxvY2sgTVVTVCBoYXZl IHRoZSBzYW1lIEVDTiBtYXJraW5nLiZuYnNwOyBUaGlzIG1heSBjYXVzZSBibG9ja3Mgb2YgY29u c2VjdXRpdmUgcGFja2V0cyB0byBiZSBzcGxpdCBpbnRvIG11bHRpcGxlIEFDSyBCbG9ja3MgKHdp dGggR2FwPTAgaW4gYmV0d2VlbiksIGlmIHRob3NlIHBhY2tldHMgaGF2ZSBkaWZmZXJlbnQgRUNO IG1hcmtpbmdzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FQ04gQml0bWFwOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBzZXF1ZW5jZSBvZiBBQ0sgQmxvY2sgQ291bnQg cGFpcnMgb2YgYml0cyB0aGF0IGluZGljYXRlIEVDTiBtYXJraW5ncyBmb3IgdGhlIGNvcnJlc3Bv bmRpbmcgQUNLIEJsb2NrLiZuYnNwOyBUaGUgc2l6ZSBvZiB0aGUgRUNOIEJpdG1hcCBmaWVsZCBp cyBDZWlsaW5nKCgxJiM0MzvigJxBQ0sgQmxvY2sgQ291bnTigJ0pLzQpIG9jdGV0cy4mbmJzcDsg VGhlIHVudXNlZCBiaXRzIHNob3VsZCBiZSBzZXQgdG8gMC48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBleGFtcGxlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+fn5+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4wIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj58QUF8QkJ8Q0N8RER84oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CaXRzIEFBIHJlcHJlc2VudCBFQ04gYml0cyBmb3IgcGFja2V0cyBhY2tub3dsZWRnZWQg aW4gdGhlIEZpcnN0IEFDSyBCbG9jay48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJpdHMgQkIgcmVwcmVzZW50IEVDTiBiaXRzIGZvciBwYWNrZXRzIGFja25vd2xlZGdlZCBp biBBZGRpdGlvbmFsIEFDSyBCbG9jayAwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Qml0cyBDQyByZXByZXNlbnQgRUNOIGJpdHMgZm9yIHBhY2tldHMgYWNrbm93bGVkZ2Vk IGluIEFkZGl0aW9uYWwgQUNLIEJsb2NrIDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPuKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BQ0sgQmxvY2tzOiAoU0FNRSBBUyBJ TiBBQ0sgRlJBTUUpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm82Ij5JZ29yPG86cD48L286cD48 L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJbmdl bWFyIEpvaGFuc3NvbiBTIFs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20iPm1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDI0LCAyMDE4IDM6MDEgQU08YnI+ DQo8Yj5Ubzo8L2I+IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5x dWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRUNOIGluIFFVSUM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgZmV3IGltcHJlc3Npb25zIG9uIHRoZSBFQ04gaW4gUVVJQyBkaXNjdXNzaW9ucy4g VGhlIGF1ZGlvIHdhcyBzby1zbywgZnJlcXVlbnQgaW50ZXJydXB0aW9ucyBhbmQgTEFSR0UgZGlm ZmVyZW5jZXMgaW4gYXVkaW8gbGV2ZWwgJiM0MzsgYmFkbHkgaW1wbGVtZW50ZWQgZWFycw0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2Vy aWYiPiYjMTI4NTIyOzwvc3Bhbj4sIHNvIHNvbWV0aW1lcyBJIG1pc3NlZCB0aGUgZGV0YWlscyBh bmQgcG9zc2libHkga2ljayBpbiBvcGVuIGRvb3JzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiogJm5ic3A7RmVlZGJhY2sgZm9ybWF0LiBJIHVuZGVyc3RhbmQgdGhhdCB0aGUgcHJvcG9zZWQg cHJvcG9zYWwgYmFzZWQgb24gRUNUKDApLCBFQ1QoMSkgYW5kIENFIGNvdW50ZXJzIGRvZXMgbm90 IHBsYXkgd2VsbCB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBJIGJlbGlldmUsIGJ1dCBJIGFt IG5vdCAxMDAlIHN1cmUgdGhhdCBJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0uIEkgdW5kZXJzdGFu ZCB0aGF0IHRoZXJlIGFyZQ0KIHR3byBjb25jZXJucyAocGVyaGFwcyBtb3JlPyk6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgMS4gQ291bnRlcnMgYXJlIHJlc2V0 LCB0aGlzIG1lYW5zIHRoYXQgdGhlcmUgd2lsbCBiZSBhIHBvdGVudGlhbGx5IHZlcnkgbGFyZ2Ug KG5lZ2F0aXZlPykgZGlmZmVyZW5jZSBpbiBDRSBtYXJrZWQgcGFja2V0cy4gSSBiZWxpZXZlIHRo YXQgdGhpcyBjYW4gYmUgZGV0ZWN0ZWQgYXMgZmFsc2UgY29uZ2VzdGlvbiBzaWduYWwgYW5kIGln bm9yZWQgYnkgdGhlIGNvbmdlc3Rpb24gc2lnbmFsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IDIuIERpZmZpY3VsdGllcyB0byBkZXRlY3QgRUNOIGJsZWFjaGlu Zy4gSXQgaXMgdHJpY2t5IHRvIHVuZGVyc3RhbmQgaWYgcGFja2V0cyBhbG9uZyB0aGUgbmV3IHBh dGggYXJlIGJsZWFjaGVkIGJhc2VkIG9uIHRoZSBFQ1QgY291bnRlcnMuIFRoaXMgY2FuIGJlIGEg bW9yZSBjb21wbGljYXRlZCBjYXNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gYW55IGNhc2UgaXQgd2FzIHN1Z2dlc3RlZCB0byBpbmRpY2F0ZSB0aGUgRUNOIGJpdHMg Zm9yIHRoZSBwYWNrZXRzIGluIHRoZSBBQ0sgZnJhbWUuIFN1Y2ggYSBmb3JtYXQgd2FzIGFjdHVh bGx5IG91dGxpbmVkIGluIGVhcmxpZXIgcHJvcG9zYWwgKHNlZSBwYWdlIDYsIEZpZ3VyZSAzIGlu DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRqb2hhbnNzb24tMkRxdWljLTJEZWNu LTJEMDEmYW1wO2Q9RHdNR2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpu M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT14VnpJQTlmN1dq SzhDVklRM0ItdjlaTmwtVWY4SENZNG5ZUGIwZk1STy00JmFtcDtzPVM5YXFjOFVJR2FURFgzWk1z MVZUeVdpTFNTRzAxbmRGaGhyX1pnMDFIMVkmYW1wO2U9Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1qb2hhbnNzb24tcXVpYy1lY24tMDE8L2E+ICkuIEl0IGlzIE9rIHdpdGgg bWUgdG8gY2hhbmdlIHRvIGEgZm9ybWF0IHNpbWlsYXIgdG8gdGhpcyBpZiB0aGUgZ3JvdXAgcHJl ZmVycyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4qIENvbmdlc3Rpb24gY29udHJvbCBm b3IgRUNUKDEpLCBMNFMgOiBNeSBmZWVsaW5nIGlzIHRoYXQgaXQgaXMgZm9yIG5vdyBPSyB0byBs ZWF2ZSB0aGlzIGFzIGZ1dHVyZSB3b3JrLiBUaGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBh cmUgYWJzb2x1dGVseSBubyBpZGVhcyBvbiBob3cgdG8gaW1wbGVtZW50IHRoaXMsIGZvciBzaG9y dCBSVFQgZW52aXJvbm1lbnRzIERDVENQIHN0eWxlIGNvbmdlc3Rpb24gY29udHJvbA0KIGlzIHF1 aXRlIE9LLiBGdXJ0aGVybW9yZSBJIGFuZCByZWNlbnRseSB3b3JrZWQgb24gYSBMNFMgY29uZ2Vz dGlvbiBjb250cm9sIHRoYXQgaXMgYmFzZWQgb24gQkJSLCB0aGUgcmVzdWx0cyBsb29rIHF1aXRl IHByb21pc2luZyBhbmQgdGhlIGNoYW5nZXMgdG8gdGhlIEJCUiBhbGdvcml0aG0gYXJlIHF1aXRl IG1pbmltYWwuIEkgYW0gd2lsbGluZyB0byBwcmVzZW50IHRoaXMgYXQgSUNDUkcgaW4gTG9uZG9u IGlmIHRoZXJlIGlzIGFueSBpbnRlcmVzdA0KIGluIHRoaXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4qIEVDTiBpbiBRVUlDIHYxIG9yIGxhdGVyIDogSSB3b3VsZCB2ZXJ5 IG11Y2ggcHJlZmVyIHRoYXQgRUNOIHN1cHBvcnQgZ29lcyBpbnRvIHYxLiBPbiB0aGUgdGVjaG5p Y2FsIHNpZGUgaXQgbWFrZXMgaXQgcG9zc2libGUgdG8gZXhwZXJpbWVudCB3aXRoIEVDTiwgcG90 ZW50aWFsbHkgb24gYSBsYXJnZXIgc2NhbGUuIE9uIHRoZSBwb2xpdGljYWwgc2lkZSBpdCBoZWxw cyB0byBtYWtlIHRoZSDigJxjaGlja2VuIGFuZA0KIGVnZ+KAnSBwcm9ibGVtIGJlY29tZSBoaXN0 b3J5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJTViI+L0luZ2VtYXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRv c3BhY2U6bm9uZSI+PHNwYW4gbGFuZz0iU1YiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08L3NwYW4+PHNwYW4gbGFuZz0iU1YiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBsYW5nPSJTViIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+SW5nZW1hciBKb2hhbnNzb24mbmJzcDsgTS5TYy4NCjwvc3Bh bj48c3BhbiBsYW5nPSJTViI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hc3RlciBS ZXNlYXJjaGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpu b25lIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj5Fcmljc3NvbiBSZXNlYXJjaDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5OZXR3b3JrIFByb3RvY29scyAmYW1wOyBFMkUgUGVyZm9ybWFuY2U8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3Bh Y2U6bm9uZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TGFicmF0b3JpZWdyw6RuZCAxMTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25l Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj45NzEgMjgsIEx1bGXDpSwgU3dlZGVuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPlBob25lICYjNDM7NDYtMTA3MSA0MzA0Mjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5TTVMvTU1TICYjNDM7NDYtNzMgMDc4IDMyODk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+PGEg aHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hdXRvc3BhY2U6bm9uZSI+ PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAt M0FfX3d3dy5lcmljc3Nvbi5jb20mYW1wO2Q9RHdNR2FRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpw TjZMWmcmYW1wO3I9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZh bXA7bT14VnpJQTlmN1dqSzhDVklRM0ItdjlaTmwtVWY4SENZNG5ZUGIwZk1STy00JmFtcDtzPXR5 U2lNbGdUeUlUOElKbWFLWVMteU1ZQk5qMFlVd19NMjQ2aFg0c3pLWjQmYW1wO2U9Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj53d3cuZXJpY3Nzb24uY29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2JhY2tncm91bmQ6I0NDQ0NERCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzMzMzMzMztiYWNrZ3JvdW5kOndoaXRlIj5UaGUgd29ybGQgaXMgZnVsbCBvZiBtYWdp Y2FsIHRoaW5ncyBwYXRpZW50bHkNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWF1dG9zcGFjZTpub25lIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzM7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7d2FpdGlu ZyBmb3Igb3VyIHdpdHMgdG8gZ3JvdyBzaGFycGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMztiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgQmVydHJhbmQgUnVzc2VsbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_HE1PR0702MB3625648A6943055201D46DCEC2E20HE1PR0702MB3625_-- From nobody Wed Jan 24 13:41:10 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85852129966 for ; Wed, 24 Jan 2018 13:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcd1BsIJ7POS for ; Wed, 24 Jan 2018 13:41:07 -0800 (PST) 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 6FC5B12D779 for ; Wed, 24 Jan 2018 13:41:03 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eeSmt-0001Uk-FY for quic@ietf.org; Wed, 24 Jan 2018 22:40:56 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eeSjn-0002gr-7m for quic@ietf.org; Wed, 24 Jan 2018 16:40:54 -0500 Received: (qmail 21141 invoked from network); 24 Jan 2018 21:37:40 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jan 2018 21:37:40 -0000 To: Ingemar Johansson S , "Lubashev, Igor" , QUIC WG References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" From: Christian Huitema Message-ID: <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> Date: Wed, 24 Jan 2018 11:37:34 -1000 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="------------0E8E8A9126990C93188D4AD3" Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5uPkL/UvIlwpyzULlMPydr8Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsQJw+wIvj/Za/dHrWEk6otB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXsyb8kPdw8E5fjseDcUSkOjZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XSWizyN/9VXiZ4elFzVDIjrsNHLD5iuK9LgA8bTWyd hUZc42FjK4e77D0r+pFXB6pZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWdVYLStU2rrUXX7KMr7Beuaf4b0gaZx7Nq9QqOn1O3qTi vS4s3d19f4QGhrGn4oy9t6i2Xwxibhye0Boj8bZR+CG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhRaIWNqDyY6nOXa2Z6n1IVlAxXqQU4SUCmX1X8Fu4HDHzL0ZrmIKZ0kUi8MQlv6kpQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 21:41:09 -0000 This is a multi-part message in MIME format. --------------0E8E8A9126990C93188D4AD3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/24/2018 10:51 AM, Ingemar Johansson S wrote: > > Hi > > =20 > > Comment on =E2=80=9CCE is not going to be a very common occurrence=E2=80= =9D. > > While that may be true for (almost) drop equivalent ECN (a.k.a. > classic), it does unfortunately not hold at all for L4S. Typical > values of ECN marking ratio with L4S is in the order of 10 to 50%. In > addition the CE marks can be spread randomly (for instance with > phantom queues). > > This means that the ACK blocks in the suggested format below can > become very short, in the worst case representing only one packet per > ACK block if we have an alternating ECT-CE-ECT-CE=E2=80=A6 pattern in t= he > received packets. > Yes. > > =20 > > So my take is that if an ECN bit pattern is really necessary then it > is better to have it as an bitmap that represents all packets that are > listed in the ACK block. If one make an assumption that an ACK frame > contains two ACK blocks that ACKs 5 and 7 packets then the ECN block > will become (5+7)*2 =3D 24bits , i.e. 3 octets. > Yes, we have to take that into account in the design. > > =20 > > But with that said I am still not convinced that the packet counter > approach is flawed (I=E2=80=99m am happy to be enlightened =F0=9F=98=8A= ) . > > Taking multipath as an example : Isn=E2=80=99t it the case that two > connections are setup, each with its own congestion control context (I > omit coupled CC for the moment). If that is the case then I don=E2=80=99= t see > any problem with the packet counters. > We are heading towards a single packet sequence number space shared by multiple paths. That means that we need precise per packet feedback. If a packet was marked with CE, you want to know on which path, and the way to know that is to find the "path" tag in the saved copy of the packet. You cant do that with counters. > As regards to connection migration. One possible matter is that it can > become tricky to detect ECN bleaching or ECN bit access problems in OS > immediately , however during the course of 1 RTT or even less, this > should be possible to detect as e.g. ECN bleaching will result in that > the neither on the ECT(0),ECT(1) and CE counters increase. But I am > fully aware that I may miss things here. > Again, there is no problem if we have precise per packet feedback, because we can find out which packets were bleached. -- Christian Huitema --------------0E8E8A9126990C93188D4AD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 1/24/2018 10:51 AM, Ingemar Johansson S wrote:

    Hi

     

    Comment on “CE is not going to be a very common occurrenceâ€.

    While that may be true for (almost) drop equivalent ECN (a.k.a. classic), it does unfortunately not hold at all for L4S. Typical values of ECN marking ratio with L4S is in the order of 10 to 50%. In addition the CE marks can be spread randomly (for instance with phantom queues).

    This means that the ACK blocks in the suggested format below can become very short, in the worst case representing only one packet per ACK block if we have an alternating ECT-CE-ECT-CE… pattern in the received packets.

    Yes.

     

    So my take is that if an ECN bit pattern is really necessary then it is better to have it as an bitmap that represents all packets that are listed in the ACK block. If one make an assumption that an ACK frame contains two ACK blocks that ACKs 5 and 7 packets then the ECN block will become (5+7)*2 = 24bits , i.e. 3 octets.

    Yes, we have to take that into account in the design.

     

    But with that said I am still not convinced that the packet counter approach is flawed (I’m am happy to be enlightened 😊) .

    Taking multipath as an example : Isn’t it the case that two connections are setup, each with its own congestion control context (I omit coupled CC for the moment). If that is the case then I don’t see any problem with the packet counters.


    We are heading towards a single packet sequence number space shared by multiple paths. That means that we need precise per packet feedback. If a packet was marked with CE, you want to know on which path, and the way to know that is to find the "path" tag in the saved copy of the packet. You cant do that with counters.

    As regards to connection migration. One possible matter is that it can become tricky to detect ECN bleaching or ECN bit access problems in OS immediately , however during the course of 1 RTT or even less, this should be possible to detect as e.g. ECN bleaching will result in that the neither on the ECT(0),ECT(1) and CE counters increase. But I am fully aware that I may miss things here.


    Again, there is no problem if we have precise per packet feedback, because we can find out which packets were bleached.

    -- Christian Huitema

    --------------0E8E8A9126990C93188D4AD3-- From nobody Wed Jan 24 13:44:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29A312AF77 for ; Wed, 24 Jan 2018 13:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnEzOD90LOhv for ; Wed, 24 Jan 2018 13:44:28 -0800 (PST) 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 E82A3127201 for ; Wed, 24 Jan 2018 13:44:27 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eeSqH-0004Om-Ja for quic@ietf.org; Wed, 24 Jan 2018 22:44:26 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eeSqE-0001ux-6y for quic@ietf.org; Wed, 24 Jan 2018 16:44:23 -0500 Received: (qmail 21141 invoked from network); 24 Jan 2018 21:37:40 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jan 2018 21:37:40 -0000 To: Ingemar Johansson S , "Lubashev, Igor" , QUIC WG References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" From: Christian Huitema Message-ID: <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> Date: Wed, 24 Jan 2018 11:37:34 -1000 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="------------0E8E8A9126990C93188D4AD3" Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tBSyeVBrWYJ+HrWiLmJHe4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsQJw+wIvj/Za/dHrWEk6otB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31WoCGUWNgo50bBZN3FfqI2VItAPyqRyV95ZNrHd7vkN RoV0IzqQdhSFseL8JJvkBtXh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GaydQSHaKCADuB2RogJvWPZnHEeB4hpRrmo/duzUUp/ID PD7lumF5jI8vJ2f0B4AMlj5WakQVs0Q447Jwg+PVE3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+lXmk/kN/ohhMsDjVJmzLuIj2lB9TLiDMfXuvSrucRXqLltlcS50veJ4w4EzZsk1xpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 21:44:30 -0000 This is a multi-part message in MIME format. --------------0E8E8A9126990C93188D4AD3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/24/2018 10:51 AM, Ingemar Johansson S wrote: > > Hi > > =20 > > Comment on =E2=80=9CCE is not going to be a very common occurrence=E2=80= =9D. > > While that may be true for (almost) drop equivalent ECN (a.k.a. > classic), it does unfortunately not hold at all for L4S. Typical > values of ECN marking ratio with L4S is in the order of 10 to 50%. In > addition the CE marks can be spread randomly (for instance with > phantom queues). > > This means that the ACK blocks in the suggested format below can > become very short, in the worst case representing only one packet per > ACK block if we have an alternating ECT-CE-ECT-CE=E2=80=A6 pattern in t= he > received packets. > Yes. > > =20 > > So my take is that if an ECN bit pattern is really necessary then it > is better to have it as an bitmap that represents all packets that are > listed in the ACK block. If one make an assumption that an ACK frame > contains two ACK blocks that ACKs 5 and 7 packets then the ECN block > will become (5+7)*2 =3D 24bits , i.e. 3 octets. > Yes, we have to take that into account in the design. > > =20 > > But with that said I am still not convinced that the packet counter > approach is flawed (I=E2=80=99m am happy to be enlightened =F0=9F=98=8A= ) . > > Taking multipath as an example : Isn=E2=80=99t it the case that two > connections are setup, each with its own congestion control context (I > omit coupled CC for the moment). If that is the case then I don=E2=80=99= t see > any problem with the packet counters. > We are heading towards a single packet sequence number space shared by multiple paths. That means that we need precise per packet feedback. If a packet was marked with CE, you want to know on which path, and the way to know that is to find the "path" tag in the saved copy of the packet. You cant do that with counters. > As regards to connection migration. One possible matter is that it can > become tricky to detect ECN bleaching or ECN bit access problems in OS > immediately , however during the course of 1 RTT or even less, this > should be possible to detect as e.g. ECN bleaching will result in that > the neither on the ECT(0),ECT(1) and CE counters increase. But I am > fully aware that I may miss things here. > Again, there is no problem if we have precise per packet feedback, because we can find out which packets were bleached. -- Christian Huitema --------------0E8E8A9126990C93188D4AD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 1/24/2018 10:51 AM, Ingemar Johansson S wrote:

    Hi

     

    Comment on “CE is not going to be a very common occurrenceâ€.

    While that may be true for (almost) drop equivalent ECN (a.k.a. classic), it does unfortunately not hold at all for L4S. Typical values of ECN marking ratio with L4S is in the order of 10 to 50%. In addition the CE marks can be spread randomly (for instance with phantom queues).

    This means that the ACK blocks in the suggested format below can become very short, in the worst case representing only one packet per ACK block if we have an alternating ECT-CE-ECT-CE… pattern in the received packets.

    Yes.

     

    So my take is that if an ECN bit pattern is really necessary then it is better to have it as an bitmap that represents all packets that are listed in the ACK block. If one make an assumption that an ACK frame contains two ACK blocks that ACKs 5 and 7 packets then the ECN block will become (5+7)*2 = 24bits , i.e. 3 octets.

    Yes, we have to take that into account in the design.

     

    But with that said I am still not convinced that the packet counter approach is flawed (I’m am happy to be enlightened 😊) .

    Taking multipath as an example : Isn’t it the case that two connections are setup, each with its own congestion control context (I omit coupled CC for the moment). If that is the case then I don’t see any problem with the packet counters.


    We are heading towards a single packet sequence number space shared by multiple paths. That means that we need precise per packet feedback. If a packet was marked with CE, you want to know on which path, and the way to know that is to find the "path" tag in the saved copy of the packet. You cant do that with counters.

    As regards to connection migration. One possible matter is that it can become tricky to detect ECN bleaching or ECN bit access problems in OS immediately , however during the course of 1 RTT or even less, this should be possible to detect as e.g. ECN bleaching will result in that the neither on the ECT(0),ECT(1) and CE counters increase. But I am fully aware that I may miss things here.


    Again, there is no problem if we have precise per packet feedback, because we can find out which packets were bleached.

    -- Christian Huitema

    --------------0E8E8A9126990C93188D4AD3-- From nobody Wed Jan 24 14:37:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6988612D779 for ; Wed, 24 Jan 2018 14:37:25 -0800 (PST) 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 QO0x2qpx_obZ for ; Wed, 24 Jan 2018 14:37:23 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C155512AF84 for ; Wed, 24 Jan 2018 14:37:23 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id u17so2123217ywg.9 for ; Wed, 24 Jan 2018 14:37:23 -0800 (PST) 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=U6ad7fcyKDDeL6W/W6aha/qlLY6v2Wc21tqouOCVpy0=; b=bjZt1uPfzQ+YLYJIKRW22XeCmEEWJJoSnvW88Eroo1NV+T0rkhSWGqv2h4dc7+bq8z 5XQhJSvYUSP3+gCf1SNGl+wSKuqEb14NdM68CdZLdB6aw2kPCcoyAFrX6Q1tFx2ceX16 TxxCnBegn6hj+QVBpm4P8ueMR4RreIhuhAh7zCokPQGSxSeUlNmkSDLyYYDKUtNEeKIM wqghwcWjWW62boRk1it2Inb8JpVRfC9g9+yU9xYPUFJD35wTal5XFVy+rJEv7vcUHiL4 pw8XkAtkeQTTfYtkMPnZKEa9/P/zUsIaCdKRDd8En7o7kjjXtlbVtIfbxljh9RL3SNqS Zi4g== 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=U6ad7fcyKDDeL6W/W6aha/qlLY6v2Wc21tqouOCVpy0=; b=SQKT8JGFeBz5LyqU7UmZF87x7QarjNl430Rw0qp8LI4dYZnSxaLLNRKb55vN9zj1UQ nvbzkh7snZF4D6srOt6VGc/BcHFL+/IutE/aB0pZ9iVPwcz6uaTukbKvHnsakCuzSkJc LCu16/o6UkVngBf6sKXoVaeykU9FCOFiXiU/N04Y0U7YvOJxCcTdnnH6vJQowO0uacK1 +Y3f5mo8fmNYMPUnWe1g6/QlqEo8ZM2xcvBxmAh3wOPj/PB7XQIcEOUi0Rba784ejL3o c4igxGbSIQXO4cqx2o+QdXaCOI/DPQohZaQDFZLDOMyA/+pTq+n04A7+ZCMoqfLJDZx9 M87A== X-Gm-Message-State: AKwxytfQSA3zB6rz1uW6fptB1D/YYgStFAjODuKk538Usc0s/b10Gux/ frxBk5lw2X/m7mLOYsmOFpqBLVcpeloyScLsUBbujYVN+g8= X-Google-Smtp-Source: AH8x2270UjkXavFFXqGhdyTvTElFZCkrX785QGc/2uJJUYUq539PccgZIIx6E7qvUiyUwKNIu5MQah6O5wdChyAoZjw= X-Received: by 10.129.39.84 with SMTP id n81mr6755563ywn.5.1516833442818; Wed, 24 Jan 2018 14:37:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Wed, 24 Jan 2018 14:36:42 -0800 (PST) From: Eric Rescorla Date: Wed, 24 Jan 2018 14:36:42 -0800 Message-ID: Subject: Read-out on offline connection ID discussion To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114097248b06a205638d4e8b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 22:37:25 -0000 --001a114097248b06a205638d4e8b Content-Type: text/plain; charset="UTF-8" Hi folks, We didn't really reach a conclusion, but here's, I think what there was at least some support for: - The long header has a variable length connection ID which has an explicit length field on the wire, with a max length (strawman: 32 bytes). The exact wire encoding to be designed by the editor. Similarly, NEW_CONNECTION_ID would have a variable length encoding. - The short header has a variable length connection ID which has an implicit length (i.e., it cannot be decoded unambiguously by an observer who is not part of the connection). However, the CID may be self-describing, so that the server may include a length field if it so chooses. There was rough consensus on the second point, but some disagreement about the first point. The major alternative proposal was to have a fixed-length CID field in the long header and NEW_CONNECTION_ID and then truncate it to an amount carried in transport_parameters. This would have the benefit that the length of the CID would be throughout the connection whereas if we wanted that rule for the other design we would need a rule. One thing that makes this second approach unattractive is that we want the server to be able to use a 16 byte connection ID (thus allowing it to be AES-encrypted) but it also needs to be able to include meta-data, such as a key-id for rotation or potentially a length. This tells us that you need to have a maximum connection ID larger than 16 bytes, and having a fixed 17-20 byte CID seems odd. -Ekr --001a114097248b06a205638d4e8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi folks,

    We didn't real= ly reach a conclusion, but here's, I think what there
    was at = least some support for:

    - The long header has a va= riable length connection ID which has an
    =C2=A0 explicit length f= ield on the wire, with a max length (strawman: 32
    =C2=A0 bytes). = The exact wire encoding to be designed by the editor.
    =C2=A0 Simi= larly, NEW_CONNECTION_ID would have a variable length
    =C2=A0 enco= ding.

    - The short header has a variable length con= nection ID which has
    =C2=A0 an implicit length (i.e., it cannot b= e decoded unambiguously
    =C2=A0 by an observer who is not part of = the connection). However,
    =C2=A0 the CID may be self-describing, = so that the server may include
    =C2=A0 a length field if it so cho= oses.

    There was rough consensus on the second poin= t, but some disagreement
    about the first point. The major alterna= tive proposal was to have
    a fixed-length CID field in the long he= ader and NEW_CONNECTION_ID
    and then truncate it to an amount carr= ied in transport_parameters.
    This would have the benefit that the= length of the CID would be
    throughout the connection whereas if = we wanted that rule for the
    other design we would need a rule.

    One thing that makes this second approach unattracti= ve is that we want
    the server to be able to use a 16 byte connect= ion ID (thus allowing it
    to be AES-encrypted) but it also needs t= o be able to include
    meta-data, such as a key-id for rotation or = potentially a length. This
    tells us that you need to have a maxim= um connection ID larger than 16
    bytes, and having a fixed 17-20 b= yte CID seems odd.

    -Ekr

    <= br>



    =C2=A0 =C2=A0


    =C2=A0=C2=A0

    --001a114097248b06a205638d4e8b-- From nobody Wed Jan 24 14:51:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0D612D779 for ; Wed, 24 Jan 2018 14:51:07 -0800 (PST) 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 moNR8oKhMo51 for ; Wed, 24 Jan 2018 14:51:05 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0107B12AF84 for ; Wed, 24 Jan 2018 14:51:04 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id m11so19784528iti.1 for ; Wed, 24 Jan 2018 14:51:04 -0800 (PST) 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=rg3UXNDW58VX9yyxMfLTEkQryT0aIwLC8TBNy6ow+yM=; b=ZpP1f2LBmIfcHxKTSCxC6lBF+X/6l1ChFTIL8wkSJSEssCOOzH3LV9XZYBQKIAuKxf favO0xnfv+p+tkykmVtzabdMzBWkYceDeOR7hYKc3azwFBm+ExkoB7pu1nz/W1kR1psX U3n53T1tNMK8DY89m24LVsTMXEN67ONGCk61BD1gKPRlMYlQYzGrZTBQo3i8USJxLnsL 1Kz4Jn9RgDcJJmdzyBw/vykqZWgfpxOrs/TnA4xY2zN6J6puHnE8V3X6Aq+yXlG4N1Ih n0sDgU6aRnbr49clgfKu5IFQCSk35LZnRDAJ8Yi1POV1KBscCCQMbyN8PNK9pMhzdkd4 aW6w== 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=rg3UXNDW58VX9yyxMfLTEkQryT0aIwLC8TBNy6ow+yM=; b=VOSHq0XNpvlJ4pdR0IBgs2bhTQwa7BeRt3chaTg7DN+vZN6s9qe8eWBNbrJeTE4kDV zVSKthx8JleVIpWy3MOSVgblPqll3LsOwmR7yfEBRsR2sNhd88KO4Jbi5Py6u+h2dWqM oXgv6pVxJ3SYl33GIrKoTwXbWvBIcsJUyIbijxh6F5JFSeVxVI6z9Yimy2NkAspFG2te nC2muH5973on/mTIfJW/bTEVGnEd+EYawyBzNqcbg6BifCg5AACKuZZJI+KLp2wQsLsM deKHiByXtUkQQmZwvN4UmhvS4HVrkTEjBbKICpiMMDrVjhdS3LzFUi2Sg9CITS0ISQQF srdA== X-Gm-Message-State: AKwxytdfLxqx/P4qajx40g3eO04P3Dqw87lE23k8GmueHyiXCt7fmsL6 aHLpX50iGzNxiKFHR4eg/12arIm6Jq1D3WKjvOydfg== X-Google-Smtp-Source: AH8x227zVb6/kDEgrFAajaF7+Z2luY3GhmZxbWTFefey0Fyo079Az6et3o5kbk1vq5gXJXMRUQ6hI8iHIcaW55W+ZXM= X-Received: by 10.36.0.209 with SMTP id 200mr10262534ita.4.1516834264398; Wed, 24 Jan 2018 14:51:04 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 24 Jan 2018 17:51:03 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 24 Jan 2018 17:51:03 -0500 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c1408883407c05638d7f65" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 22:51:07 -0000 --001a11c1408883407c05638d7f65 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t understand this requirement for the CID to be 16 bytes in o= rder to be encrypted. If you have a unique key you can encrypt 0, truncate and xor with the CID. If you don=E2=80=99t have a unique key, you can encrypt a unique counter va= lue and do the same, or derive a unique key. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 24 January 2018 at 23.37.30, Eric Rescorla (ekr@rtfm.com) wrote: Hi folks, We didn't really reach a conclusion, but here's, I think what there was at least some support for: - The long header has a variable length connection ID which has an explicit length field on the wire, with a max length (strawman: 32 bytes). The exact wire encoding to be designed by the editor. Similarly, NEW_CONNECTION_ID would have a variable length encoding. - The short header has a variable length connection ID which has an implicit length (i.e., it cannot be decoded unambiguously by an observer who is not part of the connection). However, the CID may be self-describing, so that the server may include a length field if it so chooses. There was rough consensus on the second point, but some disagreement about the first point. The major alternative proposal was to have a fixed-length CID field in the long header and NEW_CONNECTION_ID and then truncate it to an amount carried in transport_parameters. This would have the benefit that the length of the CID would be throughout the connection whereas if we wanted that rule for the other design we would need a rule. One thing that makes this second approach unattractive is that we want the server to be able to use a 16 byte connection ID (thus allowing it to be AES-encrypted) but it also needs to be able to include meta-data, such as a key-id for rotation or potentially a length. This tells us that you need to have a maximum connection ID larger than 16 bytes, and having a fixed 17-20 byte CID seems odd. -Ekr --001a11c1408883407c05638d7f65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I don=E2=80=99t unde= rstand this requirement for the CID to be 16 bytes in order to be encrypted= .
    If you have= a unique key you can encrypt 0, truncate and xor with the CID.
    If you don=E2=80=99t hav= e a unique key, you can encrypt a unique counter value and do the same, or = derive a unique key.


    Kind= Regards,
    Mi= kkel Fahn=C3=B8e J=C3=B8rgensen


    On 24 January 2018 at 23.37.30, Eric Rescorla (ekr@rtfm.com) wrote:

    Hi folks,

    We didn't really reach a conclusion, but here's, I think what there
    was at least some support for:

    - The long header has a variable length connection ID which has an
    =C2=A0 explicit length field on the wire, with a max length (strawman: 32
    =C2=A0 bytes). The exact wire encoding to be designed by the editor.
    =C2=A0 Similarly, NEW_CONNECTION_ID would have a variable length
    =C2=A0 encoding.

    - The short header has a variable length connection ID which has
    =C2=A0 an implicit length (i.e., it cannot be decoded unambiguously
    =C2=A0 by an observer who is not part of the connection). However,
    =C2=A0 the CID may be self-describing, so that the server may include
    =C2=A0 a length field if it so chooses.

    There was rough consensus on the second point, but some disagreement
    about the first point. The major alternative proposal was to have
    a fixed-length CID field in the long header and NEW_CONNECTION_ID
    and then truncate it to an amount carried in transport_parameters.
    This would have the benefit that the length of the CID would be
    throughout the connection whereas if we wanted that rule for the
    other design we would need a rule.

    One thing that makes this second approach unattractive is that we want
    the server to be able to use a 16 byte connection ID (thus allowing it
    to be AES-encrypted) but it also needs to be able to include
    meta-data, such as a key-id for rotation or potentially a length. This
    tells us that you need to have a maximum connection ID larger than 16
    bytes, and having a fixed 17-20 byte CID seems odd.

    -Ekr





    =C2=A0 =C2=A0


    =C2=A0=C2=A0

    --001a11c1408883407c05638d7f65-- From nobody Wed Jan 24 14:54:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C027B12D779 for ; Wed, 24 Jan 2018 14:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.69 X-Spam-Level: X-Spam-Status: No, score=-2.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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=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 kY7CqrTa6XYN for ; Wed, 24 Jan 2018 14:54:24 -0800 (PST) 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 3E5CD12AF84 for ; Wed, 24 Jan 2018 14:54:24 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0OMqXjq007257; Wed, 24 Jan 2018 22:53:32 GMT 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=+v4PG9CvkEKySiplprFUunq6CTYYsOalcnvJr/pxH5E=; b=nUtXSVnOFR8yLCFG38NEgVr2guXRVIuUiznk9usd+tw6O64pKqQpXWaXjkq/iGoeadmE 2YMEi2kWyFZaMY2OniWw6390fAk6mlv8pwQNJP8mk+3sHdF2Uym0G8ZFKJ3kOK5sAnLR PFx4eZGO4YMzgSzxvaee2AycqNIQLnMg52GI8tujIipUON8bKkliuiL/vuzwu3J7cysX OzeRfya4Ak+1sAsj9Q4q6oeFt+71DZ1zv8Iao0mKOwxrBjvgh5GphQQ8MIvvF/6C1hOK IGdzGwpjsj5Lp1p9UTXgpJsP8Xb/VMMY3KNhx81kD2bO6MzNhH0CY2gDq72hWOqmtE9s 9w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2fkx69mt46-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 22:53:32 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0OMjleH031064; Wed, 24 Jan 2018 17:53:30 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fm1yyqa3f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 17:53:30 -0500 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; Wed, 24 Jan 2018 17:53:30 -0500 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, 24 Jan 2018 17:53:29 -0500 From: "Lubashev, Igor" To: Christian Huitema , Ingemar Johansson S , QUIC WG CC: "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1AADTxqAAAJCiHA Date: Wed, 24 Jan 2018 22:53:29 +0000 Message-ID: <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> In-Reply-To: <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> 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.239] Content-Type: multipart/alternative; boundary="_000_26b97168c48047018d1dfe6400a36b16usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240296 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240297 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 22:54:27 -0000 --_000_26b97168c48047018d1dfe6400a36b16usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayBJIGxpa2UgYSBwZXItcGFja2V0IGJpdG1hcC4gIElmIHlvdSBhcmUgQUNLaW5nIDMw IHBhY2tldHMsIGl0IGlzIG9ubHkgOCBieXRlcy4gIFRoZSBhZHZhbnRhZ2Ugb2YgcGVyLXBhY2tl dCBiaXRtYXAgaXMgdGhhdCB5b3UgZG8gbm90IG5lZWQgdG8gc3BsaXQgQUNLIEJsb2NrcyDigJMg c2F2aW5ncyByaWdodCB0aGVyZS4NCg0KDQogICogICBJZ29yDQoNCkZyb206IENocmlzdGlhbiBI dWl0ZW1hIFttYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldF0NClNlbnQ6IFdlZG5lc2RheSwgSmFu dWFyeSAyNCwgMjAxOCA0OjM4IFBNDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5z LmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFp LmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpDYzogQm9iIEJyaXNjb2UgKHJlc2VhcmNo QGJvYmJyaXNjb2UubmV0KSA8cmVzZWFyY2hAYm9iYnJpc2NvZS5uZXQ+OyBrb2VuLmRlX3NjaGVw cGVyQG5va2lhLWJlbGwtbGFicy5jb20NClN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQw0KDQoNCg0K DQpPbiAxLzI0LzIwMTggMTA6NTEgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgd3JvdGU6DQpIaQ0K DQpDb21tZW50IG9uIOKAnENFIGlzIG5vdCBnb2luZyB0byBiZSBhIHZlcnkgY29tbW9uIG9jY3Vy cmVuY2XigJ0uDQpXaGlsZSB0aGF0IG1heSBiZSB0cnVlIGZvciAoYWxtb3N0KSBkcm9wIGVxdWl2 YWxlbnQgRUNOIChhLmsuYS4gY2xhc3NpYyksIGl0IGRvZXMgdW5mb3J0dW5hdGVseSBub3QgaG9s ZCBhdCBhbGwgZm9yIEw0Uy4gVHlwaWNhbCB2YWx1ZXMgb2YgRUNOIG1hcmtpbmcgcmF0aW8gd2l0 aCBMNFMgaXMgaW4gdGhlIG9yZGVyIG9mIDEwIHRvIDUwJS4gSW4gYWRkaXRpb24gdGhlIENFIG1h cmtzIGNhbiBiZSBzcHJlYWQgcmFuZG9tbHkgKGZvciBpbnN0YW5jZSB3aXRoIHBoYW50b20gcXVl dWVzKS4NClRoaXMgbWVhbnMgdGhhdCB0aGUgQUNLIGJsb2NrcyBpbiB0aGUgc3VnZ2VzdGVkIGZv cm1hdCBiZWxvdyBjYW4gYmVjb21lIHZlcnkgc2hvcnQsIGluIHRoZSB3b3JzdCBjYXNlIHJlcHJl c2VudGluZyBvbmx5IG9uZSBwYWNrZXQgcGVyIEFDSyBibG9jayBpZiB3ZSBoYXZlIGFuIGFsdGVy bmF0aW5nIEVDVC1DRS1FQ1QtQ0XigKYgcGF0dGVybiBpbiB0aGUgcmVjZWl2ZWQgcGFja2V0cy4N Clllcy4NCg0KDQpTbyBteSB0YWtlIGlzIHRoYXQgaWYgYW4gRUNOIGJpdCBwYXR0ZXJuIGlzIHJl YWxseSBuZWNlc3NhcnkgdGhlbiBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBpdCBhcyBhbiBiaXRtYXAg dGhhdCByZXByZXNlbnRzIGFsbCBwYWNrZXRzIHRoYXQgYXJlIGxpc3RlZCBpbiB0aGUgQUNLIGJs b2NrLiBJZiBvbmUgbWFrZSBhbiBhc3N1bXB0aW9uIHRoYXQgYW4gQUNLIGZyYW1lIGNvbnRhaW5z IHR3byBBQ0sgYmxvY2tzIHRoYXQgQUNLcyA1IGFuZCA3IHBhY2tldHMgdGhlbiB0aGUgRUNOIGJs b2NrIHdpbGwgYmVjb21lICg1KzcpKjIgPSAyNGJpdHMgLCBpLmUuIDMgb2N0ZXRzLg0KWWVzLCB3 ZSBoYXZlIHRvIHRha2UgdGhhdCBpbnRvIGFjY291bnQgaW4gdGhlIGRlc2lnbi4NCg0KDQpCdXQg d2l0aCB0aGF0IHNhaWQgSSBhbSBzdGlsbCBub3QgY29udmluY2VkIHRoYXQgdGhlIHBhY2tldCBj b3VudGVyIGFwcHJvYWNoIGlzIGZsYXdlZCAoSeKAmW0gYW0gaGFwcHkgdG8gYmUgZW5saWdodGVu ZWQg8J+YiikgLg0KVGFraW5nIG11bHRpcGF0aCBhcyBhbiBleGFtcGxlIDogSXNu4oCZdCBpdCB0 aGUgY2FzZSB0aGF0IHR3byBjb25uZWN0aW9ucyBhcmUgc2V0dXAsIGVhY2ggd2l0aCBpdHMgb3du IGNvbmdlc3Rpb24gY29udHJvbCBjb250ZXh0IChJIG9taXQgY291cGxlZCBDQyBmb3IgdGhlIG1v bWVudCkuIElmIHRoYXQgaXMgdGhlIGNhc2UgdGhlbiBJIGRvbuKAmXQgc2VlIGFueSBwcm9ibGVt IHdpdGggdGhlIHBhY2tldCBjb3VudGVycy4NCg0KV2UgYXJlIGhlYWRpbmcgdG93YXJkcyBhIHNp bmdsZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIHNwYWNlIHNoYXJlZCBieSBtdWx0aXBsZSBwYXRo cy4gVGhhdCBtZWFucyB0aGF0IHdlIG5lZWQgcHJlY2lzZSBwZXIgcGFja2V0IGZlZWRiYWNrLiBJ ZiBhIHBhY2tldCB3YXMgbWFya2VkIHdpdGggQ0UsIHlvdSB3YW50IHRvIGtub3cgb24gd2hpY2gg cGF0aCwgYW5kIHRoZSB3YXkgdG8ga25vdyB0aGF0IGlzIHRvIGZpbmQgdGhlICJwYXRoIiB0YWcg aW4gdGhlIHNhdmVkIGNvcHkgb2YgdGhlIHBhY2tldC4gWW91IGNhbnQgZG8gdGhhdCB3aXRoIGNv dW50ZXJzLg0KDQoNCkFzIHJlZ2FyZHMgdG8gY29ubmVjdGlvbiBtaWdyYXRpb24uIE9uZSBwb3Nz aWJsZSBtYXR0ZXIgaXMgdGhhdCBpdCBjYW4gYmVjb21lIHRyaWNreSB0byBkZXRlY3QgRUNOIGJs ZWFjaGluZyBvciBFQ04gYml0IGFjY2VzcyBwcm9ibGVtcyBpbiBPUyBpbW1lZGlhdGVseSAsIGhv d2V2ZXIgZHVyaW5nIHRoZSBjb3Vyc2Ugb2YgMSBSVFQgb3IgZXZlbiBsZXNzLCB0aGlzIHNob3Vs ZCBiZSBwb3NzaWJsZSB0byBkZXRlY3QgYXMgZS5nLiBFQ04gYmxlYWNoaW5nIHdpbGwgcmVzdWx0 IGluIHRoYXQgdGhlIG5laXRoZXIgb24gdGhlIEVDVCgwKSxFQ1QoMSkgYW5kIENFIGNvdW50ZXJz IGluY3JlYXNlLiBCdXQgSSBhbSBmdWxseSBhd2FyZSB0aGF0IEkgbWF5IG1pc3MgdGhpbmdzIGhl cmUuDQoNCkFnYWluLCB0aGVyZSBpcyBubyBwcm9ibGVtIGlmIHdlIGhhdmUgcHJlY2lzZSBwZXIg cGFja2V0IGZlZWRiYWNrLCBiZWNhdXNlIHdlIGNhbiBmaW5kIG91dCB3aGljaCBwYWNrZXRzIHdl cmUgYmxlYWNoZWQuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_26b97168c48047018d1dfe6400a36b16usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBF bW9qaSI7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3Jt YWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBo DQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDox NjMyNzg3MTI5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotODQ3Mzc2ODg0IC0xNDU4Mzk4NjE4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+SSB0aGluayBJIGxpa2UgYSBwZXItcGFja2V0IGJpdG1hcC4mbmJzcDsg SWYgeW91IGFyZSBBQ0tpbmcgMzAgcGFja2V0cywgaXQgaXMgb25seSA4IGJ5dGVzLiZuYnNwOyBU aGUgYWR2YW50YWdlIG9mIHBlci1wYWNrZXQgYml0bWFwIGlzIHRoYXQgeW91IGRvIG5vdCBuZWVk IHRvIHNwbGl0IEFDSyBCbG9ja3Mg4oCTIHNhdmluZ3MgcmlnaHQgdGhlcmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi Pg0KSWdvcjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij4gQ2hyaXN0aWFuIEh1aXRlbWEgW21haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAyNCwgMjAx OCA0OjM4IFBNPGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSZndDs7IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNo ZUBha2FtYWkuY29tJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5D Yzo8L2I+IEJvYiBCcmlzY29lIChyZXNlYXJjaEBib2JicmlzY29lLm5ldCkgJmx0O3Jlc2VhcmNo QGJvYmJyaXNjb2UubmV0Jmd0Ozsga29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29t PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBFQ04gaW4gUVVJQzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMS8yNC8y MDE4IDEwOjUxIEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkNvbW1lbnQgb24g4oCcQ0UgaXMgbm90IGdvaW5nIHRvIGJlIGEgdmVyeSBjb21tb24gb2NjdXJy ZW5jZeKAnS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hpbGUgdGhh dCBtYXkgYmUgdHJ1ZSBmb3IgKGFsbW9zdCkgZHJvcCBlcXVpdmFsZW50IEVDTiAoYS5rLmEuIGNs YXNzaWMpLCBpdCBkb2VzIHVuZm9ydHVuYXRlbHkgbm90IGhvbGQgYXQgYWxsIGZvciBMNFMuIFR5 cGljYWwgdmFsdWVzIG9mIEVDTiBtYXJraW5nIHJhdGlvIHdpdGggTDRTIGlzIGluIHRoZSBvcmRl ciBvZiAxMCB0byA1MCUuIEluIGFkZGl0aW9uIHRoZSBDRSBtYXJrcyBjYW4gYmUgc3ByZWFkIHJh bmRvbWx5DQogKGZvciBpbnN0YW5jZSB3aXRoIHBoYW50b20gcXVldWVzKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbWVhbnMgdGhhdCB0aGUgQUNLIGJsb2NrcyBp biB0aGUgc3VnZ2VzdGVkIGZvcm1hdCBiZWxvdyBjYW4gYmVjb21lIHZlcnkgc2hvcnQsIGluIHRo ZSB3b3JzdCBjYXNlIHJlcHJlc2VudGluZyBvbmx5IG9uZSBwYWNrZXQgcGVyIEFDSyBibG9jayBp ZiB3ZSBoYXZlIGFuIGFsdGVybmF0aW5nIEVDVC1DRS1FQ1QtQ0XigKYgcGF0dGVybiBpbiB0aGUg cmVjZWl2ZWQgcGFja2V0cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllcy48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T byBteSB0YWtlIGlzIHRoYXQgaWYgYW4gRUNOIGJpdCBwYXR0ZXJuIGlzIHJlYWxseSBuZWNlc3Nh cnkgdGhlbiBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBpdCBhcyBhbiBiaXRtYXAgdGhhdCByZXByZXNl bnRzIGFsbCBwYWNrZXRzIHRoYXQgYXJlIGxpc3RlZCBpbiB0aGUgQUNLIGJsb2NrLiBJZiBvbmUg bWFrZSBhbiBhc3N1bXB0aW9uIHRoYXQgYW4gQUNLIGZyYW1lIGNvbnRhaW5zIHR3byBBQ0sgYmxv Y2tzIHRoYXQNCiBBQ0tzIDUgYW5kIDcgcGFja2V0cyB0aGVuIHRoZSBFQ04gYmxvY2sgd2lsbCBi ZWNvbWUgKDUmIzQzOzcpKjIgPSAyNGJpdHMgLCBpLmUuIDMgb2N0ZXRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCB3ZSBoYXZlIHRvIHRh a2UgdGhhdCBpbnRvIGFjY291bnQgaW4gdGhlIGRlc2lnbi48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5CdXQgd2l0aCB0aGF0IHNhaWQgSSBhbSBzdGlsbCBub3QgY29udmlu Y2VkIHRoYXQgdGhlIHBhY2tldCBjb3VudGVyIGFwcHJvYWNoIGlzIGZsYXdlZCAoSeKAmW0gYW0g aGFwcHkgdG8gYmUgZW5saWdodGVuZWQNCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMjs8L3NwYW4+KSAuIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFraW5nIG11bHRpcGF0aCBhcyBhbiBl eGFtcGxlIDogSXNu4oCZdCBpdCB0aGUgY2FzZSB0aGF0IHR3byBjb25uZWN0aW9ucyBhcmUgc2V0 dXAsIGVhY2ggd2l0aCBpdHMgb3duIGNvbmdlc3Rpb24gY29udHJvbCBjb250ZXh0IChJIG9taXQg Y291cGxlZCBDQyBmb3IgdGhlIG1vbWVudCkuIElmIHRoYXQgaXMgdGhlIGNhc2UgdGhlbiBJIGRv buKAmXQgc2VlIGFueSBwcm9ibGVtIHdpdGggdGhlIHBhY2tldCBjb3VudGVycy4NCjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KV2UgYXJl IGhlYWRpbmcgdG93YXJkcyBhIHNpbmdsZSBwYWNrZXQgc2VxdWVuY2UgbnVtYmVyIHNwYWNlIHNo YXJlZCBieSBtdWx0aXBsZSBwYXRocy4gVGhhdCBtZWFucyB0aGF0IHdlIG5lZWQgcHJlY2lzZSBw ZXIgcGFja2V0IGZlZWRiYWNrLiBJZiBhIHBhY2tldCB3YXMgbWFya2VkIHdpdGggQ0UsIHlvdSB3 YW50IHRvIGtub3cgb24gd2hpY2ggcGF0aCwgYW5kIHRoZSB3YXkgdG8ga25vdyB0aGF0IGlzIHRv IGZpbmQgdGhlICZxdW90O3BhdGgmcXVvdDsgdGFnIGluDQogdGhlIHNhdmVkIGNvcHkgb2YgdGhl IHBhY2tldC4gWW91IGNhbnQgZG8gdGhhdCB3aXRoIGNvdW50ZXJzLiA8YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgcmVnYXJkcyB0byBj b25uZWN0aW9uIG1pZ3JhdGlvbi4gT25lIHBvc3NpYmxlIG1hdHRlciBpcyB0aGF0IGl0IGNhbiBi ZWNvbWUgdHJpY2t5IHRvIGRldGVjdCBFQ04gYmxlYWNoaW5nIG9yIEVDTiBiaXQgYWNjZXNzIHBy b2JsZW1zIGluIE9TIGltbWVkaWF0ZWx5ICwgaG93ZXZlciBkdXJpbmcgdGhlIGNvdXJzZSBvZiAx IFJUVCBvciBldmVuIGxlc3MsIHRoaXMgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGRldGVjdA0KIGFz IGUuZy4gRUNOIGJsZWFjaGluZyB3aWxsIHJlc3VsdCBpbiB0aGF0IHRoZSBuZWl0aGVyIG9uIHRo ZSBFQ1QoMCksRUNUKDEpIGFuZCBDRSBjb3VudGVycyBpbmNyZWFzZS4gQnV0IEkgYW0gZnVsbHkg YXdhcmUgdGhhdCBJIG1heSBtaXNzIHRoaW5ncyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQpBZ2FpbiwgdGhlcmUgaXMgbm8gcHJvYmxlbSBpZiB3ZSBoYXZlIHByZWNpc2UgcGVy IHBhY2tldCBmZWVkYmFjaywgYmVjYXVzZSB3ZSBjYW4gZmluZCBvdXQgd2hpY2ggcGFja2V0cyB3 ZXJlIGJsZWFjaGVkLjxicj4NCjxicj4NCi0tIENocmlzdGlhbiBIdWl0ZW1hPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_26b97168c48047018d1dfe6400a36b16usma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 15:16:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0378712D810 for ; Wed, 24 Jan 2018 15:16:57 -0800 (PST) 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 vNQHcdMLIzQN for ; Wed, 24 Jan 2018 15:16:55 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2FC12AF84 for ; Wed, 24 Jan 2018 15:16:55 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id b129so2166575ywa.8 for ; Wed, 24 Jan 2018 15:16:55 -0800 (PST) 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=uFnoxN8MA43u/sqeaKMpiHweP38DouMirgzzareUxNY=; b=dcXjzlh0bWzuub0OxD106bZfqHwSQ4hQ8DlvBk1d2RcAU5/fd/MCzpepjbB8a8KyLt z82CgFhodoIWkfYxCVAcdqle2p3Ws4QzDLji6u17osfVhziLgBwo5zIYAyA1XME4u/N9 Bfd4BcLEmsXUbYGVr1bNyBqLh1WpKGbhaeAPZwGVGJGba3m/QN6ymwlzeNAlTIgA4+W7 vlHDm3E4epA9t54O1tphhcD+UoA98/zUIm5VS8McQ8jPFJpzZ9ddG4ypcsooSN/fpNTy Be0tkoEUfM79FatlWsJkRn5hJLtsgxj4dEQFByE1//KkxhqAc9I7SpB8P+vYJSTZfr8e pqMQ== 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=uFnoxN8MA43u/sqeaKMpiHweP38DouMirgzzareUxNY=; b=YLFDUh30djglefYmdIlRhQHXXVzPXf8d9+DLHp+KwtvnOhoFhv0K3M+k4eh5xx+NkK /TaEq7TXz3EbOCITkK13HOGfp7EJK37EuqGMz6x5FV8aKmHd5yc+xzHS4Fx207SAhKGi 9ktU+sSyv2pTAGd85/5Awc09dp+LYJjHpTk619BOVR8vpHqgPjjTtCsvEtV3Ahds0rPA uXplABiE6+y35t2YSKortkNkcwq6mk8pQRDjK1XZZgJcbWaoK0eJHVA0D4T+FC2vut5o FRzKIwmvYn9EijrxKVSdSlomUJVM3Kij+uN7gmLLtpdledMvCjW9prIR7Wlz5SqEtkQu ciAQ== X-Gm-Message-State: AKwxytfzWk+ppB0z531dzIPujlqq6lcHlNUnjJLjBVNFq4ND8KuewWJo tL3M8LrENb7vB49S7hD2xrzpyJwcHYKPn5qkVXLe4Q== X-Google-Smtp-Source: AH8x224rovECQ97raDlwueL/+dNdpiVEurAegegvw94PeTQe+osKiD4q+mp+NI7/Hkny6lRI0vE11Q9EGD5kcreSjNQ= X-Received: by 10.129.172.74 with SMTP id z10mr6758745ywj.363.1516835814351; Wed, 24 Jan 2018 15:16:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Wed, 24 Jan 2018 15:16:13 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 24 Jan 2018 15:16:13 -0800 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045f3e40e5aa4005638ddb7c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 23:16:57 -0000 --f403045f3e40e5aa4005638ddb7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 24, 2018 at 2:51 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I don=E2=80=99t understand this requirement for the CID to be 16 bytes in= order to > be encrypted. > If you have a unique key you can encrypt 0, truncate and xor with the CID= . > If you don=E2=80=99t have a unique key, you can encrypt a unique counter = value and > do the same, or derive a unique key. > I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.? -Ekr > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 24 January 2018 at 23.37.30, Eric Rescorla (ekr@rtfm.com) wrote: > > Hi folks, > > We didn't really reach a conclusion, but here's, I think what there > was at least some support for: > > - The long header has a variable length connection ID which has an > explicit length field on the wire, with a max length (strawman: 32 > bytes). The exact wire encoding to be designed by the editor. > Similarly, NEW_CONNECTION_ID would have a variable length > encoding. > > - The short header has a variable length connection ID which has > an implicit length (i.e., it cannot be decoded unambiguously > by an observer who is not part of the connection). However, > the CID may be self-describing, so that the server may include > a length field if it so chooses. > > There was rough consensus on the second point, but some disagreement > about the first point. The major alternative proposal was to have > a fixed-length CID field in the long header and NEW_CONNECTION_ID > and then truncate it to an amount carried in transport_parameters. > This would have the benefit that the length of the CID would be > throughout the connection whereas if we wanted that rule for the > other design we would need a rule. > > One thing that makes this second approach unattractive is that we want > the server to be able to use a 16 byte connection ID (thus allowing it > to be AES-encrypted) but it also needs to be able to include > meta-data, such as a key-id for rotation or potentially a length. This > tells us that you need to have a maximum connection ID larger than 16 > bytes, and having a fixed 17-20 byte CID seems odd. > > -Ekr > > > > > > > > > > > --f403045f3e40e5aa4005638ddb7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On W= ed, Jan 24, 2018 at 2:51 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@= gmail.com> wrote:
    I don=E2=80=99= t understand this requirement for the CID to be 16 bytes in order to be enc= rypted.
    If you have a unique key you can encrypt 0, truncate and x= or with the CID.
    If you don=E2=80=99t have a unique key, you can e= ncrypt a unique counter value and do the same, or derive a unique key.

    I don't believe what you are de= scribing works correctly, but I'm not sure I understand your proposal. = Can you please flesh out precisely what you have in mind? In particular, wh= o is "you", who has the key, etc.?

    -Ekr<= /div>



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


    On 24 January 2018 = at 23.37.30, Eric Rescorla (ekr@rtfm.com) wrote:

    Hi folks,

    We didn't really reach a conclusion, but here's, I think what there
    was at least some support for:

    - The long header has a variable length connection ID which has an
    =C2=A0 explicit length field on the wire, with a max length (strawman: 32
    =C2=A0 bytes). The exact wire encoding to be designed by the editor.
    =C2=A0 Similarly, NEW_CONNECTION_ID would have a variable length
    =C2=A0 encoding.

    - The short header has a variable length connection ID which has
    =C2=A0 an implicit length (i.e., it cannot be decoded unambiguously
    =C2=A0 by an observer who is not part of the connection). However,
    =C2=A0 the CID may be self-describing, so that the server may include
    =C2=A0 a length field if it so chooses.

    There was rough consensus on the second point, but some disagreement
    about the first point. The major alternative proposal was to have
    a fixed-length CID field in the long header and NEW_CONNECTION_ID
    and then truncate it to an amount carried in transport_parameters.
    This would have the benefit that the length of the CID would be
    throughout the connection whereas if we wanted that rule for the
    other design we would need a rule.

    One thing that makes this second approach unattractive is that we want
    the server to be able to use a 16 byte connection ID (thus allowing it
    to be AES-encrypted) but it also needs to be able to include
    meta-data, such as a key-id for rotation or potentially a length. This
    tells us that you need to have a maximum connection ID larger than 16
    bytes, and having a fixed 17-20 byte CID seems odd.

    -Ekr





    =C2=A0 =C2=A0


    =C2=A0=C2=A0


    --f403045f3e40e5aa4005638ddb7c-- From nobody Wed Jan 24 15:25:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1C12D82D for ; Wed, 24 Jan 2018 15:25:43 -0800 (PST) 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 AZWuieGBIGeP for ; Wed, 24 Jan 2018 15:25:41 -0800 (PST) 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 D2EA612D82F for ; Wed, 24 Jan 2018 15:25:39 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eeUQD-0005Fj-6P for quic@ietf.org; Thu, 25 Jan 2018 00:25:37 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eeUQB-00023Z-2s for quic@ietf.org; Wed, 24 Jan 2018 18:25:35 -0500 Received: (qmail 14933 invoked from network); 24 Jan 2018 23:25:33 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jan 2018 23:25:32 -0000 To: Eric Rescorla , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgense?= =?UTF-8?Q?n?= References: Cc: IETF QUIC WG From: Christian Huitema Message-ID: Date: Wed, 24 Jan 2018 13:25:28 -1000 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: Read-out on offline connection ID discussion X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nqzJw33xqhd+1V7sPy1Wa8Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftDnO5Abgbhzq/vLGjphSk2B98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIem31qZa26bve9pH GOCoYNRWjP649SQzhF817kql58kAx71HfxpF/K3Kf4qEIfLm3dpo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c0gt+Ip2etgAylqOUuwdrjDqxWbTp7eom2tU0yyNvEL bNr8czFkxBlGrlmrkRm4Mvdgg2cuJB5zEnmvXbTE40Ohx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGBS397z73V754tJpGfHTWLEvKSvC0LDy5UGAFpFuWjThW MI0eudjNfAx/UImBax7US0QsLuqHsE5aiFnFk24YY1z1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiB+8bLmJgmM+kIb9M5EAJmKx3h1vgDbEdmhrg3iVBpdRYaWs6IUuJBubcrmw77x7yKGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 23:25:43 -0000 I get the argument for 16+n, var length, etc. But I am concerned that the specific length, and maybe the clear text prefixes of a CID, can be used for fingerprinting, and then provide linkability. -- Christian Huitema From nobody Wed Jan 24 15:46:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8E512D849 for ; Wed, 24 Jan 2018 15:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg589086qnQc for ; Wed, 24 Jan 2018 15:46:27 -0800 (PST) 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 E2A6912D7F4 for ; Wed, 24 Jan 2018 15:46:27 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0ONgLaI009773; Wed, 24 Jan 2018 23:46:20 GMT 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=5X/Pe/Rs/5jHMvMImUm8ViMIxOSbiUVs3+lPd9kXS34=; b=bLRCM46Q2xC+CplgXWMObSAvzM7bpSaQH1UVeq6xnVRYZu/CdykL+xlZOyYbSFAX8OhL fdzAitjd49Y0SAkKUhuCaMbR8l0snYYjbCI14dTSgQ6OThVpj+FaPzF71YiU66N51byg FkNa+D3YoDhOpZijpgQRgWMab0atuTcOzT4EkZXBc5tv67P92r87zpTd9L5WpBWriEug acZgFeHEqJ7hwWFWpCQH8IPmbrneXbjPRc2IFGx6M2tt5QH6TdiUzellQldJ4blXYfKZ 603nJJc41D/B8w6NDrUaOEnJ28fvmxr0A2Cg72b0MYBO5S1HgeynCbzCEXjcLENPmE7J Xw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2fkwwa4k8a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 23:46:19 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0ONk4XF011629; Wed, 24 Jan 2018 18:46:18 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fm1yyqe7v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 18:46:18 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 Jan 2018 18:46:17 -0500 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, 24 Jan 2018 18:46:17 -0500 From: "Lubashev, Igor" To: Christian Huitema , Eric Rescorla , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion Thread-Topic: Read-out on offline connection ID discussion Thread-Index: AQHTlWPu47NFt37BOUi/Ui44cVLNBqOD9KiAgAAHCICAAAKWAP//sUHQ Date: Wed, 24 Jan 2018 23:46:16 +0000 Message-ID: <04b6b53ef8f7490bbbfb03c3526022f8@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.33.239] 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=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=941 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240309 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=870 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801240308 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 23:46:29 -0000 PiBCdXQgSSBhbSBjb25jZXJuZWQgdGhhdCB0aGUgc3BlY2lmaWMgbGVuZ3RoLCBhbmQgbWF5YmUg dGhlIGNsZWFyIHRleHQgcHJlZml4ZXMgb2YgYSBDSUQsIGNhbiBiZSB1c2VkIGZvciBmaW5nZXJw cmludGluZywgYW5kIHRoZW4gcHJvdmlkZSBsaW5rYWJpbGl0eS4NCg0KSSB3b3VsZCBleHBlY3Qg bm9uLXRyaXZpYWwgdGhpbmdzIHRvIENJRHMgZG9uZSBieSBzZXJ2ZXJzIGluIGNsaWVudC1zZXJ2 ZXIgc2NlbmFyaW9zLCBzbyB5b3UgYXJlIGZpbmdlcnByaW50aW5nIHRoZSBzZXJ2ZXIsIG5vdCB0 aGUgY2xpZW50LiAgQWUgeW91IGNvbmNlcm5lZCB3aXRoIGEgcDJwIGNhc2U/ICANCg0KLSBJZ29y DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJpc3RpYW4gSHVpdGVtYSBb bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDI0 LCAyMDE4IDY6MjUgUE0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+DQpDYzogSUVURiBRVUlDIFdH IDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFJlYWQtb3V0IG9uIG9mZmxpbmUgY29ubmVj dGlvbiBJRCBkaXNjdXNzaW9uDQoNCkkgZ2V0IHRoZSBhcmd1bWVudCBmb3IgMTYrbiwgdmFyIGxl bmd0aCwgZXRjLiBCdXQgSSBhbSBjb25jZXJuZWQgdGhhdCB0aGUgc3BlY2lmaWMgbGVuZ3RoLCBh bmQgbWF5YmUgdGhlIGNsZWFyIHRleHQgcHJlZml4ZXMgb2YgYSBDSUQsIGNhbiBiZSB1c2VkIGZv ciBmaW5nZXJwcmludGluZywgYW5kIHRoZW4gcHJvdmlkZSBsaW5rYWJpbGl0eS4NCg0KLS0gQ2hy aXN0aWFuIEh1aXRlbWENCg0K From nobody Wed Jan 24 15:57:08 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15BAC12D830 for ; Wed, 24 Jan 2018 15:57:06 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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=fb.com header.b=dCFEpGCA; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=eCvjsKA4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZzO9QApIA95 for ; Wed, 24 Jan 2018 15:57:04 -0800 (PST) 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 165F7127078 for ; Wed, 24 Jan 2018 15:57:04 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0ONrwux007320; Wed, 24 Jan 2018 15:56:56 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=EPR3speCOCEGmQiGcpUDu54eZ8w81rIJCxB+Z4Iljmc=; b=dCFEpGCAP7RajV8TLgIixk5Xy9S1l1eO5wIjbS27pHZg3gxYSBnaz15haDoHlLIo7ANa qInni5xwjy/+ypmPAgJPXePRbgfQLwQWKeVwlXGkMkSesbw8jO4H+uHWkr8CcF6xsKd7 WW0dOd2vbrVd5qmAjVXxKxKQjx/l0qC3IQI= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fq1sw8h08-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jan 2018 15:56:56 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 24 Jan 2018 15:51:38 -0800 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=EPR3speCOCEGmQiGcpUDu54eZ8w81rIJCxB+Z4Iljmc=; b=eCvjsKA4JIwEDQWKxpAI/WVqvVmZ8hGEWOlhwq7VT4YkOoSl0P0GjGMl9rWsYsPXthXM4TG0EGCf+CD4CGLl3/YoEQcYfPO1IK2jN76Nd6tbLT7aZYW2elqMcLDrLyfVdwfUGxSCguWQ43sBM6NnGMRSMneywG+L7KUA1ofK6/M= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2182.namprd15.prod.outlook.com (52.132.131.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Wed, 24 Jan 2018 23:51:28 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Wed, 24 Jan 2018 23:51:28 +0000 From: Roberto Peon To: "Lubashev, Igor" , Christian Huitema , Eric Rescorla , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= CC: IETF QUIC WG Subject: Re: Read-out on offline connection ID discussion Thread-Topic: Read-out on offline connection ID discussion Thread-Index: AQHTlWQIcw/rnBpHIU2EI+BcfJeacaODoNeAgAAHCICAAAKVAIAABdAAgAAAncc= Date: Wed, 24 Jan 2018 23:51:28 +0000 Message-ID: References: , <04b6b53ef8f7490bbbfb03c3526022f8@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <04b6b53ef8f7490bbbfb03c3526022f8@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2182; 7:ertrt/H0o29S1QNUVqqD162+ETSVMAnJB+5PIL2TAey1ELpLEJqDuYCxeGKZ3+LszqTBtynkl1b9PCjlAMjLdT6cHe2KgJ5zxnHUaVhv4Fpxxh+4oSl03KfKbnMiIFaTB4XsTb8cduw72lDw9MRduaSeld9GYNuE8v/zIW97ZSwja9m8IfhB5ZTbGRPPpUBoJDEgjdtN1ALDbCcsn9STIxIYt9HIHoKp/2exec9u5rQleLiflYQTxhE00Wui1VFU; 20:C+fJuPU63pzwAKqQ2PmO83POX7ODRZQlHq0zPfukPtLWfU7mZxlfmN8EEDYh7BuhzhYLA3nr+DpzZWpFUb+Ks03RKAd8Z17pnefxJIGAcU4i85rgQw7vSt6jQm2vSy9+dSdRTlb45qiS0JXz+5YFhDwm1AC5aFRX/hbXuSPZs9s= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bd52ce36-c9d2-474a-a38f-08d5638562dd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2182; x-ms-traffictypediagnostic: DM5PR1501MB2182: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231023)(11241501184)(2400081)(944501161)(3002001)(6041288)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR1501MB2182; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2182; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(366004)(396003)(39380400002)(346002)(199004)(189003)(13464003)(105586002)(102836004)(8676002)(106356001)(93886005)(3280700002)(53546011)(5660300001)(7736002)(25786009)(74316002)(81166006)(6506007)(7696005)(2950100002)(81156014)(99286004)(5250100002)(39060400002)(6606003)(316002)(2900100001)(186003)(54896002)(53936002)(9686003)(236005)(76176011)(66066001)(110136005)(33656002)(6246003)(2906002)(229853002)(55016002)(19627405001)(14454004)(8936002)(4326008)(68736007)(3846002)(6116002)(6436002)(478600001)(86362001)(3660700001)(97736004)(26005)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2182; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VmYU7zDqXvd6gauuTTH6vk1L3fY9VFgR2uEZqXh1e+K6XrMac0WN8TlOqM3QdL4xn+B8T+tcDwlWnpu/SH1r0Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR1501MB218377CAC296DA62336310DDCDE20DM5PR1501MB2183_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bd52ce36-c9d2-474a-a38f-08d5638562dd X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 23:51:28.1723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2182 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Jan 2018 23:57:06 -0000 --_000_DM5PR1501MB218377CAC296DA62336310DDCDE20DM5PR1501MB2183_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Imagine allowing the server to send multiple CIDs, and provide the server w= ith some revocation mechanism (TTL or explicit, or what-have-you). A client may use any of these CIDs until they are revoked. Thus, a server which cares to prevent ossification could provide multiple C= IDs, and the client could switch between them on a per-packet basis. -=3DR ________________________________ From: QUIC on behalf of Lubashev, Igor Sent: Wednesday, January 24, 2018 3:46:16 PM To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion > But I am concerned that the specific length, and maybe the clear text pre= fixes of a CID, can be used for fingerprinting, and then provide linkabilit= y. I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client. Ae you co= ncerned with a p2p case? - Igor -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net] Sent: Wednesday, January 24, 2018 6:25 PM To: Eric Rescorla ; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: Re: Read-out on offline connection ID discussion I get the argument for 16+n, var length, etc. But I am concerned that the s= pecific length, and maybe the clear text prefixes of a CID, can be used for= fingerprinting, and then provide linkability. -- Christian Huitema --_000_DM5PR1501MB218377CAC296DA62336310DDCDE20DM5PR1501MB2183_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Imagine allowing the server to se= nd multiple CIDs, and provide the server with some revocation mechanism (TT= L or explicit, or what-have-you).

    A client may use any of these CIDs until they are revoked.

    Thus, a server which cares to prevent ossification could provide = multiple CIDs, and the client could switch between them on a per-packet bas= is.

    -=3DR

    From: QUIC <quic-bounces= @ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
    Sent: Wednesday, January 24, 2018 3:46:16 PM
    To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG
    Subject: RE: Read-out on offline connection ID discussion
     
    > But I am concerned that the specific length, = and maybe the clear text prefixes of a CID, can be used for fingerprinting,= and then provide linkability.

    I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client.  Ae y= ou concerned with a p2p case? 

    - Igor

    -----Original Message-----
    From: Christian Huitema [mailto:huit= ema@huitema.net]
    Sent: Wednesday, January 24, 2018 6:25 PM
    To: Eric Rescorla <ekr@rtfm.com>; Mikkel Fahn=F8e J=F8rgensen <mik= kelfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: Read-out on offline connection ID discussion

    I get the argument for 16+n, var length, etc. But I am concerned that t= he specific length, and maybe the clear text prefixes of a CID, can be used= for fingerprinting, and then provide linkability.

    -- Christian Huitema

    --_000_DM5PR1501MB218377CAC296DA62336310DDCDE20DM5PR1501MB2183_-- From nobody Wed Jan 24 16:12:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF72F12D835 for ; Wed, 24 Jan 2018 16:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6_wTQVF4H0Nn for ; Wed, 24 Jan 2018 16:12:48 -0800 (PST) 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 AAF9912D831 for ; Wed, 24 Jan 2018 16:12:48 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0P0CVV9015766; Thu, 25 Jan 2018 00:12:31 GMT 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=R6UKuBeNwjaJNqov52IAN5xxxYIGCUPdW0ZBWvRrP30=; b=jsn04mvdXQv9kQVkvcUgcs+Goa9Mo2HFs8kHFThovEWqlq05EBF2yLoFVyYU6b9Zj2h8 iJ2CxAl8kOPKhZ6EwlwRhazundcE1wZ9zjU06PWyIEspCKvUuQ3AFw5vPrSDbLcKUObw igtIikmsZavI0fov9Ulo35bY54QA1V+kggf0cuF4JODJIe8xL57mm20N6vzQABzw3Gvs G6ev8RVn+dViBFjhpSyEYteRyMVXO0l9Sb/hmETaKL1KC+RPiYfyBXiO4CJDj+f7ELy5 ROW1OgRkczgAPA4OPzyUAZwiKCDwa7WtM3dQumgOOjZh587YVKR7/mKTUVqVT9BsS6Gg FA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgwxmn9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 00:12:31 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0P0AXRP023220; Wed, 24 Jan 2018 19:12:30 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fm200n2jw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 24 Jan 2018 19:12:30 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 24 Jan 2018 19:12:28 -0500 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, 24 Jan 2018 19:12:28 -0500 From: "Lubashev, Igor" To: Roberto Peon , Christian Huitema , "Eric Rescorla" , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= CC: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion Thread-Topic: Read-out on offline connection ID discussion Thread-Index: AQHTlWPu47NFt37BOUi/Ui44cVLNBqOD9KiAgAAHCICAAAKWAP//sUHQgABWAwD//67rUA== Date: Thu, 25 Jan 2018 00:12:28 +0000 Message-ID: References: , <04b6b53ef8f7490bbbfb03c3526022f8@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.239] Content-Type: multipart/alternative; boundary="_000_f35d6dfb1fa9460fb623c0cae028fe56usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=711 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250001 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1031 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=653 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250001 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 00:12:51 -0000 --_000_f35d6dfb1fa9460fb623c0cae028fe56usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are worried that the client's privacy can be compromised by CIDs lin= kable to the same server, I'd be worried that server's IP will give this aw= ay even more reliably. * Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Wednesday, January 24, 2018 6:51 PM To: Lubashev, Igor ; Christian Huitema ; Eric Rescorla ; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: Re: Read-out on offline connection ID discussion Imagine allowing the server to send multiple CIDs, and provide the server w= ith some revocation mechanism (TTL or explicit, or what-have-you). A client may use any of these CIDs until they are revoked. Thus, a server which cares to prevent ossification could provide multiple C= IDs, and the client could switch between them on a per-packet basis. -=3DR ________________________________ From: QUIC > on behalf = of Lubashev, Igor > Sent: Wednesday, January 24, 2018 3:46:16 PM To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion > But I am concerned that the specific length, and maybe the clear text pre= fixes of a CID, can be used for fingerprinting, and then provide linkabilit= y. I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client. Ae you co= ncerned with a p2p case? - Igor -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net] Sent: Wednesday, January 24, 2018 6:25 PM To: Eric Rescorla >; Mikkel Fahn=F8e J=F8= rgensen > Cc: IETF QUIC WG > Subject: Re: Read-out on offline connection ID discussion I get the argument for 16+n, var length, etc. But I am concerned that the s= pecific length, and maybe the clear text prefixes of a CID, can be used for= fingerprinting, and then provide linkability. -- Christian Huitema --_000_f35d6dfb1fa9460fb623c0cae028fe56usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    If you are worried that the client’s privacy c= an be compromised by CIDs linkable to the same server, I’d be worried= that server’s IP will give this away even more reliably.<= /p>

     

    • Igor

     

    From: Roberto Peon [mailto:fenix@fb.com]
    Sent: Wednesday, January 24, 2018 6:51 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema &l= t;huitema@huitema.net>; Eric Rescorla <ekr@rtfm.com>; Mikkel Fahn= =F8e J=F8rgensen <mikkelfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: Read-out on offline connection ID discussion=

     

    Imagine allowing the server= to send multiple CIDs, and provide the server with some revocation mechani= sm (TTL or explicit, or what-have-you).

    A client may use any of these CIDs until they are revoked.

    Thus, a server which cares to prevent ossification could provide = multiple CIDs, and the client could switch between them on a per-packet bas= is.

    -=3DR

    From: QUIC <q= uic-bounces@ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
    Sent: Wednesday, January 24, 2018 3:46:16 PM
    To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG
    Subject: RE: Read-out on offline connection ID discussion

     

    > But I am concern= ed that the specific length, and maybe the clear text prefixes of a CID, ca= n be used for fingerprinting, and then provide linkability.

    I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client.  Ae y= ou concerned with a p2p case? 

    - Igor

    -----Original Message-----
    From: Christian Huitema [mailto:huit= ema@huitema.net]
    Sent: Wednesday, January 24, 2018 6:25 PM
    To: Eric Rescorla <ekr@rtfm.com>;= Mikkel Fahn=F8e J=F8rgensen <mikk= elfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>=
    Subject: Re: Read-out on offline connection ID discussion

    I get the argument for 16+n, var length, etc. But I am concerned that t= he specific length, and maybe the clear text prefixes of a CID, can be used= for fingerprinting, and then provide linkability.

    -- Christian Huitema

    --_000_f35d6dfb1fa9460fb623c0cae028fe56usma1exdag1mb5msgcorpak_-- From nobody Wed Jan 24 16:20:49 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65E512D831 for ; Wed, 24 Jan 2018 16:20:48 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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=fb.com header.b=dXB2y1xi; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Y7Ok2lMj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvxXwDZXX_ZG for ; Wed, 24 Jan 2018 16:20:46 -0800 (PST) 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 42EC31200C1 for ; Wed, 24 Jan 2018 16:20:46 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0P0J15b026222; Wed, 24 Jan 2018 16:20:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=zcQ4KkWJ6Iq0hNaS0VyS/DTnmMQKnwtlUPcvwckuL6Q=; b=dXB2y1xitN8nQ2/XkJc9Wt6LNTkQb1CZFuvrCiO8wYL2KvF/miWfgFW8zbdcfGT6AMXv 5YjKnrdinBCgm0OqVtSFu+nJIO5IwfPfg/QxF4iV03f926/+1wGeJDjFpruaP3Ir1Vna RZSHLeCpqVixJPWULrXJu2QVtlZUe6TWJZo= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fq1sw8ker-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 24 Jan 2018 16:20:36 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 24 Jan 2018 19:20:33 -0500 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=zcQ4KkWJ6Iq0hNaS0VyS/DTnmMQKnwtlUPcvwckuL6Q=; b=Y7Ok2lMjTQCKYvPkDpDjIUhdARQXagtQClLu+sfhk+NrrTRJl0XxTjH6i+eac/tP0CCqjeHjB0htKFGCmHL+XhwBfJtdEmT6acXvkXIbFsq4si/WIaU2w/E7+TnZz/sC+RrlPWPicSQoGw7Tjkl5WLzoVjzYmcMvgJRKRXMad88= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.18; Thu, 25 Jan 2018 00:20:31 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0428.014; Thu, 25 Jan 2018 00:20:31 +0000 From: Roberto Peon To: "Lubashev, Igor" , Christian Huitema , Eric Rescorla , =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= CC: IETF QUIC WG Subject: Re: Read-out on offline connection ID discussion Thread-Topic: Read-out on offline connection ID discussion Thread-Index: AQHTlWQIcw/rnBpHIU2EI+BcfJeacaODoNeAgAAHCICAAAKVAIAABdAAgAAAnceAAAa1AIAAAMqW Date: Thu, 25 Jan 2018 00:20:31 +0000 Message-ID: References: , <04b6b53ef8f7490bbbfb03c3526022f8@usma1ex-dag1mb5.msg.corp.akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.170.5.21] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB2183; 7:2g/vNvd/qtjmFTGHj2v2wRPMYaY0VIypYtc9gCStHuL0xd2YpbwchZB7oM1t1oApZAGnafD/OAC5OXF6PLF/qZIa2GAJ8GyjtgH2Dk6ZLq/IO22Z6UkZxizz5wrNRAIPHubD77Rj1Q92DxodcmI5neTycd16ty/Pr0AIv8fcapb28uBkYRy+BGG1cR1ramqXrb+4aIG5SIKhvr4QqOkvOUlGd/lu+T5wjIC4vo/xJGtKIt9LTXzu1T4oTWDb5krR; 20:tdjxwIvmr+wh2e5CDfR96n5c9ITvoppyASR3vtQZKCZRyeIonq3XedND66GIbxqSDfNDWMSmeZy/oD2xH10YsXU9oAdcmxyeKT/NdXZCoV8fv1iqAUDXrbtNtHD0PqBV4oJ/w3/qpFn/UaxyBV1XvPt3fEULaP/XPj7yu+74q0g= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4ef51c72-ba94-4f1c-97ee-08d563897222 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB2183; x-ms-traffictypediagnostic: DM5PR1501MB2183: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231023)(11241501184)(2400081)(944501161)(3002001)(6041288)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR1501MB2183; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB2183; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(376002)(396003)(346002)(39380400002)(366004)(13464003)(199004)(189003)(478600001)(6116002)(81156014)(8936002)(33656002)(99286004)(81166006)(316002)(110136005)(68736007)(3660700001)(229853002)(53936002)(93886005)(39060400002)(8676002)(4326008)(6436002)(105586002)(186003)(2906002)(3846002)(2900100001)(54896002)(97736004)(7696005)(2950100002)(6246003)(3280700002)(19627405001)(5660300001)(5250100002)(6606003)(26005)(86362001)(106356001)(74316002)(7736002)(59450400001)(66066001)(25786009)(53546011)(6506007)(9686003)(102836004)(76176011)(236005)(14454004)(55016002)(42262002)(19627235001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB2183; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1ccMDF1DJAgtntFTjQQKH2F3hB5mrTo0euzUePGnWIA3syTuzgnUnRtqpGmYR5BeHZ4HILNzUP5zXSDM55qL/w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR1501MB21832F46144D4149CBCD17BDCDE10DM5PR1501MB2183_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4ef51c72-ba94-4f1c-97ee-08d563897222 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 00:20:31.7926 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB2183 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-24_09:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 00:20:49 -0000 --_000_DM5PR1501MB21832F46144D4149CBCD17BDCDE10DM5PR1501MB2183_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I suspect you mean the 5-tuple, and not just the server IP, as that leaks m= ore information. I agree that (the 5-tuple and/or server address) gives away information. I suspect it makes it somewhat more difficult. Once multipath and/or 5-tupl= e migration is available, the combinations of 5-tuple plus CID changes does= provide some substantial improvements. Regardless, it is certainly helpful to prevent ossification, which is what = I was commenting on. -=3DR ________________________________ From: Lubashev, Igor Sent: Wednesday, January 24, 2018 4:12:28 PM To: Roberto Peon; Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rge= nsen Cc: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion If you are worried that the client=92s privacy can be compromised by CIDs l= inkable to the same server, I=92d be worried that server=92s IP will give t= his away even more reliably. * Igor From: Roberto Peon [mailto:fenix@fb.com] Sent: Wednesday, January 24, 2018 6:51 PM To: Lubashev, Igor ; Christian Huitema ; Eric Rescorla ; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: Re: Read-out on offline connection ID discussion Imagine allowing the server to send multiple CIDs, and provide the server w= ith some revocation mechanism (TTL or explicit, or what-have-you). A client may use any of these CIDs until they are revoked. Thus, a server which cares to prevent ossification could provide multiple C= IDs, and the client could switch between them on a per-packet basis. -=3DR ________________________________ From: QUIC > on behalf = of Lubashev, Igor > Sent: Wednesday, January 24, 2018 3:46:16 PM To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG Subject: RE: Read-out on offline connection ID discussion > But I am concerned that the specific length, and maybe the clear text pre= fixes of a CID, can be used for fingerprinting, and then provide linkabilit= y. I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client. Ae you co= ncerned with a p2p case? - Igor -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net] Sent: Wednesday, January 24, 2018 6:25 PM To: Eric Rescorla >; Mikkel Fahn=F8e J=F8= rgensen > Cc: IETF QUIC WG > Subject: Re: Read-out on offline connection ID discussion I get the argument for 16+n, var length, etc. But I am concerned that the s= pecific length, and maybe the clear text prefixes of a CID, can be used for= fingerprinting, and then provide linkability. -- Christian Huitema --_000_DM5PR1501MB21832F46144D4149CBCD17BDCDE10DM5PR1501MB2183_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    I suspect you mean the 5-tuple, a= nd not just the server IP, as that leaks more information.


    I agree that (the 5-tuple and/or server address) gives away information. I suspect it makes it somewhat more difficult. Once multipath and/or 5-tupl= e migration is available, the combinations of 5-tuple plus CID changes does= provide some substantial improvements.

    Regardless, it is certainly helpful to prevent ossification, which is = what I was commenting on.
    -=3DR

    From: Lubashev, Igor <il= ubashe@akamai.com>
    Sent: Wednesday, January 24, 2018 4:12:28 PM
    To: Roberto Peon; Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e = J=F8rgensen
    Cc: IETF QUIC WG
    Subject: RE: Read-out on offline connection ID discussion
     

    If you are worried that the client=92s privacy can= be compromised by CIDs linkable to the same server, I=92d be worried that = server=92s IP will give this away even more reliably.

     

    • Igor

     

    From: Roberto Peon [mailto:fenix@fb.com] Sent: Wednesday, January 24, 2018 6:51 PM
    To: Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema &l= t;huitema@huitema.net>; Eric Rescorla <ekr@rtfm.com>; Mikkel Fahn= =F8e J=F8rgensen <mikkelfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>
    Subject: Re: Read-out on offline connection ID discussion

     

    Imagine allowing the serve= r to send multiple CIDs, and provide the server with some revocation mechan= ism (TTL or explicit, or what-have-you).

    A client may use any of these CIDs until they are revoked.

    Thus, a server which cares to prevent ossification could provide = multiple CIDs, and the client could switch between them on a per-packet bas= is.

    -=3DR

    From: QUIC <quic-bounces@ietf.org> on behalf of Lubashev, Igor <ilubashe@akamai.com>
    Sent: Wednesday, January 24, 2018 3:46:16 PM
    To: Christian Huitema; Eric Rescorla; Mikkel Fahn=F8e J=F8rgensen Cc: IETF QUIC WG
    Subject: RE: Read-out on offline connection ID discussion

     

    > But I am conce= rned that the specific length, and maybe the clear text prefixes of a CID, = can be used for fingerprinting, and then provide linkability.

    I would expect non-trivial things to CIDs done by servers in client-server = scenarios, so you are fingerprinting the server, not the client.  Ae y= ou concerned with a p2p case? 

    - Igor

    -----Original Message-----
    From: Christian Huitema [mailto:huit= ema@huitema.net]
    Sent: Wednesday, January 24, 2018 6:25 PM
    To: Eric Rescorla <ekr@rtfm.com>;= Mikkel Fahn=F8e J=F8rgensen <mikk= elfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org>=
    Subject: Re: Read-out on offline connection ID discussion

    I get the argument for 16+n, var length, etc. But I am concerned that t= he specific length, and maybe the clear text prefixes of a CID, can be used= for fingerprinting, and then provide linkability.

    -- Christian Huitema

    --_000_DM5PR1501MB21832F46144D4149CBCD17BDCDE10DM5PR1501MB2183_-- From nobody Wed Jan 24 17:05:57 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6272E12D80E for ; Wed, 24 Jan 2018 17:05:56 -0800 (PST) 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 l_1iRQu4oDuo for ; Wed, 24 Jan 2018 17:05:54 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7122712D7F6 for ; Wed, 24 Jan 2018 17:05:54 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id d124so4165866oib.13 for ; Wed, 24 Jan 2018 17:05:54 -0800 (PST) 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=z0XG7qKlAasKO0gGiTzpzkKlLAlixsitCgf32aKb5NE=; b=E1UC/Z8SaQRZpQv4VakO1ZrtcVAX319lfgbLKQe6m93eprPT7K5rwoz5RjCeNpI84e NMIe3DHK7dbuzAOG2Q9A9Vw4KrYKsqREEO+DnM4H1nj2Re1/8se9QIwGYadmx7621V/2 VeYKY9y9mVWo8C9gSZLT4pOMXE4yCpwDGw4rNe7r9rQM/8xc2ku4kwqB/pW6KNKyf9W9 vzJ5XigBwDkmB+jCVxICww9euk7/7TtwJZtDuVlMGip7I7XTmz2ryr1BYLmO+uX50Z2T ZXk5FxKYFRX7rsfvk1R5hnELgYS6dOIgZrChL345wpczhUwF2GNFRP+OXC3mZDZ3QEIU erPg== 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=z0XG7qKlAasKO0gGiTzpzkKlLAlixsitCgf32aKb5NE=; b=s490Mdb+0x0Wszu8WBNGMT68KRP34HsXeh5e4khjtVpXi6ejHox5BBK+lJ19dldDE5 7ec0TW15OdiAmvGn9TAnblKIHqm7nmK0iapig+gJMu5StW9v/sF0zgYQKKwRlzaZ5wva WmOE2YCc1ttLpqycksZ9wr+G7zqEmDR8MCM/TwkH1dkcaxUbjZUEPMgFkFmvV5v9LOS3 s4zcYQCC67YhKUJCeVaMO5sWwVAoLU0t9hceL6EZHBM+AFl/Nd2u5Jb4B755RCzhglZS GRQJABwwD2A3hxqFNlk8N0GruW7vLDj59nUHIY983YZeAbW15Sop5nFDuPb6d/z85q/H E4tQ== X-Gm-Message-State: AKwxyteiO3qlAEe4AJX+wbLmyYzauJ/ijMTNjmqOIU1sPKT66xk/m8bm jEWkACOJBcNDRKmGq2Pb+3wkKPTUahK3ZZZR0BX6ocua X-Google-Smtp-Source: AH8x225pshFLXGyAin9VBj8hOFetp6JF4kp46KxmCyMYcnajqqZUs5f10BD1oJww2tBCd8yk52Kz6AkggydOTMjCT48= X-Received: by 10.84.77.132 with SMTP id y4mr6112530oix.50.1516842353382; Wed, 24 Jan 2018 17:05:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Wed, 24 Jan 2018 17:05:52 -0800 (PST) From: Martin Thomson Date: Thu, 25 Jan 2018 12:05:52 +1100 Message-ID: Subject: EXTENSION frame 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: Thu, 25 Jan 2018 01:05:56 -0000 This came up several times, and I think that having a pressure relief valve is a nice thing. We found this extremely valuable in h2 and the obvious design is pretty simple. I expect that people will want to talk about the IANA policy that I've proposed. https://github.com/quicwg/base-drafts/pull/1068 From nobody Wed Jan 24 19:09:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C792012D87A for ; Wed, 24 Jan 2018 19:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 6JnmkhYi2GDW for ; Wed, 24 Jan 2018 19:09:17 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 7E38112D7EA for ; Wed, 24 Jan 2018 19:09:17 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l20so15841124qtj.11 for ; Wed, 24 Jan 2018 19:09:17 -0800 (PST) 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=52fHZ/9V4CnzkVmthR8bOqjHdzX0ZYCe9Yys1nHR/w8=; b=vObW1Msc32oO8TH+Mnzez2weUUFwzQssKINKcdnseR3rIH2mQ8L59LGS3b/k00CFwv G7ZAhK7xWVyKj/EpsGQ3iiiKO38EvEI1fNLOpGp4AUXk5Yha00/HAnnUMehdd/Deu/gn 1UDgoGunWHLv5cfTQPIbQ49uF0LzSZ1MCRVsR3Sh1tnkZaa00oocNWy1YJc4roN3V+Il OK9x9eSk8/qLYUicO2GnkWbX1IEw5s/V/NzNXwzsOp8O50RbDQR2MtMF/70NUhx+8iAF St7ZUTzi8EGvIFh3HBRNRzPsJ3Gdm8B6RqP4bJ5Bi0Iy22bKrh/Mt95gX5dS+n8MVzPd TfAA== 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=52fHZ/9V4CnzkVmthR8bOqjHdzX0ZYCe9Yys1nHR/w8=; b=Vl/sL/efaUv3aOPZMMp4v+ckURjPlofr9qRP1MCNDR9/wIJKXZjCc6nc311F0dmAPi /+fSqFzoyCi1nQ1dbUSv4FhUHbOb7nlke66J0qqPyqOlOyVnygNiAt/UiXy+G62n5FU+ EwKRbfoAbepbFh/m9vVIs8V4gTqwWzswgLOIrHBJfAPt2PTGwEH4xdPQhuheheDrT7nL c/Fwjj+MWuXR53WUg99WXL4tUle4z+Jr3pkI+goW9zMV0g5vE6AHLNwCZy/qhLhvRqt6 vYmuDsaUBruMfD+ZH7Q7iGCrDL0sRAIaBJvzy2dt06RC9gAnfCFiWXnEFmDc7xfhGvu/ wcXA== X-Gm-Message-State: AKwxytfxAFjePRlLFplfq2h16Nsb8oBY3MLuDmYV+fz1iI0zCnVmy3eo Q8a3TYHbGK7xhZOrUh8hLW/o8ceCBIW3WrDE122CMA== X-Google-Smtp-Source: AH8x226puXGXrUqzL0mqu/4rGJL9ZWLUOsixmKgfqeaipK9i4SfOEgIzC/8iLqFeXUQw4pX98Q5KDOHDq7l054V39GI= X-Received: by 10.237.52.101 with SMTP id w92mr14023420qtd.204.1516849756327; Wed, 24 Jan 2018 19:09:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.12.130 with HTTP; Wed, 24 Jan 2018 19:09:15 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Wed, 24 Jan 2018 22:09:15 -0500 Message-ID: Subject: Re: EXTENSION frame To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c124a5ce7eb5a0563911aff" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 03:09:20 -0000 --94eb2c124a5ce7eb5a0563911aff Content-Type: text/plain; charset="UTF-8" Is there a reason we can't go with TLS-style extension negotiation in the handshake? This would allow fatal errors on unknown extension frames, and would save the peers the effort of sending things that are not supported. On Wed, Jan 24, 2018 at 8:05 PM, Martin Thomson wrote: > This came up several times, and I think that having a pressure relief > valve is a nice thing. We found this extremely valuable in h2 and the > obvious design is pretty simple. > > I expect that people will want to talk about the IANA policy that I've > proposed. > > https://github.com/quicwg/base-drafts/pull/1068 > > --94eb2c124a5ce7eb5a0563911aff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Is there a reason we can't go with TLS-style extension= negotiation in the handshake?=C2=A0 This would allow fatal errors on unkno= wn extension frames, and would save the peers the effort of sending things = that are not supported.

    On Wed, Jan 24, 2018 at 8:05 PM, Martin Thomson <martin= .thomson@gmail.com> wrote:
    = This came up several times, and I think that having a pressure relief
    valve is a nice thing.=C2=A0 We found this extremely valuable in h2 and the=
    obvious design is pretty simple.

    I expect that people will want to talk about the IANA policy that I've = proposed.

    https://github.com/quicwg/base-drafts/pull/1068<= /a>


    --94eb2c124a5ce7eb5a0563911aff-- From nobody Wed Jan 24 20:02:43 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2662F12E042 for ; Wed, 24 Jan 2018 20:02:42 -0800 (PST) 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 JVHvFdq3w824 for ; Wed, 24 Jan 2018 20:02:40 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 11D6A12D95B for ; Wed, 24 Jan 2018 20:02:40 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id f100so5596954otf.3 for ; Wed, 24 Jan 2018 20:02:39 -0800 (PST) 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=a7ilJYM47STQ3RC8tqHy88i+zly7yDASgHqrw3JHqgU=; b=E1vYz1203ovmN+Y6oyqaUldiRUkhwil101ziAhFG0UF/2XNll1CoULLZsaRwf6tyts s9EWE7G6lW+qdrmfXsU44FE3hcgasYu80deOnunzYM+vP5opsWBXGpngcEmp+JUpb94o AKzh1bkA2BlEE9N/NWQO2xS2VGLgR4lU4R+kt3Lgh/dTvUiz9F8F0unQMPzSUnx39Bm9 rfvgjHsqOhUCnGr6/K8ORTDIxv1iJQ4u2vOUF7yhsPLw9XNZ8TPUyLmYEGhvT+DP8bPw rwH3Bow3d9SRrg2ZEHZ1NZeUDmeZrZGz6PfKAB7cb8otiS6jKFNzCsqlMlO6DmbygZOw PIEA== 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=a7ilJYM47STQ3RC8tqHy88i+zly7yDASgHqrw3JHqgU=; b=HV9ninHl1DXHslNKvInnlbTjy7FXVuM5bTrUPrucQqD/r1pQClXsDcWC0jrh4L7Ej3 nrHE3qf9CL9YbXy+nP3k8CJy3lDQku6NQA9pdZpnmmXmw3CawD5k+Gb7715WAS2rz/2X UvhsFWprTKEm5iKLmUGtOSGTvHdON9Q8tmzzYUpNskihroEVas4KnQnVhZwt+0bvACbN uF3WhLAnD+N/qIhICzhH8YYrjVB8//ILf89RSWpIvd9+CEIs0zybMWKPJIaH6lifml4p maNSgSR+c8K1zHcg5R69cJe7A8dG1wR8dkvfYmFeTWgh62sWZsGJtRdeXFGfYxehMtgj Q8Pg== X-Gm-Message-State: AKwxytdDEitm4zLgvlvY1axhCYhH/QoUK7PXlQVVSI9ow4RDO/t3ljKM q+kZcZwPOfKlWx6NHiZdV4gkH3DFHGIVUooGbeU= X-Google-Smtp-Source: AH8x226TFKSRotEik8c/eWV6AW5cVRiNDQc0VkCPRGemSthps5bbZ3nGAXgsvfyeYhNsPMHhk7xHwFyN5UkQ0Enzxqc= X-Received: by 10.157.0.102 with SMTP id 93mr10509761ota.175.1516852959282; Wed, 24 Jan 2018 20:02:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.46 with HTTP; Wed, 24 Jan 2018 20:02:38 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 25 Jan 2018 15:02:38 +1100 Message-ID: Subject: Re: EXTENSION frame To: Victor Vasiliev Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 04:02:42 -0000 Creating reasons to tear down connections doesn't seem like a goal. If you are concerned about the need to send things that the other side doesn't support, then by all means negotiate the use of an extension before sending it. This only makes it *possible* to send something without first negotiating support. On Thu, Jan 25, 2018 at 2:09 PM, Victor Vasiliev wrote: > Is there a reason we can't go with TLS-style extension negotiation in the > handshake? This would allow fatal errors on unknown extension frames, and > would save the peers the effort of sending things that are not supported. > > On Wed, Jan 24, 2018 at 8:05 PM, Martin Thomson > wrote: >> >> This came up several times, and I think that having a pressure relief >> valve is a nice thing. We found this extremely valuable in h2 and the >> obvious design is pretty simple. >> >> I expect that people will want to talk about the IANA policy that I've >> proposed. >> >> https://github.com/quicwg/base-drafts/pull/1068 >> > From nobody Wed Jan 24 20:09:25 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62212E042 for ; Wed, 24 Jan 2018 20:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t7Jy5gbIysB for ; Wed, 24 Jan 2018 20:09:21 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEC612D893 for ; Wed, 24 Jan 2018 20:09:20 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id w0P49ES3022287; Thu, 25 Jan 2018 05:09:14 +0100 Date: Thu, 25 Jan 2018 05:09:14 +0100 From: Willy Tarreau To: Martin Thomson Cc: Victor Vasiliev , QUIC WG Subject: Re: EXTENSION frame Message-ID: <20180125040914.GB22267@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 04:09:23 -0000 On Thu, Jan 25, 2018 at 03:02:38PM +1100, Martin Thomson wrote: > Creating reasons to tear down connections doesn't seem like a goal. > > If you are concerned about the need to send things that the other side > doesn't support, then by all means negotiate the use of an extension > before sending it. This only makes it *possible* to send something > without first negotiating support. Indeed, that's exactly what TCP does and the level of interoperability is extremely good, without requiring to break connections and try again. Willy From nobody Wed Jan 24 20:33:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A43EB12E055 for ; Wed, 24 Jan 2018 20:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=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 JtpDOdWNbaiT for ; Wed, 24 Jan 2018 20:33:12 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF14712D880 for ; Wed, 24 Jan 2018 20:33:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,409,1511856000"; d="asc'?scan'208";a="252235230" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx141-out.netapp.com with ESMTP; 24 Jan 2018 20:33:12 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 24 Jan 2018 20:33:12 -0800 Received: from NAM01-SN1-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.1320.4 via Frontend Transport; Wed, 24 Jan 2018 20:33:12 -0800 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=EXMuCdSWMc9TgK1p+Z4szS6E816Kq1P7vZhYwNFhI4s=; b=A4ZMZcsuSwcNK0sZu3LTUTrLy8CxYPWlPAeWrn1f2RzoESI8jtwDkXQjO2Pn5DuAmdxIV27l450Krctkw7U1EYUU8WxguJQ5PtNVL5/OMum9NCDEsG+ZWG1rlfDnjCp5tcfP4L3t/UGGwadHwpm+3FBUPHT9gDV2rl1aRM2O1f0= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB259.namprd06.prod.outlook.com (10.141.22.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Thu, 25 Jan 2018 04:33:10 +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.20.0444.014; Thu, 25 Jan 2018 04:33:09 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Doodle poll for Feb 2018 remote interop day Thread-Topic: Doodle poll for Feb 2018 remote interop day Thread-Index: AQHTlZWaFH+AP5tehUOdVs5PAA0XDg== Date: Thu, 25 Jan 2018 04:33:09 +0000 Message-ID: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [131.170.169.240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB259; 7:oTPUVFu24PbiSJilrBSoqM5EbiWNd1iWtKFq1yCLoNk5vjFznkoCSbU+jpBi0lyUS6KAgygLoxhMFOQvTwfdZj/jC70W++DHE+o5sK26IIkcrMu/UPMvwHIeCb20wVCUWncd0ZSYn7QH41fZe2thxwvmVAEDu/5wzJ0WuJm13Xg/eEiDY4GVzHzhmfQ2AD7ujMXnw49Fnq7APK5V2LmwY7cHrwVh0Lo+Y/mHddgLdfIlMtbCUXCYdqTDe6ddfdAZ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1978f6fc-92f7-43fa-c49e-08d563acbcd0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB259; x-ms-traffictypediagnostic: BLUPR06MB259: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231023)(2400081)(944501161)(6055026)(6041288)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BLUPR06MB259; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB259; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(366004)(346002)(39860400002)(396003)(189003)(199004)(102836004)(86362001)(558084003)(6506007)(478600001)(77096007)(6436002)(26005)(7736002)(316002)(305945005)(50226002)(83716003)(6486002)(82746002)(6512007)(6306002)(99936001)(3280700002)(53936002)(57306001)(186003)(66066001)(966005)(106356001)(33656002)(3660700001)(14454004)(5660300001)(105586002)(81156014)(8936002)(2906002)(97736004)(8676002)(99286004)(68736007)(6916009)(2900100001)(25786009)(36756003)(81166006)(6116002)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB259; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DcrgqtQcJRjwC8UNrQRrti1DsDJExbv9llxUy1IFi2olZm4+hNDx4VR18FhuN0EkRZfL3agfhL6eObA8hZOZUA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_B5C255A0-771F-4455-8783-88D343F42445"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1978f6fc-92f7-43fa-c49e-08d563acbcd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 04:33:09.5647 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB259 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: Thu, 25 Jan 2018 04:33:15 -0000 --Apple-Mail=_B5C255A0-771F-4455-8783-88D343F42445 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please indicate your availability, if you have a stack you wish to test: = https://doodle.com/poll/ee4gueyfve3azpqn (This will be a remote interop day. Next physical one will be Hackathon = in London.) Lars --Apple-Mail=_B5C255A0-771F-4455-8783-88D343F42445 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlppXgQACgkQVLXDCb9w wVf4XQ//bmQwofwj5oh9nHsMnPayD3bQr6pxUhQUDqOkDEF65Uwidlmp/k+orAFf mG5vLbFl9KstWLe32i53+3VNRp7zPcFx4Xq8yfvGMIiIadAVsKf89nJ8G+y+BO7u czFs5sQchqNmJEjEgzDVqEdeQ75vGGAuiBoFV46S3G/hoNjK1//T1dww1KUTvWsw ot3XTgoXpiUUtgqctzDIOoDFBL8934yU6PSFVKY836N7ZBJlaZ9E9EXwtUrxTyXb V9aOW01PjnOhhmOlsqg0Ar8jhrC376sg3Hj3O6ZbOyRQv+MY8r1hTiSPTN+mb+HE MgRbrnSDTalSHwm5MKEHqT8t3A3vlpwmX8ZY6uJrCcd3CgVHPZouqxyoeHLlUG30 cuFplafK4rEkfwj5BlbOzVORKG15t+vTVzdguVvHSN36XNMCrM/OJJSxDtnvD/Yp z1j478LYXmq5F6QU4JYDxX4gHCYeSHF2FjPWfgaWyq40vJcExxsijJmPDU/hx82t 4t4pNYVY2vhcOnW1LzbcfpZW09mNrpoeUSejtz4/lyVdVepP6v9UPYiCl7NxAP3a 1EQc1E6ZGVDJcjYj3BzE2wgItDgUvvoZiK3M7ZiXubb//nyzqYSVSP6x/tRPCvlA rhJCkjO4eVUGMQ6lL/A7wCnUQH0dvbg2N8my7k+CueK5MJOxQQM= =Pi7e -----END PGP SIGNATURE----- --Apple-Mail=_B5C255A0-771F-4455-8783-88D343F42445-- From nobody Wed Jan 24 22:03:33 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D88112D860 for ; Wed, 24 Jan 2018 22:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qBKU9kE94dB for ; Wed, 24 Jan 2018 22:03:29 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6767120713 for ; Wed, 24 Jan 2018 22:03:27 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BBA26340F46; Thu, 25 Jan 2018 07:03:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.30040); Thu, 25 Jan 2018 07:03:22 +0100 (CET) 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, 25 Jan 2018 07:03:22 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43231853; Thu, 25 Jan 2018 07:03:22 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0C3CFA65-3D79-46C4-AB46-C0ECB20600DE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC Date: Thu, 25 Jan 2018 07:03:22 +0100 In-Reply-To: <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: Christian Huitema , Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" To: "Lubashev, Igor" References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> 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, 25 Jan 2018 06:03:32 -0000 --Apple-Mail=_0C3CFA65-3D79-46C4-AB46-C0ECB20600DE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Jan 2018, at 23:53, Lubashev, Igor wrote: >=20 > I think I like a per-packet bitmap. If you are ACKing 30 packets, it = is only 8 bytes. The advantage of per-packet bitmap is that you do not = need to split ACK Blocks =E2=80=93 savings right there. I'll also note that in the current Internet case (no L4S or DCTCP, = sporadic deployment of CE-marking routers), there are opportunities for = large savings with the bitmap approach through trivially simple = compression (maybe even as simple as a special representation for "all = of these packets were 0/ECT0/ECT1"). Cheers, Brian > =E2=80=A2 Igor >=20 > From: Christian Huitema [mailto:huitema@huitema.net] > Sent: Wednesday, January 24, 2018 4:38 PM > To: Ingemar Johansson S ; Lubashev, = Igor ; QUIC WG > Cc: Bob Briscoe (research@bobbriscoe.net) ; = koen.de_schepper@nokia-bell-labs.com > Subject: Re: ECN in QUIC >=20 >=20 >=20 >=20 > On 1/24/2018 10:51 AM, Ingemar Johansson S wrote: > Hi >=20 > Comment on =E2=80=9CCE is not going to be a very common occurrence=E2=80= =9D. > While that may be true for (almost) drop equivalent ECN (a.k.a. = classic), it does unfortunately not hold at all for L4S. Typical values = of ECN marking ratio with L4S is in the order of 10 to 50%. In addition = the CE marks can be spread randomly (for instance with phantom queues). > This means that the ACK blocks in the suggested format below can = become very short, in the worst case representing only one packet per = ACK block if we have an alternating ECT-CE-ECT-CE=E2=80=A6 pattern in = the received packets. > Yes. >=20 >=20 > So my take is that if an ECN bit pattern is really necessary then it = is better to have it as an bitmap that represents all packets that are = listed in the ACK block. If one make an assumption that an ACK frame = contains two ACK blocks that ACKs 5 and 7 packets then the ECN block = will become (5+7)*2 =3D 24bits , i.e. 3 octets. > Yes, we have to take that into account in the design. >=20 >=20 > But with that said I am still not convinced that the packet counter = approach is flawed (I=E2=80=99m am happy to be enlightened =F0=9F=98=8A) = . > Taking multipath as an example : Isn=E2=80=99t it the case that two = connections are setup, each with its own congestion control context (I = omit coupled CC for the moment). If that is the case then I don=E2=80=99t = see any problem with the packet counters. >=20 > We are heading towards a single packet sequence number space shared by = multiple paths. That means that we need precise per packet feedback. If = a packet was marked with CE, you want to know on which path, and the way = to know that is to find the "path" tag in the saved copy of the packet. = You cant do that with counters. >=20 >=20 > As regards to connection migration. One possible matter is that it can = become tricky to detect ECN bleaching or ECN bit access problems in OS = immediately , however during the course of 1 RTT or even less, this = should be possible to detect as e.g. ECN bleaching will result in that = the neither on the ECT(0),ECT(1) and CE counters increase. But I am = fully aware that I may miss things here. >=20 > Again, there is no problem if we have precise per packet feedback, = because we can find out which packets were bleached. >=20 > -- Christian Huitema >=20 --Apple-Mail=_0C3CFA65-3D79-46C4-AB46-C0ECB20600DE 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlppcyoACgkQihK3vwvq RqOUEhAAhtOKGTxZxqu041aNK6e6KLTbJNtWFjcMYiIHJ7noSD4PDbWFUYAWc8eu uNikZeLNDOuBp0urKBp49CiR58niatRUg8GsplyE5yhGMpIFAKlUqZ74w6J7B0OX 8UmV0aa9FwSl8E6xW2x+LfKJScFkWwjoVPFmyCL4v9p9uTXOOQj1wI2IQA0IbzpF Ym2WMgF6dtKynxnPSL9hnyFyBjDKKE0hFm73UQ0QenztZk4UopgSQphcJKNoZUb9 WmBp+p5eN20pCMbf3lCnIS2kLEbYABArhIGgg8mWnmnRtCf+VLHHC8/tPEHldo7k 6gRHcl9hWGFHAKAyNTVozOxOj+m82PpyhdDz08O3S8QhaAUcZkx5zq3o0IuEJseL a6iF3ajB8DKtA5nEtiOtY1eBg7BgBXJvL/ENlV7fKyBEHTOUbYc1eXy+Wdn8iLtg piktbpA9ZDX7vDQm9b3gvKwxu3vn5n6JM9illTDSNUfSOE9xp8z9dJdEN1vEyC4n pgeRwV9STBavS4qlbDlwf8hP/LGC+Axh062Ss0NHGTMVdZ3J5aN1LNlRGvGTuM6H bvyXjj65vYVEfB1PhJREKEFUGIa/SfzZ2d4LO6wADlh9HzhEWSCMDVOdqFY06f4z iB+aJEkfFmTkjHhGdVP5V9nxS7nArgY9Sw11J+/8VNzXiDZM5lA= =oZfZ -----END PGP SIGNATURE----- --Apple-Mail=_0C3CFA65-3D79-46C4-AB46-C0ECB20600DE-- From nobody Wed Jan 24 22:31:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3EC126BF3 for ; Wed, 24 Jan 2018 22:31:11 -0800 (PST) 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=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 9Kbdg42H4JAB for ; Wed, 24 Jan 2018 22:31:09 -0800 (PST) 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 99779129C6A for ; Wed, 24 Jan 2018 22:31:09 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0P6R8Rd018166; Thu, 25 Jan 2018 06:29:56 GMT 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=BV47wUfCV9hZg5GSgyHJ6NJO0iJU3Mjfe0L5XQgtUeE=; b=hww46yqoqiOnSTJ7ffghXRzYq17SXNDshCS3V9gyMYcxLaLVB+Wiht712Xoh7HL+zfJS k/tV/XhH+ZHf012myyp6UwQXcZ/7t6kk0skV6AZl5EfXaxWriK+p3QWY6d0LvPfj3F7e dv8xXrl2rHskF5z84kZpMk+aHYBfoOABdXyr9P+vGTYLjd897WeGFqtspsAMOBCl5x3Z Nn+FRqtbmzq6oI54Am6LrWRjJUCIpW9/i7YhgAu/pnNti7PRm/kfkw2QiwXZJpsFst71 vnZ+4ZRvimBxgmA9+5V+axnPcPMfs8ulK7gF6yAegeEYV0JNX5I1ogLsAvqzpCFRqpdi CQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2fpbgx01fc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 06:29:56 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w0P6QW8N019078; Thu, 25 Jan 2018 01:29:55 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2fp9tvd00w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 01:29:55 -0500 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, 25 Jan 2018 01:29:54 -0500 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, 25 Jan 2018 01:29:54 -0500 From: "Lubashev, Igor" To: "Brian Trammell (IETF)" CC: Christian Huitema , Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" , "koen.de_schepper@nokia-bell-labs.com" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1AADTxqAAAJCiHAAAigEwAACgVbwA== Date: Thu, 25 Jan 2018 06:29:53 +0000 Message-ID: References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@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.239] 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=2018-01-25_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=705 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250089 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_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 mlxscore=0 impostorscore=0 mlxlogscore=701 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801250089 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 06:31:11 -0000 PiBPbiBUaHVyc2RheSwgSmFudWFyeSAyNSwgMjAxOCAxOjAzIEFNLCBCcmlhbiBUcmFtbWVsbCAo SUVURikgW21haWx0bzppZXRmQHRyYW1tZWxsLmNoXSB3cm90ZToNCj4NCj4gSSdsbCBhbHNvIG5v dGUgdGhhdCBpbiB0aGUgY3VycmVudCBJbnRlcm5ldCBjYXNlIChubyBMNFMgb3IgRENUQ1AsIHNw b3JhZGljIGRlcGxveW1lbnQgb2YgQ0UtbWFya2luZyByb3V0ZXJzKSwgdGhlcmUgYXJlIG9wcG9y dHVuaXRpZXMgZm9yIGxhcmdlIHNhdmluZ3Mgd2l0aCB0aGUgYml0bWFwIGFwcHJvYWNoIHRocm91 Z2ggdHJpdmlhbGx5IHNpbXBsZSBjb21wcmVzc2lvbiAobWF5YmUgZXZlbiBhcyBzaW1wbGUgYXMg YSBzcGVjaWFsIHJlcHJlc2VudGF0aW9uIGZvciAiYWxsIG9mIHRoZXNlIHBhY2tldHMgd2VyZSAw L0VDVDAvRUNUMSIpLg0KDQpDb21wbGV0ZWx5IGFncmVlLg0KDQpUaGF0J3MgZXhhY3Qgd2h5IEkg aGFkIEFDSyBhbmQgQUNLLUVDVCBmcmFtZXMgaW4gbXkgcHJvcG9zYWwgKHNlZSBlYXJsaWVyIGlu IHRoZSB0aHJlYWQpIC0tIHRvIG1ha2UgImFsbCBwYWNrZXRzIGhhdmUgbm8gRUNOIG1hcmtpbmdz IiBhbmQgImFsbCBwYWNrZXRzIGFyZSBFQ1QiIGNhc2VzIGNvc3QgMCBieXRlcy4gIFRoZSBjb21t b24gY2FzZSB0b2RheSB3b3VsZCBjb3N0IG5vdGhpbmcuICBXaGVuIHNvbWUgcGF0aCBnZXRzICJp bnRlcmVzdGluZyIsIGl0IHdvdWxkIHN0YXJ0IGNvc3RpbmcgfjIgYml0cyBwZXIgcGFja2V0Lg0K DQooU2VlIFBhcnRzIDEmMiBhbmQgaWdub3JlIFBhcnQgMywgd2hpY2ggaGFzIGEgcGVyLUFDS19C bG9jayBpbnN0ZWFkIG9mIGEgcGVyLXBhY2tldCBiaXRtYXA6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvcXVpYy9jdXJyZW50L21zZzAyOTczLmh0bWwpLg0KDQotIElnb3IN Cg== From nobody Thu Jan 25 00:45:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72D212D96B for ; Thu, 25 Jan 2018 00:45:11 -0800 (PST) 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 EacMWkzyVyZM for ; Thu, 25 Jan 2018 00:45:09 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 319D812D868 for ; Thu, 25 Jan 2018 00:45:09 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id f34so7830557ioi.13 for ; Thu, 25 Jan 2018 00:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=y89BGQvDIVdLoxWXEdVqX8wZDYDpfgcIOzyHxbBeKD0=; b=rOIGp9ztwDaV4ltiMLSfLEz4HhH9e1y5WjxTHlg5PiLWyIoSax9U849JlVBUQGAqGR V/eFAzgzhTPZ5Ldjtmp8NWINQoG0wrBZUfEJFsYsBhCNG1cybNnyuwMsaKFNa/z4JyZK 5S81q6kMphpSyr5nXiXneqfL9Dk2DYypOsswha2xvxHuSW+SVGXjB/BaiJJIebETPpG1 0wVEpg4vtltZ+XnhtOO7xZMPbbLBcwx+ud7JOWTbunIu10cM1vuOfaZckgsMBsu96a+a OP31oLgzhCl0PbH//UwY9aHx93xP6SkJdFT6yG3FeCDoZM+X3PFZu3sQR3DdnW4hxv2v Sasg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=y89BGQvDIVdLoxWXEdVqX8wZDYDpfgcIOzyHxbBeKD0=; b=P3qhJf3v+yW3+d9jT30onaQLX8NfbgF4aGgZ2JadQhwiMYkdl+gKZVoB9IRF0eWObW Sd+Xy4CoFphs67gSw39bZy6jEKYKKDl2v2ypTjTXmI5EppO/EZHEnjOBs+lrUNfcqEN4 60PqvkwnEbfrynOxbqiULfem75TZYiqCsa/0GSjXPAKlfQUVEBXrNaWCfuwvbIe6TcvQ NsXK3hscQ9ATQbveg6DJ4+C2+KerCUgfRnpUjlvpxJnjs/+4ZpDAWY6cwVVAB6w2uQ9C wW9H+vE/dslAjjuAbclhvYZC91UaywDHCH8L3xDQPLDbqW8xvd6RnPu4uq0w6adbEQIf Ogfw== X-Gm-Message-State: AKwxytc1brCTutEXVnm0NURdhu2ck0rD+Ssxs8Zi6K3k6dI4YZ3TqUGD wrVLGMVUkR9MbTbz1Y2gIvPY8pd7miATmumNT/n56w== X-Google-Smtp-Source: AH8x227Kw7JCtIe1fQL4kP0GlEAU0ZoHXaGxxVDX3z88h7EA0DyEa0mEPRzbwz80XicQ0x8F98k0TxUsiwFHKxtXWP8= X-Received: by 10.107.20.200 with SMTP id 191mr11918607iou.239.1516869908462; Thu, 25 Jan 2018 00:45:08 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 00:45:07 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 25 Jan 2018 00:45:07 -0800 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114fd4c81081ba056395ccf4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 08:45:12 -0000 --001a114fd4c81081ba056395ccf4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote: I don=E2=80=99t understand this requirement for the CID to be 16 bytes in o= rder to be encrypted. If you have a unique key you can encrypt 0, truncate and xor with the CID. If you don=E2=80=99t have a unique key, you can encrypt a unique counter va= lue and do the same, or derive a unique key. I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.? I=E2=80=99m merely stating that if you want to encrypt with AES and you do = not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic. There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES. As to a possible scheme: Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make= it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P= =3D not P if key changed since last derivation. The encrypted CID ECID =3D . We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation. The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route. We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag. In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in. http://www.mindspring.com/~dmcgrew/gcm-nist-6.pdf AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part. --001a114fd4c81081ba056395ccf4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 25 January 2018 a= t 00.16.55, Eric Rescorla (ekr@rtfm.com= ) wrote:
    I don=E2=80=99t understand this requirement for = the CID to be 16 bytes in order to be encrypted.
    If you have a unique key you can encryp= t 0, truncate and xor with the CID.
    If you don=E2=80=99t have a unique key, you can encr= ypt a unique counter value and do the same, or derive a unique key.

    I don't believe what you are de= scribing works correctly, but I'm not sure I understand your proposal. = Can you please flesh out precisely what you have in mind? In particular, wh= o is "you", who has the key, etc.?

    I=E2=80=99m merely stating that if you want to encrypt with AES a= nd you do not care about authentication, then AES works fine with shorter i= nputs than 16 bytes. You may still have to provide an initialisation vector= so the +n still holds. The last block of AES-GCM is not a full block and w= orks as i described - see sect. 2.3 and figure 1 in link to GCM paper. If t= he last block is the only block, you encrypt less than 16 bytes without any= magic.

    There are many reasons you might want to use 16 bytes, or you= might want to add authentication, but it is not AES itself that imposes th= ose constraints as already argued. My point is that if you need 16 bytes, p= lease state why, instead of blaming it on AES.

    As to a possible schem= e:

    Assume a server cluster wants to encode routing data by selecting = one out of 256 possible routes and a 8 bit unique id for each route. This c= an be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99= s make it simple for a start: just have 1 routing bit R to choose between t= wo servers and 1 IV bit to identify the connection, and one phase bit P. Th= e objective is to make it unpredictable which server is hit. The encryption= of the two bits happen by encrypting the IV bit with a cluster key that al= l routers are aware of. The phase bit is not needed but avoids guessing whi= ch router key is active since it rotates every hour derived from a master k= ey. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99i= ng with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(maste= r, R), P =3D not P if key changed since last derivation. The encrypted CID = ECID =3D <AES(key, IV) XOR R, IV, P>.

    We can readily extend the= above to as many R bits as needed. The IV must be unique but if we only ca= re about making it hard to force a route rather than protecting information= , it is less critical, assuming we hide the master key behind strong deriva= tion.

    The problem is that an attacker can easily flip the first bit i= n the ECID. We can make this harder by having more than R bits than valid r= outes and having more IV bits chosen at random. The R bits now either map t= o a valid route or not. It becomes harder to guess a valid route.

    We = can make this harder by adding an auth tag - say of length 16 bits. AES-GCM= is not suited for short tags, but there CMACs that can do this I believe (= two times AES + padding and truncation to desired length, from memory). How= ever, if it is sufficiently hard to guess a route, and it is easy to decide= if a route is valid or not, it may not be necessary with an auth tag.

    <= p>In addition we want to identify the connection uniquely with respect to t= he chosen server route so we add U bits to make the connection id unique. T= hese do not have to be encrypted, but they might as well be thrown in.

    <= p>http://www.= mindspring.com/~dmcgrew/gcm-nist-6.pdf

    AES-GCM goes horribly wron= g if the same encrypted counter value is used twice - but we may not have a= problem with horribly wrong in our use case, which also only uses the CTR = mode part.

    --001a114fd4c81081ba056395ccf4-- From nobody Thu Jan 25 01:07:41 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76FEF12E870 for ; Thu, 25 Jan 2018 01:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0hy_zEXPPLT for ; Thu, 25 Jan 2018 01:07:37 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CA6512D868 for ; Thu, 25 Jan 2018 01:07:37 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id c17so7919387iod.1 for ; Thu, 25 Jan 2018 01:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=QsUu5SSeGnlzBcA1QTMYDR+qo7AWxAnI6szsCbwBuaI=; b=NKGaJaqtSnX3m+vybKbcYXK50t8y28aH4jj42kP2ADFdTVI/gKTJn5c/U9d9VMrR8E K7r7n81Q+lbPyLLAEfp5FjivDN6Irg0RLZtbXB71zJT8TRKJP/0Q0EnxF6zmukns0ezb S3VbYCFJjvg1y8v9dj54mxbfxKOYVt7RKTMERVwF86HRtDp1mQQVKNDVJ3FcCu229oPy SjyNvahBoFyaetBC1FomYjBOOKPZCGjbAXBAVtGWulEinlwxhGY2QSUAn8paXp8AiAIz UYPRgcCWg5rKXsaX50qmo8h9BeuUYMqOLYYRhhKCOvxmTAjWer4xKnJlJqHEhtHeGgCh /iyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=QsUu5SSeGnlzBcA1QTMYDR+qo7AWxAnI6szsCbwBuaI=; b=gJSDmpEcUHdI9Vm+oc96FCCzB/S/Ko4DKY3X1dmEJ5TC0/aOgrlJ68UOBwR5Eu4112 BNdI0urWOB9jBPaW4zo44JvljfJnseUggQ+3ZsBgvtpQ8VqtbYmFGo4uY447XWcHKTiR Ebi+NSPvknt427nB3FbCKJO6Z231t8dh4U+OtaLu3L3qdan9tGVCCGdZGlwu5RKtZnyh 9GLWWdWhIi0LS3Yq2Zp/KW23RhOdMxRPr7GrGsw6tHv/siyTItWBX7jVYvRhcofBFzpk z3LWQGCA4uJLq/W9RX1HN5FCYtJJBQH1m9VRwQTtacnmCyZWFpoM9QHfSDaDy3wr16TW pXfg== X-Gm-Message-State: AKwxytc+Hs/sa/leMdNj53ukxHuhB8jBThEwN4WHtq0hNIGESQCIZ+3G g/0tlzfSNNYrc6fypkSRrva/vJVKJrV8DfPZags= X-Google-Smtp-Source: AH8x225E8owWRoxU/NIpX6khzWfApYsc1HShkVChwNnYW7hqZ0ORFDGhEbKIM9gnK16qkM7QvwTzfyWwI5PCD0WucrQ= X-Received: by 10.107.3.209 with SMTP id e78mr11102858ioi.96.1516871256558; Thu, 25 Jan 2018 01:07:36 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 01:07:35 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 25 Jan 2018 01:07:35 -0800 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113dea646ad1940563961c97" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 09:07:39 -0000 --001a113dea646ad1940563961c97 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another thing is that such a scheme is somewhat broken because an off-path attacker can connect to a host as any other client and retrieve a connection ID. Then it has sufficient information about the routing table for the next our to flood a specific route. It=E2=80=99s not really possible to avoid unless each router has more infor= mation than a key rotating every hour. The targeted server can protect itself by not accepting any encrypted ECID in a new handshake and drop packets via ordinary auth failure on other packets. To handle stateless retry, the encryption ECID for retry must be different, so we name it RECID. The targeted server will generate ECID for client initiated communication with a random client CID, or accept RECID based handshakes, but will not accept ECID for handshake because that is a DoS waiting to happen. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote: I don=E2=80=99t understand this requirement for the CID to be 16 bytes in o= rder to be encrypted. If you have a unique key you can encrypt 0, truncate and xor with the CID. If you don=E2=80=99t have a unique key, you can encrypt a unique counter va= lue and do the same, or derive a unique key. I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.? I=E2=80=99m merely stating that if you want to encrypt with AES and you do = not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic. There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES. As to a possible scheme: Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make= it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P= =3D not P if key changed since last derivation. The encrypted CID ECID =3D . We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation. The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route. We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag. In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in. http://www.mindspring.com/~dmcgrew/gcm-nist-6.pdf AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part. --001a113dea646ad1940563961c97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Another thing is tha= t such a scheme is somewhat broken because an off-path attacker can connect= to a host as any other client and retrieve a connection ID. Then it has su= fficient information about the routing table for the next our to flood a sp= ecific route.

    It=E2= =80=99s not really possible to avoid unless each router has more informatio= n than a key rotating every hour.

    The targeted server can protect itself by not accepting any = encrypted ECID in a new handshake and drop packets via ordinary auth failur= e on other packets.

    T= o handle stateless retry, the encryption ECID for retry must be different, = so we name it RECID. The targeted server will generate ECID for client init= iated communication with a random client CID, or accept RECID based handsha= kes, but will not accept ECID for handshake because that is a DoS waiting t= o happen.

    Kind Re= gards,
    Mikke= l Fahn=C3=B8e J=C3=B8rgensen


    On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote:
    I don=E2=80=99t understand this requirement for the CID to be 16 bytes in order to be encrypted.
    If you have a unique key you can encrypt 0, truncate and xor with the CID.
    If you don=E2=80=99t have a unique key, you can encrypt a unique counter value and do the same, or derive a unique key.

    I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.?

    I=E2=80=99m merely stating that if you want to encrypt with AES and you do not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic.

    There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES.

    As to a possible scheme:

    Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P =3D not P if key changed since last derivation. The encrypted CID ECID =3D <AES(key, IV) XOR R, IV, P>.

    We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation.

    The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route.

    We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag.

    In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in.

    http://www= .mindspring.com/~dmcgrew/gcm-nist-6.pdf

    AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part.

     --001a113dea646ad1940563961c97-- From nobody Thu Jan 25 01:11:28 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1036812E87F for ; Thu, 25 Jan 2018 01:11:26 -0800 (PST) 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 zVLi9Gy2kyje for ; Thu, 25 Jan 2018 01:11:23 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AA7212DA01 for ; Thu, 25 Jan 2018 01:11:23 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 72so7898217iom.10 for ; Thu, 25 Jan 2018 01:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=n9O2INv7FZ67pNPRPOtPYV/DqraKU7yZQqucFPELBxg=; b=qiyneiuCbaJ25Mf+e3EIDEmK0uKfKKRGu0XBHonoSIYIEFoF6AnUXMHRtdO1TPyGDz pInkB7B5js7cJcA94kFagK1i+0xuHh9QRqfDJg9XgwuzSC/p5OL5UoLLK+9MOxXhZDya Xs8BDES8AgSwK23baJrNBlBXlxiwfvZKqxRSJvUiKe2topbbNto61aJ4OgMAsYYW2otn L3wbOluP3a/1fM5GztVFehP/eYhLRAwqaveMn2fT0FN1gOMZVQyrI+YjOwWNcvXZ326D 6B20mhXHFJmKcfHzEXXiocP29fvfcO4Z6sXvHi/5KwG4NOTpiDddVnCtBQtfE5UeD0ML qvtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=n9O2INv7FZ67pNPRPOtPYV/DqraKU7yZQqucFPELBxg=; b=mgbu9AqX3G07Qc7rhhpEr3y8CW4JnkpQL9WTdvX0a+UiWDtyxkqdBvw4F4n0qDfuZP sHgpa9yA0gJS2R1D9wBRVJ1/K/1MgySvSVh+btru/mSyexwpNMii0+rcNk2i9pLoiRAS 9nUXN32zVqP4aOO+29+AII/i1/mQQTEEhaV6RC/IS/NDaYfYLw3yix2y+UdKOHEk+vMM sdu6wWoUvTmuTEiGsNZqzLuqdgp9Pn9erWWhgVZkfrp1htTzUnG7N8iOvLAq7O9dpsD4 j9TpzImX5LV8WPtBk88nGifBRn7QiEVe300DN4KeDLwIUfaZJ16OehHKhCW4MprrRy7i fuxA== X-Gm-Message-State: AKwxytd+J1zWqoMBLnGSmZY8drfSjBIwUGWfnwL4yq3Ie+PPL0cxEhMJ YqnInLBEU/5Y0kHVOIGKTAu8tRd1b0aEHosDEQ/c2g== X-Google-Smtp-Source: AH8x227Bv1oA0xChgUQio00IKYYawm4JMNxgbxkq4yB6EAIDSoGtaVQDOkrRipJ9ODGf6My0Jjbr6z8nsK/1roHC2aI= X-Received: by 10.107.3.209 with SMTP id e78mr11112120ioi.96.1516871482641; Thu, 25 Jan 2018 01:11:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 01:11:22 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 25 Jan 2018 01:11:22 -0800 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113dea64e4930605639629b4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 09:11:26 -0000 --001a113dea64e4930605639629b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m not even sure that will work because the RECID could also be re= played. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 10.07.35, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Another thing is that such a scheme is somewhat broken because an off-path attacker can connect to a host as any other client and retrieve a connection ID. Then it has sufficient information about the routing table for the next our to flood a specific route. It=E2=80=99s not really possible to avoid unless each router has more infor= mation than a key rotating every hour. The targeted server can protect itself by not accepting any encrypted ECID in a new handshake and drop packets via ordinary auth failure on other packets. To handle stateless retry, the encryption ECID for retry must be different, so we name it RECID. The targeted server will generate ECID for client initiated communication with a random client CID, or accept RECID based handshakes, but will not accept ECID for handshake because that is a DoS waiting to happen. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote: I don=E2=80=99t understand this requirement for the CID to be 16 bytes in o= rder to be encrypted. If you have a unique key you can encrypt 0, truncate and xor with the CID. If you don=E2=80=99t have a unique key, you can encrypt a unique counter va= lue and do the same, or derive a unique key. I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.? I=E2=80=99m merely stating that if you want to encrypt with AES and you do = not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic. There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES. As to a possible scheme: Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make= it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P= =3D not P if key changed since last derivation. The encrypted CID ECID =3D . We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation. The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route. We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag. In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in. http://www.mindspring.com/~dmcgrew/gcm-nist-6.pdf AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part. --001a113dea64e4930605639629b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m not even= sure that will work because the RECID could also be replayed.
    <= div id=3D"bloop_sign_1516871410209250048" class=3D"bloop_sign">
    Kind Regards,
    Mikkel Fahn=C3=B8e J=C3= =B8rgensen


    On 25 January 20= 18 at 10.07.35, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    Another thing is that such a scheme is somewhat broken because an off-path attacker can connect to a host as any other client and retrieve a connection ID. Then it has sufficient information about the routing table for the next our to flood a specific route.

    It=E2=80=99s not really possible to avoid unless each router has more information than a key rotating every hour.

    The targeted server can protect itself by not accepting any encrypted ECID in a new handshake and drop packets via ordinary auth failure on other packets.

    To handle stateless retry, the encryption ECID for retry must be different, so we name it RECID. The targeted server will generate ECID for client initiated communication with a random client CID, or accept RECID based handshakes, but will not accept ECID for handshake because that is a DoS waiting to happen.

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


    On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    I don=E2=80=99t understand this requirement for the CID to be 16 bytes in order to be encrypted.
    If you have a unique key you can encrypt 0, truncate and xor with the CID.
    If you don=E2=80=99t have a unique key, you can encrypt a unique counter value and do the same, or derive a unique key.

    I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.?

    I=E2=80=99m merely stating that if you want to encrypt with AES and you do not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic.

    There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES.

    As to a possible scheme:

    Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P =3D not P if key changed since last derivation. The encrypted CID ECID =3D <AES(key, IV) XOR R, IV, P>.

    We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation.

    The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route.

    We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag.

    In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in.

    http://www= .mindspring.com/~dmcgrew/gcm-nist-6.pdf

    AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part.

    --001a113dea64e4930605639629b4-- From nobody Thu Jan 25 01:11:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9CA12E870 for ; Thu, 25 Jan 2018 01:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 r1jAl-MFP71q for ; Thu, 25 Jan 2018 01:11:56 -0800 (PST) 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 D76F012D868 for ; Thu, 25 Jan 2018 01:11:55 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx12.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eedZQ-0007ks-6u for quic@ietf.org; Thu, 25 Jan 2018 10:11:48 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eedZJ-0006zT-RK for quic@ietf.org; Thu, 25 Jan 2018 04:11:41 -0500 Received: (qmail 10835 invoked from network); 25 Jan 2018 09:11:32 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2018 09:11:31 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-A2E6BD0C-FE2F-4E37-A930-BEA7099B0A75 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Wed, 24 Jan 2018 23:11:28 -1000 Cc: Eric Rescorla , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: <3B18A5DF-E9D6-4866-9B1F-25068647203F@huitema.net> References: To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Subject: Re: Read-out on offline connection ID discussion X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5l0ULHbsj3cpPgbIvyKFHkMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuarhUvg7Jby3KCeBAtlpgFB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RbsXxkdg7AzXKJWQK1/EQZPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATvFVVOfJAYdBTniKgyyo60ONoJfh+XjGSeeT90H/uIEv dgPkYMgX1clsm44k8mBD4xk5vj6n8gof57frkeDipGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWi2LEHF33nMCnEPdDBPtPg/fFcHV2tQAVqGdj/zM7G/G3L31QGIB1LDs8uX49JL/W5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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, 25 Jan 2018 09:11:58 -0000 --Apple-Mail-A2E6BD0C-FE2F-4E37-A930-BEA7099B0A75 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jan 24, 2018, at 10:45 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >=20 >> On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote: >> I don=E2=80=99t understand this requirement for the CID to be 16 bytes in= order to be encrypted. >> If you have a unique key you can encrypt 0, truncate and xor with the CID= . >> If you don=E2=80=99t have a unique key, you can encrypt a unique counter v= alue and do the same, or derive a unique key. >>=20 >> I don't believe what you are describing works correctly, but I'm not sure= I understand your proposal. Can you please flesh out precisely what you hav= e in mind? In particular, who is "you", who has the key, etc.? >=20 > I=E2=80=99m merely stating that if you want to encrypt with AES and you do= not care about authentication, then AES works fine with shorter inputs than= 16 bytes. You may still have to provide an initialisation vector so the +n s= till holds. The last block of AES-GCM is not a full block and works as i des= cribed - see sect. 2.3 and figure 1 in link to GCM paper. If the last block i= s the only block, you encrypt less than 16 bytes without any magic. >=20 AES GCM is a stream cipher. It is OK in AEAD mode, but using that without au= thentication opens the way to all the known attacks against stream ciphers. I= f we don't have room for authentication, then ECB mode seems much preferable= . --Christian Huitema=20 --Apple-Mail-A2E6BD0C-FE2F-4E37-A930-BEA7099B0A75 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    On Jan 24, 2018, at 10:45 PM, Mikk= el Fahn=C3=B8e J=C3=B8rgensen <mikk= elfj@gmail.com> wrote:

    body{font-family:Helvetica,Arial;font-size:13px}
    On 25 January 2018 at 00.16.55, Eri= c Rescorla (ekr@rtfm.com) wrote:
    <= div>
    I d= on=E2=80=99t understand this requirement for the CID to be 16 bytes in order= to be encrypted.
    If you have a unique key you can encrypt 0, truncate and xor with the CID= .
    If you don=E2= =80=99t have a unique key, you can encrypt a unique counter value and do the= same, or derive a unique key.

    I don= 't believe what you are describing works correctly, but I'm not sure I under= stand your proposal. Can you please flesh out precisely what you have in min= d? In particular, who is "you", who has the key, etc.?

    I=E2=80=99m merely stating that if you want to encrypt wi= th AES and you do not care about authentication, then AES works fine with sh= orter inputs than 16 bytes. You may still have to provide an initialisation v= ector so the +n still holds. The last block of AES-GCM is not a full block a= nd works as i described - see sect. 2.3 and figure 1 in link to GCM paper. I= f the last block is the only block, you encrypt less than 16 bytes without a= ny magic.

    AES GCM is a stream cipher. It is OK in= AEAD mode, but using that without authentication opens the way to all the k= nown attacks against stream ciphers. If we don't have room for authenticatio= n, then ECB mode seems much preferable.

    --Christian= Huitema 
    = --Apple-Mail-A2E6BD0C-FE2F-4E37-A930-BEA7099B0A75-- From nobody Thu Jan 25 01:49:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BF7912E87F for ; Thu, 25 Jan 2018 01:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKq6z2zCqng9 for ; Thu, 25 Jan 2018 01:49:08 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B66112D847 for ; Thu, 25 Jan 2018 01:49:07 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4FE4D340D6A; Thu, 25 Jan 2018 10:49:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.31793); Thu, 25 Jan 2018 10:49:03 +0100 (CET) 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, 25 Jan 2018 10:49:02 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43263051; Thu, 25 Jan 2018 10:49:02 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_04B55BF3-90C9-4A74-A993-143DC6C04329"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Read-out on offline connection ID discussion Date: Thu, 25 Jan 2018 10:49:02 +0100 In-Reply-To: Cc: IETF QUIC WG To: Eric Rescorla 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: Thu, 25 Jan 2018 09:49:11 -0000 --Apple-Mail=_04B55BF3-90C9-4A74-A993-143DC6C04329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 Jan 2018, at 23:36, Eric Rescorla wrote: >=20 > Hi folks, >=20 > We didn't really reach a conclusion, but here's, I think what there > was at least some support for: >=20 > - The long header has a variable length connection ID which has an > explicit length field on the wire, with a max length (strawman: 32 > bytes). The exact wire encoding to be designed by the editor. > Similarly, NEW_CONNECTION_ID would have a variable length > encoding. This seems like a perfectly reasonable starting point. > - The short header has a variable length connection ID which has > an implicit length (i.e., it cannot be decoded unambiguously > by an observer who is not part of the connection). However, > the CID may be self-describing, so that the server may include > a length field if it so chooses. A question about the details here: We put the CID (if present) up front in the short header so that it's = easy for load balancers to find; the packet number in -08 (which is = necessary to sequence and decrypt packets) is similarly easy for the = endpoint to find -- CID is fixed length and either present or not. If the CID is varlen and its length is implicit in the CID itself, then = the receiver needs to decode the CID in order to find the offset to the = packet number so that it can decrypt the packet number in order to = sequence the packet and decrypt the rest of it. This implies the = receiver always needs to know how to decode enough of the CID to skip it = (which can be trivially done in a transport parameter, but still). I presume the encrypted representation of the packet number on the wire = will be fixed-length, so we can fix this by moving the CID back behind = the packet number, but I'm not sure where we are in the tradeoff space = between forcing load balancers to skip N bytes before making a routing = decision and forcing packet receivers on both sides to always do more = work to parse the packet. Cheers, Brian > There was rough consensus on the second point, but some disagreement > about the first point. The major alternative proposal was to have > a fixed-length CID field in the long header and NEW_CONNECTION_ID > and then truncate it to an amount carried in transport_parameters. > This would have the benefit that the length of the CID would be > throughout the connection whereas if we wanted that rule for the > other design we would need a rule. >=20 > One thing that makes this second approach unattractive is that we want > the server to be able to use a 16 byte connection ID (thus allowing it > to be AES-encrypted) but it also needs to be able to include > meta-data, such as a key-id for rotation or potentially a length. This > tells us that you need to have a maximum connection ID larger than 16 > bytes, and having a fixed 17-20 byte CID seems odd. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_04B55BF3-90C9-4A74-A993-143DC6C04329 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlppqA4ACgkQihK3vwvq RqPUABAAmuB9KL3MJFZPfW1UlBezusPL3QZliy0ClOc2689mSjG/HEPPr8xsxkl+ 8giF/MHrv0Wd4OkODfRINXkWiWiV2xU4MSYKGlXzKq/acVkZ9dSX5BJh35yo4ThJ tUT1SFi9EntrkTFy279rQob2W/fnVxWtMqqvFIP44nMVfiqnYydb1mbLlMuY1xcA VWTRBi++RRDowgrwe1RktNWYlC3yQRH5qJRJ7L08gQllGZeii2mgPXocT9Dm9P0W lmOzOmSsWyY+zvTnhB9BfiuWKK5ASPWrGw5ejxZJpal0xBXv4LHUcQZ0lxGdHj5z 55/nuAG6wuhoG0QF3bxa3fEz5X9sSSIE1gYccc8pn10Z4yd35C/ZD7NQ72ivUmXN +R/ietLW6cBkpaAgLcu0+iIRoOeYMz11f92bsUODuzJ4AfvQXGPjQRSkUZGKc7OR 0gcAvhtH70OkWMl4JbCpWmKnzt7fckwCmtnEMdQ8UoTFM4qSpkiv3zN3EV9voZ+0 ZnC461QkLMGPDKlXxFeVOW3TCV9nvGNN6sFOKBPjpCHGcc6lNSZe8SfpHmOQ1kk6 l+pDzNvNJ+dZ2+l0GsU7pot9UcSqAHLNujkp9+LT6oqZp25WtwYwxrjwIjkaDYCg qFV3bIWaY15fuBoIST4nN9zjYLRWnuHllpqOJDQy7bvUXHxvopA= =hFNQ -----END PGP SIGNATURE----- --Apple-Mail=_04B55BF3-90C9-4A74-A993-143DC6C04329-- From nobody Thu Jan 25 02:10:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9581D12E886 for ; Thu, 25 Jan 2018 02:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, 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=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 ChUszyzLZo4Y for ; Thu, 25 Jan 2018 02:10:34 -0800 (PST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00111.outbound.protection.outlook.com [40.107.0.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99EB12E885 for ; Thu, 25 Jan 2018 02:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pe1kwwpht1VaIPAcupkIqZiDTOnvoCtmyxDZlQrZmDc=; b=OrxKIbg9hMBLUJVkCWGOaVfqaZZfgwF7V2L8WkWjRkYKUPZ9pPp6LYtVSgeRAy2MvktTuDHSP//zsMA+p4a3gpyV4ZS33bDjHyIQsApc2kMj+Nq5w+XS4BehU70kdrvjGEysY3eTghk2ou7pcddluKMutdrjGMgf/n5Ae+dUkD4= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2973.eurprd07.prod.outlook.com (10.173.72.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Thu, 25 Jan 2018 10:10:30 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::a16e:3b1a:be89:10fa]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::a16e:3b1a:be89:10fa%15]) with mapi id 15.20.0464.006; Thu, 25 Jan 2018 10:10:30 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: "Lubashev, Igor" , "Brian Trammell (IETF)" CC: Christian Huitema , Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1AAAsI1AAACpr+AAA8DdQAAAO0UgAAGEbDQ Date: Thu, 25 Jan 2018 10:10:30 +0000 Message-ID: References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com; x-originating-ip: [135.245.212.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2973; 7:TC5CqGXBKAhVMKGyYtEPrNRlltKpUlGi2guyuA5/Bd42QAFtVL5M/pxcKehSuNdxJSSjY+Q+AxWXY0Ds9kXJVUd0ladS3RB52kdmi1FOQ3Vqe5shLbaBgnfPTvUlfdVlwxHFbKh+auu4D2WnMJpnmvE08Cl6Ytx6mVnbBqaHgmDKyl6toBnI4hdAWyFcfE2Sga6lKtoocNL/WTcJlCddhczI7rbVbfyMgY7RR7+8BHcmhf6NT5qeM7ja5RyLMCNp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f60ebd42-4686-4662-f01f-08d563dbdd85 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR0701MB2973; x-ms-traffictypediagnostic: VI1PR0701MB2973: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231023)(11241501184)(2400081)(944501161)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR0701MB2973; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2973; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(39380400002)(396003)(39860400002)(13464003)(199004)(53754006)(189003)(9686003)(8936002)(316002)(2906002)(305945005)(2950100002)(3280700002)(7736002)(229853002)(105586002)(81156014)(54906003)(966005)(74316002)(6246003)(3660700001)(97736004)(81166006)(110136005)(7696005)(8676002)(3480700004)(2900100001)(6436002)(6306002)(6116002)(3846002)(55016002)(99286004)(76176011)(53936002)(5250100002)(186003)(478600001)(33656002)(561944003)(68736007)(26005)(59450400001)(53546011)(25786009)(6506007)(7116003)(4326008)(102836004)(106356001)(5660300001)(86362001)(93886005)(66066001)(14454004)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2973; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ny5Sq0fgiPBC4ptA/43h0s7BvedD7gpphZfGduUKbq9tJ1LLKh8zYaMolyxWVaxNJmiZOkOD7lvgFTIX5J4NgQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: f60ebd42-4686-4662-f01f-08d563dbdd85 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 10:10:30.7385 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2973 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 10:10:36 -0000 SGkgYWxsLA0KDQpTb21lIHF1ZXN0aW9ucyByZWxhdGVkIHRvIHRoZSByZW1hcmsgb2YgQ2hyaXN0 aWFuOiAiV2UgYXJlIGhlYWRpbmcgdG93YXJkcyBhIHNpbmdsZSBwYWNrZXQgc2VxdWVuY2UgbnVt YmVyIHNwYWNlIHNoYXJlZCBieSBtdWx0aXBsZSBwYXRocyINCldoYXQgaXMgdGhlIHJhdGlvbmFs ZSBiZWhpbmQgdGhpcz8NCklzIHRoZSByZWFzb24gZm9yIHRoaXMgdGhhdCB0aGVyZSBhcmUgY3Vy cmVudGx5IG5vIHBlciBwYXRoIHN0YXRlcy9jb21tdW5pY2F0aW9ucyByZXF1aXJlZD8gKGJlY2F1 c2UgY29uZ2VzdGlvbiBjb250cm9sIGlzIGN1cnJlbnRseSBvdXQgb2Ygc2NvcGUsIGFuZCBpdCBp cyBjdXJyZW50bHkgdGhlIG9ubHkgcGVyIHBhdGggcHJvY2Vzc2luZyByZXF1aXJlZCkuIEluIHRo YXQgY2FzZSBJIHVuZGVyc3RhbmQgd2h5IHRoZSBjdXJyZW50IGRlc2lnbiBvZiBRVUlDIGlzIG9w dGltaXppbmcgaXRzZWxmIHRvd2FyZHMgYXBwbGljYXRpb24gdG8gYXBwbGljYXRpb24gc3RhdGUs IGJ1dCB3ZSBtdXN0IG1ha2Ugc3VyZSB3ZSBkb24ndCBtYWtlIG91ciBsaXZlIGRpZmZpY3VsdCBp ZiB3ZSBoYXZlIHBlciBjb25uZWN0aW9uIHN0YXRlICh3aGVuIGl0IGlzIG5lZWRlZCwgbGlrZSBj b25nZXN0aW9uIGNvbnRyb2wpLg0KDQpMb29raW5nIGF0IHBlciBwYXRoIHByb2Nlc3NpbmcgZm9y IGNvbmdlc3Rpb24gY29udHJvbCwgaXQgc2VlbXMgdG8gYmUgYSBiaWcgaW1wYWN0IGFuZCBidXJk ZW4gKHByb2Nlc3Npbmcgb3ZlcmxvYWQpIHRvIGhhbmRsZSBiaXRtYXBzIChjb21wb3NlIGF0IHJl Y2VpdmVyIGFuZCBwYXJzZSBhdCBzZW5kZXIpLCBrZWVwIHRyYWNrIG9mIHdoaWNoIHBhY2tldHMg d2VyZSBzZW5kIG9uIHdoaWNoIHBhdGggKGluIHNlbmRlcikgYW5kIG1hcHBpbmcgdGhlIGJpdHMg YmFjayB0byB0aGUgcGVyIHBhdGggY291bnRlcnMgKGluIHRoZSBzZW5kZXIpLiBFdmVuIGZvciBk cm9wLCBkZXRlY3RpbmcgaWYgcGFja2V0cyBhcmUgbG9zdCwgb24gd2hpY2ggcGF0aCB0aGV5IHdl cmUgbG9zdCBzZWVtcyBhbHJlYWR5IG5vbi10cml2aWFsLg0KDQpFdmVuIHdpdGggc2luZ2xlIHBh Y2tldCBzZXF1ZW5jZSBudW1iZXIgc3BhY2UsIGlzIGl0IG5vdCBwb3NzaWJsZSBmb3IgYm90aCB0 aGUgc2VuZGVyIGFuZCB0aGUgcmVjZWl2ZXIgdG8gZGV0ZWN0IHRoZSBtdWx0aXBsZSBwYXRocywg a2VlcCBFQ04gY291bnRlciBjb250ZXh0IHBlciBwYXRoLCBhbmQgc2VuZCB0aGVzZSBjb3VudGVy cyBvbmx5IGZvciBhY2tzIG9uIHRoYXQgcGF0aC4NCg0KSXMgaXQgZW52aXNpb25lZCB0byBhbGxv dyBhY2tpbmcgcGFja2V0cyBvbiBhbm90aGVyIHBhdGggdGhhbiBvbiB0aGUgcGF0aCB0aGV5IHdl cmUgcmVjZWl2ZWQgKG90aGVyIHRoYW4gaW4gZXhjZXB0aW9uYWwgY29uZGl0aW9ucyBsaWtlIGFm dGVyIHBhdGggZmFpbHVyZSk/IEluIHRoYXQgY2FzZSB3ZSB3b3VsZCBuZWVkIGEgcGF0aCBpZCBp biB0aGUgcGVyIHBhdGggY291bnRlcnMgZmVlZGJhY2suIEFsc28gdGhlIGltcGFjdCBmb3IgbG9z cyBiYXNlZCBjb25nZXN0aW9uIGNvbnRyb2wgd291bGQgYmUgaGFyZCB0byBtYW5hZ2UgKG5lZWRz IGEgdmlldyBpbiBhbGwgcGF0aHMgZm9yIGFsbCBwYXRocywgbWVhbmluZyBhY2tzIG5lZWQgdG8g YmUgc2hhcmVkIG92ZXIgYWxsIHBhdGhzKS4gTWF5YmUgcmVjZWl2ZWQgcGFja2V0IGNvdW50ZXIg c3RhdGUgcGVyIHBhdGggd2lsbCBpbXByb3ZlIGxvc3MgYmFzZWQgY29uZ2VzdGlvbiBjb250cm9s IHRvbyB0byBtYWtlIHRoZSBwcm9jZXNzaW5nIG9mIHRoaXMgbW9yZSBmZWFzaWJsZS4uLg0KDQpB ZGRpdGlvbmFsbHksIGluIHRoZSBleGFtcGxlIG1lbnRpb25lZCBiZWZvcmUsIGluZGVlZCAzMCBw YWNrZXRzIGZpdCBpbiA4IGJ5dGVzLCBidXQgb24gYSAxR2JwcyBsaW5rIHdpdGggYSAxMG1zIFJU VCwgODMzIHBhY2tldHMgYXJlIGluIGZsaWdodCwgYW5kIHlvdSBuZWVkIDgzMyBiaXRzLiBEb2Vz IHRoaXMgbWVhbiB3ZSBoYXZlIHRvIHNhY3JpZmljZSAxMDQgYnl0ZXMgcGVyIGFjayBvbiBzdWNo IGEgcGF0aCwgYW5kIGZpbHRlciwgbWFwIGFuZCBjb3VudCA4MzMgYml0cyBwZXIgYWNrIHBhY2tl dCByZWNlaXZlZD8NCg0KUmVnYXJkcywNCktvZW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBMdWJhc2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dIA0K U2VudDogVGh1cnNkYXksIEphbnVhcnkgMjUsIDIwMTggNzozMCBBTQ0KVG86IEJyaWFuIFRyYW1t ZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD4NCkNjOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD47IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEJvYiBCcmlzY29lIChy ZXNlYXJjaEBib2JicmlzY29lLm5ldCkgPHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0PjsgRGUgU2No ZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEt YmVsbC1sYWJzLmNvbT4NClN1YmplY3Q6IFJFOiBFQ04gaW4gUVVJQw0KDQo+IE9uIFRodXJzZGF5 LCBKYW51YXJ5IDI1LCAyMDE4IDE6MDMgQU0sIEJyaWFuIFRyYW1tZWxsIChJRVRGKSBbbWFpbHRv OmlldGZAdHJhbW1lbGwuY2hdIHdyb3RlOg0KPg0KPiBJJ2xsIGFsc28gbm90ZSB0aGF0IGluIHRo ZSBjdXJyZW50IEludGVybmV0IGNhc2UgKG5vIEw0UyBvciBEQ1RDUCwgc3BvcmFkaWMgZGVwbG95 bWVudCBvZiBDRS1tYXJraW5nIHJvdXRlcnMpLCB0aGVyZSBhcmUgb3Bwb3J0dW5pdGllcyBmb3Ig bGFyZ2Ugc2F2aW5ncyB3aXRoIHRoZSBiaXRtYXAgYXBwcm9hY2ggdGhyb3VnaCB0cml2aWFsbHkg c2ltcGxlIGNvbXByZXNzaW9uIChtYXliZSBldmVuIGFzIHNpbXBsZSBhcyBhIHNwZWNpYWwgcmVw cmVzZW50YXRpb24gZm9yICJhbGwgb2YgdGhlc2UgcGFja2V0cyB3ZXJlIDAvRUNUMC9FQ1QxIiku DQoNCkNvbXBsZXRlbHkgYWdyZWUuDQoNClRoYXQncyBleGFjdCB3aHkgSSBoYWQgQUNLIGFuZCBB Q0stRUNUIGZyYW1lcyBpbiBteSBwcm9wb3NhbCAoc2VlIGVhcmxpZXIgaW4gdGhlIHRocmVhZCkg LS0gdG8gbWFrZSAiYWxsIHBhY2tldHMgaGF2ZSBubyBFQ04gbWFya2luZ3MiIGFuZCAiYWxsIHBh Y2tldHMgYXJlIEVDVCIgY2FzZXMgY29zdCAwIGJ5dGVzLiAgVGhlIGNvbW1vbiBjYXNlIHRvZGF5 IHdvdWxkIGNvc3Qgbm90aGluZy4gIFdoZW4gc29tZSBwYXRoIGdldHMgImludGVyZXN0aW5nIiwg aXQgd291bGQgc3RhcnQgY29zdGluZyB+MiBiaXRzIHBlciBwYWNrZXQuDQoNCihTZWUgUGFydHMg MSYyIGFuZCBpZ25vcmUgUGFydCAzLCB3aGljaCBoYXMgYSBwZXItQUNLX0Jsb2NrIGluc3RlYWQg b2YgYSBwZXItcGFja2V0IGJpdG1hcDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9xdWljL2N1cnJlbnQvbXNnMDI5NzMuaHRtbCkuDQoNCi0gSWdvcg0K From nobody Thu Jan 25 02:41:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC8612D967; Thu, 25 Jan 2018 02:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 5Nra79a4boWQ; Thu, 25 Jan 2018 02:41:06 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B126CBF; Thu, 25 Jan 2018 02:41:06 -0800 (PST) Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7BFC91B001CF; Thu, 25 Jan 2018 10:41:04 +0000 (GMT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id B9E7E216CA; Thu, 25 Jan 2018 05:41:00 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 25 Jan 2018 05:41:00 -0500 X-ME-Sender: Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id C785124640; Thu, 25 Jan 2018 05:40:59 -0500 (EST) Date: Thu, 25 Jan 2018 10:40:57 +0000 From: Tom Jones To: Christian Huitema Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Michael Tuexen , Gorry Fairhurst , "tsvwg@ietf.org" , QUIC WG Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Message-ID: <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> User-Agent: Mutt/1.9.2 (2017-12-15) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 10:41:10 -0000 On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote: > > > On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote: > > Here is a Fibonacci variant the grows slower. > > Not sure it is any better, but the intention is to avoid probing very > > large packets too early. > > It could probably be applied recursively to avoid bin search altogether. > > The same idea might be applicable to reducing the congestion window as > > opposed to doubling or halving. > > > > /* Fibonacci variant */ > > /* roughly like this - untestet */ > > unit = 10 /* min probe increment */ > > a = minPMTU / unit > > b = maxPMTU / unit > > k1 = initDelta /* 1 or larger, e.g. a / 4 */ > > k0 = 0 > > while a + k0 <= b > > k2 = k0 + k1 > > n = binsearch(a + k0, min(a + k1 - 1, b), unit) > > if n return n > > k0 = k1 > > k1 = k2 > > end > > /* binsearch probes multiples of unit and calls > > updatePMTUEstimate(n) whenever n is a larger > > valid probe than previously reported */ > > > Yes, there are multiple ways to go about sending probes. In the QUIC > case, the peer sends its own version of MAX MTU during the handshake. So > what I did was simply try the peer's MTU, and if that fail do a binary > search between that and the initial value. The peer MTU is typically > between 1470 and 1500, so the binary search converges very quickly. Thanks for the comment, this is an interesting approach we probably need some discussion of the probe size search algorithm in the draft. Is the ~1500 value something you have manually configured or have you found it from the host? maxdgram on my machine is 9216. > There are certainly ways to do better, especially if the peer sets its > own MTU to some large value, e.g. in a data center environment. For > example, one could have a table of probability of finding some > particular MTU. And then apply logic based on how much the connection > wants to send, what it costs to send a probe, and what is the likely > gain if the probe succeeds. You could use that to choose the next probed > value. Or to decide to stop probing if no plausible next value can bring > a potential gain. Or to send several probes in parallel... > RFC1191 suggested a table with some common values. I would try: - validating the base ~1280 - probing for ~1500 - if that works probing for the Max MTU from the peer then falling back to a search algorithm to close the gap if it is a sensible size. - [tj] From nobody Thu Jan 25 03:43:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BAA12DA1D for ; Thu, 25 Jan 2018 03:43:24 -0800 (PST) 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 uHuiU5fet-9o for ; Thu, 25 Jan 2018 03:43:21 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ECC612DA1A for ; Thu, 25 Jan 2018 03:43:21 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id l17so8339924ioc.3 for ; Thu, 25 Jan 2018 03:43:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=klhrHIO1OTxBjsDzmE/SW7tyktB/tEnPtlzTJXZAR5A=; b=bH720Nf3rnEhm2x8n0Fa8Fskqx3leO6fmtETWQn8SlRRjZqXsGCLVxCDQCqN/pQY5z JvvxW/5vqqrUVIFew9f50obeclbAjbqrZaKyxjOpgSR4lgGhv9OYkiSUUye45O3Fdqzf HjZ94b56UhyU3qAsWfk+gPBCRwWpSwQtc0yiGMd5P5TmQ2O93121zGCGIswn9A5kwLub Ix0wAUHnkVxHEVOb9uPRVOqy+zxkzUWnOwbJwyMNIIjUhC3idD3aAqVl59d6OVudJtlz 0LS2qXm2X1RbrJg7ErAHKhp08HVwNkfvE4K3fQB2+bhQZI+wT5I37oeIGqYymf1JnN6K LiAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=klhrHIO1OTxBjsDzmE/SW7tyktB/tEnPtlzTJXZAR5A=; b=BaUNR6Ng8xhmM3rGyMw9Fub5P9P08WuPu1AlIWYpf7yYRKc8mW6bviCAUrZkpCHFUt cDGO+gre83V8kiz9SDS+aUHbxQOirSamUdSrVHzox9xxmnHNfNX/a4xsNF56ne05ikmY TpZzm9y9x90PCqJAu1V8bhc5bS+ajbhwTeqEzbEmPKIHCWcS3sx0n5ad48LvRi5c/jUt eDTvqKdnzpJCkqQCnQh4mSX5HKzsjF37+JFkHlmcQnBaleVnIGYbN4UD4YutVBWwtNqI IvG/jbBhrFxhqlvA4r3HqXLJ2Z+WONH6ufgwH2y8A9/GByXI3G88d2siTBottJQWGc2r Ryww== X-Gm-Message-State: AKwxyte6vK7631h82ENyFGrS2jh6GV5C8rDS/oqqCKRpEzPfloMnekQS rt78Lw19cXPjR5C98Ug772EhVN/12/lP/hHF+tlm7A== X-Google-Smtp-Source: AH8x227R4PuMt8mZSu5ttuWW23/KI85OTWbqFEvOVjfQPgaZkd9/LAk2LNlfQuq3UAKONxqi1EeWHX8xSwHUkpyYlzI= X-Received: by 10.107.168.25 with SMTP id r25mr11985741ioe.16.1516880600394; Thu, 25 Jan 2018 03:43:20 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Jan 2018 03:43:19 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 25 Jan 2018 03:43:19 -0800 Message-ID: Subject: Re: Read-out on offline connection ID discussion To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11427bca5a7065056398497e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 11:43:25 -0000 --001a11427bca5a7065056398497e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But I now think I understand the concerns with AES block size. You want to spread a few bits over multiple bits, like with a hash function except reversible. I stated below that you could add more than the necessary R routing bits. But if you don=E2=80=99t don=E2=80=99t mix those bits it is easy to flip bi= ts. If you take the R routing bits as input to AES instead of a counter, you achieve the desired mixing, but then it is correct that you need 16 bytes to recover the information. You could still use the XOR method and use a shorter authentication tag instead - this would not make the routing bit locations unidentifiable, but it would make the unmodifiable with a certain probability. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 10.11.22, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: I=E2=80=99m not even sure that will work because the RECID could also be re= played. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 10.07.35, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Another thing is that such a scheme is somewhat broken because an off-path attacker can connect to a host as any other client and retrieve a connection ID. Then it has sufficient information about the routing table for the next our to flood a specific route. It=E2=80=99s not really possible to avoid unless each router has more infor= mation than a key rotating every hour. The targeted server can protect itself by not accepting any encrypted ECID in a new handshake and drop packets via ordinary auth failure on other packets. To handle stateless retry, the encryption ECID for retry must be different, so we name it RECID. The targeted server will generate ECID for client initiated communication with a random client CID, or accept RECID based handshakes, but will not accept ECID for handshake because that is a DoS waiting to happen. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote: I don=E2=80=99t understand this requirement for the CID to be 16 bytes in o= rder to be encrypted. If you have a unique key you can encrypt 0, truncate and xor with the CID. If you don=E2=80=99t have a unique key, you can encrypt a unique counter va= lue and do the same, or derive a unique key. I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.? I=E2=80=99m merely stating that if you want to encrypt with AES and you do = not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic. There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES. As to a possible scheme: Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make= it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P= =3D not P if key changed since last derivation. The encrypted CID ECID =3D . We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation. The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route. We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag. In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in. http://www.mindspring.com/~dmcgrew/gcm-nist-6.pdf AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part. --001a11427bca5a7065056398497e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = But I now think I un= derstand the concerns with AES block size.
    You want to spread a few bits over multiple b= its, like with a hash function except reversible.

    I stated below that you could add more than th= e necessary R routing bits. But if you don=E2=80=99t don=E2=80=99t mix thos= e bits it is easy to flip bits. If you take the R routing bits as input to = AES instead of a counter, you achieve the desired mixing, but then it is co= rrect that you need 16 bytes to recover the information.

    You could still use the XOR method and = use a shorter authentication tag instead - this would not make the routing = bit locations unidentifiable, but it would make the unmodifiable with a cer= tain probability.


    Kind Re= gards,
    Mikke= l Fahn=C3=B8e J=C3=B8rgensen


    On 25 January 2018 at 10.11.22, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    I=E2=80=99m not even sure that will work because the RECID could also be replayed.

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


    On 25 January 2018 at 10.07.35, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

    Another thing is that such a scheme is somewhat broken because an off-path attacker can connect to a host as any other client and retrieve a connection ID. Then it has sufficient information about the routing table for the next our to flood a specific route.

    It=E2=80=99s not really possible to avoid unless each router has more information than a key rotating every hour.

    The targeted server can protect itself by not accepting any encrypted ECID in a new handshake and drop packets via ordinary auth failure on other packets.

    To handle stateless retry, the encryption ECID for retry must be different, so we name it RECID. The targeted server will generate ECID for client initiated communication with a random client CID, or accept RECID based handshakes, but will not accept ECID for handshake because that is a DoS waiting to happen.
    Kind Regards,
    Mikkel Fahn=C3=B8e J=C3=B8rgensen

    On 25 January 2018 at 09.45.07, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

    On 25 January 2018 at 00.16.55, Eric Rescorla (ekr@rtfm.com) wrote:
    I don=E2=80=99t understand this requirement for the CID to be 16 bytes in order to be encrypted.
    If you have a unique key you can encrypt 0, truncate and xor with the CID.
    If you don=E2=80=99t have a unique key, you can encrypt a unique counter value and do the same, or derive a unique key.

    I don't believe what you are describing works correctly, but I'm not sure I understand your proposal. Can you please flesh out precisely what you have in mind? In particular, who is "you", who has the key, etc.?

    I=E2=80=99m merely stating that if you want to encrypt with AES and you do not care about authentication, then AES works fine with shorter inputs than 16 bytes. You may still have to provide an initialisation vector so the +n still holds. The last block of AES-GCM is not a full block and works as i described - see sect. 2.3 and figure 1 in link to GCM paper. If the last block is the only block, you encrypt less than 16 bytes without any magic.

    There are many reasons you might want to use 16 bytes, or you might want to add authentication, but it is not AES itself that imposes those constraints as already argued. My point is that if you need 16 bytes, please state why, instead of blaming it on AES.

    As to a possible scheme:

    Assume a server cluster wants to encode routing data by selecting one out of 256 possible routes and a 8 bit unique id for each route. This can be done with 16 bits. (Not saying this is a good idea). Or, let=E2=80=99s make it simple for a start: just have 1 routing bit R to choose between two servers and 1 IV bit to identify the connection, and one phase bit P. The objective is to make it unpredictable which server is hit. The encryption of the two bits happen by encrypting the IV bit with a cluster key that all routers are aware of. The phase bit is not needed but avoids guessing which router key is active since it rotates every hour derived from a master key. The encrypted CID is just 1 bit flipped randomly based on XOR=E2=80=99ing with encrypting 1 or 0, depending the IV is 1 or 0. key =3D derive(master, R), P =3D not P if key changed since last derivation. The encrypted CID ECID =3D <AES(key, IV) XOR R, IV, P>.

    We can readily extend the above to as many R bits as needed. The IV must be unique but if we only care about making it hard to force a route rather than protecting information, it is less critical, assuming we hide the master key behind strong derivation.

    The problem is that an attacker can easily flip the first bit in the ECID. We can make this harder by having more than R bits than valid routes and having more IV bits chosen at random. The R bits now either map to a valid route or not. It becomes harder to guess a valid route.

    We can make this harder by adding an auth tag - say of length 16 bits. AES-GCM is not suited for short tags, but there CMACs that can do this I believe (two times AES + padding and truncation to desired length, from memory). However, if it is sufficiently hard to guess a route, and it is easy to decide if a route is valid or not, it may not be necessary with an auth tag.

    In addition we want to identify the connection uniquely with respect to the chosen server route so we add U bits to make the connection id unique. These do not have to be encrypted, but they might as well be thrown in.

    http://www= .mindspring.com/~dmcgrew/gcm-nist-6.pdf

    AES-GCM goes horribly wrong if the same encrypted counter value is used twice - but we may not have a problem with horribly wrong in our use case, which also only uses the CTR mode part.

     --001a11427bca5a7065056398497e-- From nobody Thu Jan 25 05:02:04 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576CE129966; Thu, 25 Jan 2018 05:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUApPTFCHVMX; Thu, 25 Jan 2018 05:02:00 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 B157012751F; Thu, 25 Jan 2018 05:01:59 -0800 (PST) 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 w0PD0GUk021077 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jan 2018 14:00:16 +0100 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eeh80-0003b3-TL; Thu, 25 Jan 2018 13:59:40 +0100 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 Date: Thu, 25 Jan 2018 14:00:14 +0100 In-Reply-To: <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> Cc: Christian Huitema , Gorry Fairhurst , Michael Tuexen , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , "tsvwg@ietf.org" To: Tom Jones References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 13:02:02 -0000 --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 25. Jan 2018, at 11:40, Tom Jones wrote: >=20 > On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote: >>=20 >>=20 >> On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >>> Here is a Fibonacci variant the grows slower. >>> Not sure it is any better, but the intention is to avoid probing = very >>> large packets too early. >>> It could probably be applied recursively to avoid bin search = altogether. >>> The same idea might be applicable to reducing the congestion window = as >>> opposed to doubling or halving. >>>=20 >>> /* Fibonacci variant */ >>> /* roughly like this - untestet */ >>> unit =3D 10 /* min probe increment */ >>> a =3D minPMTU / unit >>> b =3D maxPMTU / unit >>> k1 =3D initDelta /* 1 or larger, e.g. a / 4 */ >>> k0 =3D 0 >>> while a + k0 <=3D b >>> k2 =3D k0 + k1 >>> n =3D binsearch(a + k0, min(a + k1 - 1, b), unit) >>> if n return n >>> k0 =3D k1 >>> k1 =3D k2 >>> end >>> /* binsearch probes multiples of unit and calls >>> updatePMTUEstimate(n) whenever n is a larger >>> valid probe than previously reported */ >>>=20 >> Yes, there are multiple ways to go about sending probes. In the QUIC >> case, the peer sends its own version of MAX MTU during the handshake. = So >> what I did was simply try the peer's MTU, and if that fail do a = binary >> search between that and the initial value. The peer MTU is typically >> between 1470 and 1500, so the binary search converges very quickly. >=20 > Thanks for the comment, this is an interesting approach we probably = need > some discussion of the probe size search algorithm in the draft.=20 Ack; =E2=80=93 I think the main question is whether you want a generic algorithm or something that is optimised for today=E2=80=99s Internet, but also somehow works otherwise. >=20 > Is the ~1500 value something you have manually configured or have you > found it from the host? maxdgram on my machine is 9216. 1500 is default for Ethernet without Jumbo Frames. >> There are certainly ways to do better, especially if the peer sets = its >> own MTU to some large value, e.g. in a data center environment. For >> example, one could have a table of probability of finding some >> particular MTU. And then apply logic based on how much the connection >> wants to send, what it costs to send a probe, and what is the likely >> gain if the probe succeeds. You could use that to choose the next = probed >> value. Or to decide to stop probing if no plausible next value can = bring >> a potential gain. Or to send several probes in parallel... >>=20 >=20 > RFC1191 suggested a table with some common values. I would try: >=20 > - validating the base ~1280 > - probing for ~1500 > - if that works probing for the Max MTU from the peer >=20 > then falling back to a search algorithm to close the gap if it is a > sensible size. I think the table from RFC1191 will need updating, but I think this approach works best: - validating the base ~1280 - probe table of common MTUs (linear or binary search)=20 including Max MTU=20 - do some search between the largest working / smallest non-working MTU Whereby I would use some exponential search variant (not tested): =20 MTUsearch (a,b,step): if probeMTU(b-step): MTU :=3D b-step a :=3D b-step step =3D step/2 else b =3D b-step step =3D step*2 if b > a MTUsearch(a,b,step) =20 =20 Rational behind that is that MTUs will usually be LL-MTU (hopefully in = the table) minus some encapsulation. AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On 25. Jan 2018, at 11:40, Tom Jones <tom@erg.abdn.ac.uk> = wrote:

    On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema = wrote:


    On 1/20/2018 11:50 PM, Mikkel Fahn=C3=B8e = J=C3=B8rgensen wrote:
    Here is a Fibonacci variant the grows slower.
    Not= sure it is any better, but the intention is to avoid probing very
    large packets too early.
    It could probably be = applied recursively to avoid bin search altogether.
    The = same idea might be applicable to reducing the congestion window as
    opposed to doubling or halving.

    /*= Fibonacci variant */
    /* roughly like this - untestet = */
    unit =3D 10 /* min probe increment */
    a =3D= minPMTU / unit
    b =3D maxPMTU / unit
    k1 =3D = initDelta /* 1 or larger, e.g. a / 4 */
    k0 =3D 0
    while a + k0 <=3D b
     k2 =3D k0 + k1
     n =3D binsearch(a + k0, min(a + k1 - 1, b), unit)
     if n return n
     k0 =3D k1
     k1 =3D k2
    end
    /* binsearch = probes multiples of unit and calls
    =   updatePMTUEstimate(n) whenever n is a larger
    =   valid probe than previously reported */

    Yes, there are multiple ways to go about sending = probes. In the QUIC
    case, the peer sends its own version = of MAX MTU during the handshake. So
    what I did was simply = try the peer's MTU, and if that fail do a binary
    search = between that and the initial value. The peer MTU is typically
    between 1470 and 1500, so the binary search converges very = quickly.

    Thanks for the = comment, this is an interesting approach we probably need
    some discussion of the probe size search algorithm in the = draft.

    Ack; =E2=80=93 I think the main question is = whether you want a generic
    algorithm or something that is = optimised for today=E2=80=99s Internet,
    but also somehow works = otherwise.


    Is the ~1500 value something = you have manually configured or have you
    found it from the = host? maxdgram on my machine is 9216.

    1500 is default for Ethernet without Jumbo = Frames.

    There = are certainly ways to do better, especially if the peer sets its
    own MTU to some large value, e.g. in a data center = environment. For
    example, one could have a table of = probability of finding some
    particular MTU. And then apply = logic based on how much the connection
    wants to send, what = it costs to send a probe, and what is the likely
    gain if = the probe succeeds. You could use that to choose the next probed
    value. Or to decide to stop probing if no plausible next = value can bring
    a potential gain. Or to send several = probes in parallel...


    RFC1191 suggested a table with some common values. I would = try:

    - validating the base ~1280
    = - probing for ~1500
    - if that works probing for the = Max MTU from the peer

    then falling back to = a search algorithm to close the gap if it is a
    sensible = size.


    I think = the table from RFC1191 will need updating, but I think this
    approach works best:
     - validating = the base ~1280
     - probe table of common MTUs = (linear or binary search) 
      =  including Max MTU 
     - do some = search between the largest working / smallest non-working MTU

    Whereby I would use some = exponential search variant (not tested):
     
     MTUsearch = (a,b,step):
       if = probeMTU(b-step):
          MTU :=3D = b-step
          a =   :=3D b-step
          step = =3D step/2
       else
          b =3D b-step
      =     step =3D step*2
       if b = > a
          MTUsearch(a,b,step) =    
     
    Rational behind that is that MTUs will usually be = LL-MTU (hopefully in the table) minus some encapsulation.

    AVE!
      Philipp S. Tiesel / phils=E2=80=A6
    = --Apple-Mail=_EBD182D4-1C4F-4445-BBBC-A549E4DDC1AD-- From nobody Thu Jan 25 07:35:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518C7126B6E; Thu, 25 Jan 2018 07:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 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, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 fuGZ-9o4rNHf; Thu, 25 Jan 2018 07:35:38 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 D1B92124BAC; Thu, 25 Jan 2018 07:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FfGdriwYytEWGlxuf7uNTlckCg/hfQET5xagf7XnmE8=; b=z3Ld/Jonzq7bxPb5M4euU0KZX /bNovbVBw+Va23U4FDXrOHtpcM43mmxNdl2Qyi4A2Ru9loCJiX2e8TcccW9LagLHyNjRI/+LrOvHq zAlAoPovlyK8NiP4hYdX6ijLtVccWh9JmlenUSRmhveIGvNlKQAgn8VtQnAfQcXlUNH3oFGV7uA9c i7ElNzEXfZM55FsiPSGDvTXs+SBJc9folOlkX3M/SfFKicPfeDU9RQ9R1JE9x4UWRabOb3lIwxLAA 5yAqflOYF945LxUUzFDyaFAcPsONzTpD1B+SVkaGezd7cLfmqNXld3vCvJ8HarRzUVAnQcaY8va1S NcB2mortw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49886 helo=[192.168.1.87]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eejYG-003oSm-PX; Thu, 25 Jan 2018 10:35:03 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018 From: Joe Touch In-Reply-To: Date: Thu, 25 Jan 2018 07:34:38 -0800 Cc: Tom Jones , Gorry Fairhurst , "tsvwg@ietf.org" , Christian Huitema , Michael Tuexen , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Message-Id: References: <9837331A-76DF-4137-9612-CC653E869553@netapp.com> <5A563390.8050403@erg.abdn.ac.uk> <4123465B-CFE2-410E-BE1D-E09DC189F280@huitema.net> <9493C5B9-A79E-4311-8C07-67E14564B1ED@lurchi.franken.de> <838694fc-bfb6-9804-b8fa-ad7aa47e5472@huitema.net> <150452ec-ba36-f88a-4c29-013fea99c9c2@huitema.net> <20180125104057.GA9797@tom-desk.erg.abdn.ac.uk> To: "Philipp S. Tiesel" X-Mailer: Apple Mail (2.3445.5.20) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 15:35:40 -0000 --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 25, 2018, at 5:00 AM, Philipp S. Tiesel = wrote: >=20 >=20 >=20 >> On 25. Jan 2018, at 11:40, Tom Jones > wrote: >> ... >> Thanks for the comment, this is an interesting approach we probably = need >> some discussion of the probe size search algorithm in the draft.=20 >=20 > Ack; =E2=80=93 I think the main question is whether you want a generic > algorithm or something that is optimised for today=E2=80=99s Internet, > but also somehow works otherwise. 1) we should have a generic algorithm that should be applicable across = all PLPMTUD variants, unless there are specific reasons otherwise. This = is a wheel that should not be reinvented for each packetization layer = protocol. 2) whatever you *think* =E2=80=9Ctoday=E2=80=99s Internet is=E2=80=9D, = you=E2=80=99re wrong today and you=E2=80=99ll be very wrong in the = future. Design to work well in most environments most of the time, and = you=E2=80=99ll have =E2=80=9Coptimized=E2=80=9D for the most important = case for the Internet - ubiquity and longevity. Joe= --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

    On Jan 25, 2018, at 5:00 AM, Philipp S. Tiesel <phils@in-panik.de> = wrote:


    On 25. Jan 2018, at 11:40, Tom = Jones <tom@erg.abdn.ac.uk> wrote:
    ...
    Thanks for the comment, this is an = interesting approach we probably need
    some discussion of = the probe size search algorithm in the draft. 

    Ack; =E2=80=93 I think the main = question is whether you want a generic
    algorithm or = something that is optimised for today=E2=80=99s Internet,
    but also somehow works = otherwise.

    1) we = should have a generic algorithm that should be applicable across all = PLPMTUD variants, unless there are specific reasons otherwise. This is a = wheel that should not be reinvented for each packetization layer = protocol.

    2) whatever you *think* = =E2=80=9Ctoday=E2=80=99s Internet is=E2=80=9D, you=E2=80=99re wrong = today and you=E2=80=99ll be very wrong in the future. Design to work = well in most environments most of the time, and you=E2=80=99ll have = =E2=80=9Coptimized=E2=80=9D for the most important case for the Internet = - ubiquity and longevity.

    Joe
    = --Apple-Mail=_249E98D2-0E71-4E2E-9F3A-4712DBCB74B4-- From nobody Thu Jan 25 08:34:36 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE2F12DA51 for ; Thu, 25 Jan 2018 08:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 uiOR46zDunVV for ; Thu, 25 Jan 2018 08:34:31 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c: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 81F1712DA73 for ; Thu, 25 Jan 2018 08:34:26 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id f71so15738954wmf.0 for ; Thu, 25 Jan 2018 08:34:26 -0800 (PST) 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=pzofMFc2BWU5tQdCS7znte5lNj2GLC8YmJZc1/stilQ=; b=llF20rGFskalxrnjNDXLxpuDtVaEhmOYAf2lMPn+28nsbPbRQ0M2w/A++OQmvu6xwz YZ2j72F8fZIjC4b1bvm+5ZkceuHeebLTuYBkjRCjItRRpteUvIlkV3IorCvKrAK00YYd K0vsPE7hTAcKJav9sbtBHn4F6AXnJL1QuogtgZmFhw79a5xmCRjZqS9JMt0bbRrs33T1 wkWO73Z2jDLSRZj5o5HFD1XWo0xd0KPVf/9wNyJE6icSFZnalqL+19B8dyJi6sTR+JoN Z4RwnDVeHXNp8Dq3RacRrkMIlW0hEnAxnNn3bgjjcGkEMApaHkSvlv4yHMjO3ZbqrpVT G7JA== 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=pzofMFc2BWU5tQdCS7znte5lNj2GLC8YmJZc1/stilQ=; b=nyvrZaLzDT1LRjoOJNAOzfIWXRfhHecCrr1EQyfSkpY0C7lzJyb2FlyFS5+ZsKpBwO 4xAP/Sd20eBt0xVRocBt4gVphl2yaS5On1tJ/jlffK6EGRZvVj9GKLDDfwrKLcwEOJa2 ytDtg138Nr6KkMeivDEbXio6KOK+i5c88H3wTkURQamL2vYOWkXO3d+YVal6EqRkvzZq weOtN0B/9nlX26L3b47D6fMk91GCBH5nP4rSDTJfj/FAjsC98hCU9LR2PrQEBCIB64OW YV5xun5pp68pzIw5yX6dYO4FcNJMAlmqLrwuBPHjKQSS41xZHNFSitdIUEbPClT6TXKZ Zr5A== X-Gm-Message-State: AKwxytcKr7O4DPr6YLRFdV2DZHJYY9N6lrtNn9FguOqcJfcp1McdAWRQ Mb2PYCKXzI5jSwgyN4b61rEuqV5Azzt36kX/UBx+HFQs X-Google-Smtp-Source: AH8x227Oby1lq/vjvOBoMvnUJm1CZW8DjsBSOdHKpGAZsGV7BsO3NIvymbfwqn5tGBUXK3B0FRVmNHFFY27ADxFTHX4= X-Received: by 10.80.129.225 with SMTP id 88mr29900782ede.19.1516898064616; Thu, 25 Jan 2018 08:34:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.134.182 with HTTP; Thu, 25 Jan 2018 08:34:24 -0800 (PST) From: Victor Vasiliev Date: Thu, 25 Jan 2018 11:34:24 -0500 Message-ID: Subject: Mechanism for negotiating extensions To: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05da824e074905639c5a4c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 16:34:34 -0000 --94eb2c05da824e074905639c5a4c Content-Type: text/plain; charset="UTF-8" I've been thinking about extension negotiation, and I'm not entirely sure that "just put a transport parameter per extension" is a sufficiently complete answer. There are at least two problems in extending QUIC that we ought to address. The first problem is that the frame type field is only one byte long. While this is enough for any single QUIC connection, if we try to allocate those globally in a non-conflicting manner, we might exhaust it sooner than we think (also, this would require coordinating two extensions to be compatible). Thus, I believe we should to add a general mechanism where every extension, when negotiated, would specify which frame type numbers it's using on the wire for each frame, so that this number allocation can be performed on per-connection basis. I believe there are mechanisms similar to that in other protocols (e.g. RTP does something like that in RFC 8285). The second problem is that the client list of offered extensions is not protected by secure keys. I am not sure how much of an issue this is in terms of ossification -- I don't remember off the top of my head where it caused problems in TLS *per se*, and inventing a completely new mechanism for it will surely run into a set of issues. Still, it's worth discussing. If people believe that the mapping proposal is valuable, I can write up a PR for this. --94eb2c05da824e074905639c5a4c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I've been thinking about extension negotiation, and I&= #39;m not entirely sure that "just put a transport parameter per exten= sion" is a sufficiently complete answer.=C2=A0 There are at least two = problems in extending QUIC that we ought to address.

    The= first problem is that the frame type field is only one byte long.=C2=A0 Wh= ile this is enough for any single QUIC connection, if we try to allocate th= ose globally in a non-conflicting manner, we might exhaust it sooner than w= e think (also, this would require coordinating two extensions to be compati= ble).=C2=A0 Thus, I believe we should to add a general mechanism where ever= y extension, when negotiated, would specify which frame type numbers it'= ;s using on the wire for each frame, so that this number allocation can be = performed on per-connection basis.=C2=A0 I believe there are mechanisms sim= ilar to that in other protocols (e.g. RTP does something like that in RFC 8= 285).

    The second problem is that the client list o= f offered extensions is not protected by secure keys.=C2=A0 I am not sure h= ow much of an issue this is in terms of ossification -- I don't remembe= r off the top of my head where it caused problems in TLS per se, and= inventing a completely new mechanism for it will surely run into a set of = issues.=C2=A0 Still, it's worth discussing.

    If= people believe that the mapping proposal is valuable, I can write up a PR = for this.
    --94eb2c05da824e074905639c5a4c-- From nobody Thu Jan 25 12:09:52 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC35912E89C for ; Thu, 25 Jan 2018 12:09:51 -0800 (PST) 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=EBOT8uk0; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Uc1gepkG Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHwv0inc8syJ for ; Thu, 25 Jan 2018 12:09:50 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5765C127601 for ; Thu, 25 Jan 2018 12:09:50 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w0PK9Pkd008392; Thu, 25 Jan 2018 12:09:49 -0800 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=8uSRDuwpmsT1HrVBls9JOHprYd6gGZr9ejdEH77JfGs=; b=EBOT8uk0sK4vS/+ljt0SY+t2ygZ6JxjVNjIAL4A4ObY8KJCidggZ6oVprLwJ4/0CvItC yCPGQB64Qp+9nECBhQdig8m17b4/6p3TCGwTPSmMUWP6tkaatdgoA6AhVAEl65fT4YjC 6Omnzv1jK1dAio7wRWKcW0j9u3XpmEM9MD0= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2fqkp18e5n-5 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Jan 2018 12:09:49 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.31) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 25 Jan 2018 15:09:27 -0500 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=8uSRDuwpmsT1HrVBls9JOHprYd6gGZr9ejdEH77JfGs=; b=Uc1gepkGN4tjUH+3s40D4CIh+48TQgGvVy8juSme4q7CJlzBjF79xeMPKUXiToxDPcXvxhUs747JBNamjSO2mEfgTgOShMhdJWK6qI8dOU+H03a/cpgPpbolTRKnM5CxOHRJjKmcN+hzcaG3/2ZD2fuWPg7G1YrzyD8wQF/an5Y= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Thu, 25 Jan 2018 20:09:26 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0428.024; Thu, 25 Jan 2018 20:09:26 +0000 From: Subodh Iyengar To: Victor Vasiliev , IETF QUIC WG Subject: Re: Mechanism for negotiating extensions Thread-Topic: Mechanism for negotiating extensions Thread-Index: AQHTlfp5B7VvQnb4bkKXByBUlrODTqOFBCrN Date: Thu, 25 Jan 2018 20:09:26 +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: [199.201.64.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 7:36kcCVZJVuBOnTvmxscRDyUzNzbL1uEr2UYnmx+R9mGJ/+4hCr6mUJK5p0TMqDLmdP7G4QBHu6LvCFy2O7OKhE20Kr5Busx0uSBZZKKxQge+KkhtFKBrITDyMPkqeHanPsx2weEKXq7olwLB25sRL4DeENXLsfD9Gy1sfeo2QjNBeN9O7HWLJbhRl9HWY3mtue8ciLhz/2uZpM3z2ivq9vKvk1P9ptS4fzaZp38LXNGSgcw7FfCsc887JQKVNEU7; 20:7WEIvlP6bEmFI5IMVfhXz6PwmcqSa0Q/UqznsV7a4bed/uO1KdqAtFIJUXQI63b9xUROLYEtw5t6FQDgL9NoaFrfV1YiTBzLqTD6Tkb2m7ExhkLCWYVqi66AOqJfjD+HvHzWhSnEyP+I4qRjejj+Q6Oiz9rCzBFTTDNBNDCgqws= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a036c93b-c365-4d11-889b-08d5642f88bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231059)(11241501184)(2400081)(944501161)(6041288)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1455; x-forefront-prvs: 0563F2E8B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(396003)(346002)(39860400002)(189003)(199004)(6246003)(19627405001)(97736004)(2906002)(3846002)(186003)(14454004)(3480700004)(26005)(2900100001)(25786009)(3280700002)(561944003)(33656002)(3660700001)(106356001)(6116002)(86362001)(68736007)(77096007)(316002)(55016002)(54896002)(6506007)(229853002)(102836004)(81156014)(478600001)(99286004)(53936002)(7696005)(8936002)(66066001)(53546011)(110136005)(9686003)(81166006)(5660300001)(2950100002)(105586002)(6606003)(7736002)(74316002)(76176011)(6436002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: /OKrXvApQzNJ90d2nqRGu6laLajtlISYUlBCkaS1zaFFlo0OVmbuO1uEHDc2DJ1MsMpyQ5mZHJGQ04QOecBBGg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14556D3385A8FEA859CCCFC1B6E10MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a036c93b-c365-4d11-889b-08d5642f88bf X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jan 2018 20:09:26.1256 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-25_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 20:09:52 -0000 --_000_MWHPR15MB14556D3385A8FEA859CCCFC1B6E10MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Alternatively, could we say that "You MUST not use extension frames in IETF= QUIC versions", i.e. if you want to use a extension frame, you should have= your own version of QUIC. This makes extension frames less useful for IETF QUIC versions, but private= experimental QUIC versions do not have to rev that often, which is super v= aluable as well. Subodh ________________________________ From: QUIC on behalf of Victor Vasiliev Sent: Thursday, January 25, 2018 8:34:24 AM To: IETF QUIC WG Subject: Mechanism for negotiating extensions I've been thinking about extension negotiation, and I'm not entirely sure t= hat "just put a transport parameter per extension" is a sufficiently comple= te answer. There are at least two problems in extending QUIC that we ought= to address. The first problem is that the frame type field is only one byte long. Whil= e this is enough for any single QUIC connection, if we try to allocate thos= e globally in a non-conflicting manner, we might exhaust it sooner than we = think (also, this would require coordinating two extensions to be compatibl= e). Thus, I believe we should to add a general mechanism where every exten= sion, when negotiated, would specify which frame type numbers it's using on= the wire for each frame, so that this number allocation can be performed o= n per-connection basis. I believe there are mechanisms similar to that in = other protocols (e.g. RTP does something like that in RFC 8285). The second problem is that the client list of offered extensions is not pro= tected by secure keys. I am not sure how much of an issue this is in terms= of ossification -- I don't remember off the top of my head where it caused= problems in TLS per se, and inventing a completely new mechanism for it wi= ll surely run into a set of issues. Still, it's worth discussing. If people believe that the mapping proposal is valuable, I can write up a P= R for this. --_000_MWHPR15MB14556D3385A8FEA859CCCFC1B6E10MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Alternatively, could we say that = "You MUST not use extension frames in IETF QUIC versions", i.e. i= f you want to use a extension frame, you should have your own version of QU= IC.


    This makes extension frames less = useful for IETF QUIC versions, but private experimental QUIC versions do no= t have to rev that often, which is super valuable as well.


    Subodh

    From: QUIC <quic-bounces= @ietf.org> on behalf of Victor Vasiliev <vasilvv@google.com>
    Sent: Thursday, January 25, 2018 8:34:24 AM
    To: IETF QUIC WG
    Subject: Mechanism for negotiating extensions
     
    I've been thinking about extension negotiation, and I'm no= t entirely sure that "just put a transport parameter per extension&quo= t; is a sufficiently complete answer.  There are at least two problems= in extending QUIC that we ought to address.

    The first problem is that the frame type field is only one byte long.&= nbsp; While this is enough for any single QUIC connection, if we try to all= ocate those globally in a non-conflicting manner, we might exhaust it soone= r than we think (also, this would require coordinating two extensions to be compatible).  Thus, I believe we sh= ould to add a general mechanism where every extension, when negotiated, wou= ld specify which frame type numbers it's using on the wire for each frame, = so that this number allocation can be performed on per-connection basis.  I believe there are mechanisms si= milar to that in other protocols (e.g. RTP does something like that in RFC = 8285).

    The second problem is that the client list of offered extensions is no= t protected by secure keys.  I am not sure how much of an issue this i= s in terms of ossification -- I don't remember off the top of my head where= it caused problems in TLS per se, and inventing a completely new mechanism for it will surely = run into a set of issues.  Still, it's worth discussing.

    If people believe that the mapping proposal is valuable, I can write u= p a PR for this.
    --_000_MWHPR15MB14556D3385A8FEA859CCCFC1B6E10MWHPR15MB1455namp_-- From nobody Thu Jan 25 13:03:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6229512EAB0 for ; Thu, 25 Jan 2018 13:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 157Qd0PL4kdX for ; Thu, 25 Jan 2018 13:03:50 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 15F6212EAAF for ; Thu, 25 Jan 2018 13:03:50 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id d7so8075105oti.0 for ; Thu, 25 Jan 2018 13:03:50 -0800 (PST) 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=nsdkNwAXdrPzGnz8kHibQ2a7LVVpZjynQSMCYhAGvXg=; b=hBDeUUBbh8YsW1OnA/rKj4Z0WDeWRJZp0xI6gdot9pToM1Rc7/bgsuN54peEk71sC1 fonIdo4EbDsJPEGuI6fqaVEGJa6Cz/b8WAdIEzUzWIV95c5VpjeHhPntn6ki8YyqTJYF dLm1O5Cx+r3Bst81C2tvvtmkxWaFZ9lGOhV3ol/mSPnIsGxcebTEt7KsX21TLNIwc5rA csNPmj2iskiUvT6Z9mtRJ61iG4X+7N2A+cHndlyW9nhHm9InUuafjGbka8iZXZzF7WvN yvwltoFUiGyS8mKRfy0sztZzebq8SgItNN4KO+jqyF43QZKnsOh6B3gHTe2fzHrgqCJg Rzug== 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=nsdkNwAXdrPzGnz8kHibQ2a7LVVpZjynQSMCYhAGvXg=; b=TlASxwuYSNA0TS/ZcBanqUBeaiM3b8rcQbhyhMxrtQoMRznxQgD5wfzfTVLjmHu2Wz r11DEqEiLuw+NQvRBMxzGROwfLQeiZ/pfv+5UmYZHZ+36l2ay5bCA4KMZKZNYBpd/PcW vaPIYUiU69hFHB07tg4nexjV+D518S6gQJsu9MOVhJhShOiryTrqIpVVsj7LNEsbTtDw owVb+aOWqQQE5AcCUPzGumbQXKuiTOcvJQWfeyIQoFA9XQrgAa53BwosLlPg2KbbGwa9 v4KN7bJmk4htqMNt34nFvW4GlcdHXgxepiOzoaSuvGlqfjKkCsgU4Ou5LVl71dRlJWDA GSVg== X-Gm-Message-State: AKwxytenIo/WCR5Q9Ue1REFlQve4m0/pcg9smyNgfjKfYK4xLJT0cfzj 9yxgX1W1GZieXGlxedJdcsHJjFknFI1mvJdONR3N X-Google-Smtp-Source: AH8x227j+HsSozz4Xpkbd+RjJW+LGh49poRTvLVoJXGzfwDrkPNj4Ao1PwM8Z/hIAHXs0UDtslv8uQ7ngazXR2+srew= X-Received: by 10.107.59.66 with SMTP id i63mr13692185ioa.220.1516914228691; Thu, 25 Jan 2018 13:03:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.156.203 with HTTP; Thu, 25 Jan 2018 13:03:28 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Thu, 25 Jan 2018 13:03:28 -0800 Message-ID: Subject: Re: Updated QCRAM Draft To: Kazuho Oku Cc: Jana Iyengar , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c068686c268e70563a01d29" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 21:03:53 -0000 --94eb2c068686c268e70563a01d29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've gotten the simulator working with QCRAM -04 changes, specifically the part that moves all updates to the control stream. I ran some tests to compare hpack, qcram-03 and qcram-04. HolBs (%) hpack 850 100 qcram-03 27 3.2 qcram-04 46 5.4 HolBs here are requests that experienced Hol blocking. I think the main reason -04 doesn't degrade to HPACK is that there are quite a lot of requests that do no updates. Note that the indexing strategy doesn't index :path. Additional details: The har was a facebook of my own. I got it from chrome, using developer tools For reference it has 299 requests, and 167955 uncompressed header bytes. The table maxed out at 38 entries (same for all runs). The HolBs above are totals over 10 runs of each scheme. I ran multiple times to smooth variation due to the randomization of the simulator. I set the simulator loss rate of 0.35, which may be insanely high, but it stresses HoL Blocking. On Wed, Jan 24, 2018 at 9:06 AM, Kazuho Oku wrote: > Hi, > > Thank you for the response. > > 2018-01-25 3:44 GMT+11:00 Charles 'Buck' Krasic : > >> >> >> On Wed, Jan 24, 2018 at 7:27 AM, Kazuho Oku wrote: >> >>> 2018-01-24 23:10 GMT+11:00 Jana Iyengar : >>> > >>> > The draft outlines what I think the room converged on, and it seems >>> fairly straightforward -- thanks for the quick turnaround! >>> > >>> > Kazuho: I could be wrong, so Buck or Mike should correct me if so, bu= t >>> I believe the "Base Index" is basically what I think of as the "generat= ion >>> ID" of the table. It reflects the number of table operations that have >>> happened... this is important when you have evictions, since just a >>> reference to the largest index is ambiguous if there have been eviction= s. >>> >>> Jana, thank you for the response. >>> >>> Please correct me if I am wrong, but the below is my understanding. >>> >>> Modifications to the HPACK state only happens on the Control Stream. >>> So we do not need to rely on the index to determine how the state >>> needs to be changed. >>> >> >> Great point. The prefix is not needed for the modifications to HPACK >> state, i.e. for the blocks delivered on the Control Stream. >> >> >>> >>> For HEADERS frames sent over non-control streams, the only information >>> that the decoder needs is the absolute indices of the header table, >>> which can be encoded as largest_index (or whatever you call) plus the >>> deltas. >>> >>> > >>> > >>> > I don't understand however how the largest index is "Base Index - >>> Depends". I would've thought the largest index would simply be "Depends= ". >>> What am I missing? >>> >> >> Alan F. also made a similar point. >> >> Base index is for interpreting indexed representations correctly >> regardless of re-ordering. It is basically the total number of insertio= ns >> that happened before the current block has processed. >> >> Depends is for ensuring that the decoder blocks if necessary to wait for >> table updates the current block depends on. >> >> The 'Base Index - Depends' is poorly written and needs an example, sorry >> about that. The point I was trying (badly) to make was that depends is >> encoded relative to Base Index so that it's size stays bounded, it's jus= t >> an optimization to save bytes for the case of very long lived connection= s. >> Note that Base Index does not have such bound right now. Maybe a change= to >> specify wrap-around might be a reasonable way to also bound Base Index. >> >> Alternatively, and maybe this is what you just said (?), the two could b= e >> combined into one number. >> > > Yes. That is what I have been thinking of. > > >> I think that is tricky because one does not naturally know "depends" yet >> while emitting indexed entries. >> > > I think that the encoder needs to do a two-pass operation regardless of i= f > we encode two numbers (i.e. base_index, depends) or just one. This is > because since base_index and depends cannot be determined until the encod= er > iterate through all the headers. > > So to me it seems that it is not tricker for an encoder to use an unified > value; in the first pass the encoder determines the absolute index, and > then in the second pass emit the unified "base index" plus the deltas. > > >> It could be in practice that either the depends flag is false, or it >> is true and the Depends value is the same as Base Index. This was >> definitely not true with QCRAM-03, but it might well be with QCRAM-04. >> That's what I hope to sort out ASAP with updates to the simulator. =F0= =9F=A4=94 >> > > I understand that it's hard to update all the related code as we adjust > the approach. Thank you for your efforts! > > >> >> >> >> >> >>> > >>> > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku >>> wrote: >>> >> >>> >> Buck, >>> >> >>> >> Thank you for the draft. >>> >> >>> >> I like the approach and I think that it is not difficult to implemen= t. >>> >> >>> >> Reading the spec, the question I have is why you need the BLOCKING >>> flag and two variables (i.e. base index and depends). Can't each HEADER= S >>> frame always hold just one offset (i.e. largest index that the frame re= fers >>> to)? >>> >> >>> >> Maybe I am missing something. >>> >> >>> >> >>> >> 2018-01-24 16:53 GMT+11:00 Mike Bishop : >>> >>> >>> >>> Buck has posted an updated QCRAM draft at >>> https://tools.ietf.org/html/draft-krasic-quic-qcram-04 -- please read >>> before tomorrow=E2=80=99s meeting so we can have a useful discussion. = Thanks! >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> Kazuho Oku >>> > >>> > >>> >>> >>> >>> -- >>> Kazuho Oku >>> >> >> >> >> -- >> Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 >> (408) 412-1141 <(408)%20412-1141> >> >> > > > -- > Kazuho Oku > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --94eb2c068686c268e70563a01d29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I've gotten the simulator working with QCRAM -04 chang= es, specifically the part that moves all updates to the control stream.
    I ran some tests to compare hpack, qcram-03 and qcram-04.= =C2=A0 =C2=A0=C2=A0


    =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0HolBs=C2=A0 =C2=A0 = =C2=A0(%)
    hpack=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0850=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0100
    qcram-03=C2=A0 =C2=A027=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 3.2
    qcram-04=C2=A0 =C2=A046=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 5.4

    HolBs here are requests that experienced Hol blocking.
    <= /div>

    I think the main reason -0= 4 doesn't degrade to HPACK is that there are quite a lot of requests th= at do no updates.=C2=A0 =C2=A0Note that the indexing strategy doesn't i= ndex :path.=C2=A0 =C2=A0=C2=A0

    Additional = details:

    Th= e har was a facebook of my own.=C2=A0 I got it from chrome, using developer= tools For reference it has 299 requests, and 167955 uncompressed header by= tes.

    The table maxed out at 3= 8 entries (same for all runs).

    The HolBs above are totals over 10 runs of each sch= eme.=C2=A0 I ran multiple times to smooth variation due to the randomizatio= n of the simulator.

    I set the simulator= loss rate of 0.35, which may be insanely high, but it stresses HoL Blockin= g.








    <= div class=3D"gmail_extra">
    On Wed, Jan 24, 20= 18 at 9:06 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:
    =
    Hi,=C2=A0
    Thank you for the response.

    =
    2018-01-25 3:44 GMT+11:00= Charles 'Buck' Krasic <ckrasic@google.com>:


    On Wed, Jan 24, 2018 at 7:27 AM, K= azuho Oku <kazuhooku@gmail.com> wrote:
    2018-01-24 23:10 GMT+11:00 Jana Iyengar <jri@google.com>:
    >
    > The draft outlines what I think the room converged on, and it seems fa= irly straightforward -- thanks for the quick turnaround!
    >
    > Kazuho: I could be wrong, so Buck or Mike should correct me if so, but= I believe the "Base Index" is basically what I think of as the &= quot;generation ID" of the table. It reflects the number of table oper= ations that have happened... this is important when you have evictions, sin= ce just a reference to the largest index is ambiguous if there have been ev= ictions.

    Jana, thank you for the response.

    Please correct me if I am wrong, but the below is my understanding.

    Modifications to the HPACK state only happens on the Control Stream.
    So we do not need to rely on the index to determine how the state
    needs to be changed.

    Great point= .=C2=A0 The prefix is not needed for the modifications to HPACK state, i.e.= for the blocks delivered on the Control Stream.
    =C2=A0

    For HEADERS frames sent over non-control streams, the only information
    that the decoder needs is the absolute indices of the header table,
    which can be encoded as largest_index (or whatever you call) plus the
    deltas.

    >
    >
    > I don't understand however how the largest index is "Base Ind= ex - Depends". I would've thought the largest index would simply b= e "Depends". What am I missing?
    =
    Alan F.=C2=A0 also made a similar point.
    Base index is for interpreting indexed representations correct= ly regardless of re-ordering.=C2=A0 It is basically the total number of ins= ertions that happened before the current block has processed.
    Depends is for ensuring that the decoder blocks if necessary to= wait for table updates the current block depends on.=C2=A0=C2=A0

    The 'Base Index - Depends' is poorly written and ne= eds an example, sorry about that.=C2=A0 =C2=A0The point I was trying (badly= ) to make was that depends is encoded relative to Base Index so that it'= ;s size stays bounded, it's just an optimization to save bytes for the = case of very long lived connections.=C2=A0 Note that Base Index does not ha= ve such bound right now.=C2=A0 Maybe a change to specify wrap-around=C2=A0 = might be a reasonable way to also bound Base Index.

    Alternatively, and maybe this is what you just said (?), the two could be= combined into one number.

    Yes. That is what I have been thinking of.
    =C2=A0
    I think that is tricky because one= does not naturally know "depends" yet while emitting indexed ent= ries.

    I thin= k that the encoder needs to do a two-pass operation regardless of if we enc= ode two numbers (i.e. base_index, depends) or just one. This is because sin= ce base_index and depends cannot be determined until the encoder iterate th= rough all the headers.

    So to me it seems that it i= s not tricker for an encoder to use an unified value; in the first pass the= encoder determines the absolute index, and then in the second pass emit th= e unified "base index" plus the deltas.
    =C2=A0
    =
    =C2=A0 =C2=A0 It could be in practice that = either the depends flag is false, or it is true and the Depends value is th= e same as Base Index.=C2=A0 =C2=A0This was definitely not true with QCRAM-0= 3, but it might well be with QCRAM-04.=C2=A0 =C2=A0 That's what I hope = to sort out ASAP with updates to the simulator.=C2=A0=F0=9F=A4=94

    I understand that it&= #39;s hard to update all the related code as we adjust the approach. Thank = you for your efforts!




    =C2=A0
    >
    > On Wed, Jan 24, 2018 at 8:11 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
    >>
    >> Buck,
    >>
    >> Thank you for the draft.
    >>
    >> I like the approach and I think that it is not difficult to implem= ent.
    >>
    >> Reading the spec, the question I have is why you need the BLOCKING= flag and two variables (i.e. base index and depends). Can't each HEADE= RS frame always hold just one offset (i.e. largest index that the frame ref= ers to)?
    >>
    >> Maybe I am missing something.
    >>
    >>
    >> 2018-01-24 16:53 GMT+11:00 Mike Bishop <mbishop@evequefou.be>:
    >>>
    >>> Buck has posted an updated QCRAM draft at https://tools.ietf.org/html/draft-krasic-quic-qcram-04 --= please read before tomorrow=E2=80=99s meeting so we can have a useful disc= ussion.=C2=A0 Thanks!
    >>
    >>
    >>
    >>
    >> --
    >> Kazuho Oku
    >
    >



    --
    Kazuho Oku



    --
    C= harles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1



    --
    Kazuho Oku


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

    --94eb2c068686c268e70563a01d29-- From nobody Thu Jan 25 14:10:54 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9B5129C6F for ; Thu, 25 Jan 2018 14:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_zoiakx-M5G for ; Thu, 25 Jan 2018 14:10:51 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::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 F2B9212EAC2 for ; Thu, 25 Jan 2018 14:10:50 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c2so23188883qtn.9 for ; Thu, 25 Jan 2018 14:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=GGA3VuErKEMrj5/c4X+lzSoS+gRE+Cxmz13KXrKpTAw=; b=jEf1kbR1GW4O4Pe8wZe6eWL85zOVd6ybQiQ8o09lkPRRcFGQVRAybVHaZCjz8r7iyZ DBkSgbBF5JS9HRjEwCc9yqf7JhWfRGINvmLYOLF0Pj/bqzwdFiPOY/OzPbuGrroX4WWQ Z+JC/u3LWNGofOTYTIWUA4wPg/60zr/hNklHutq0uYEljjZZM1xSWraK14XzQgVjDIgS zHu+4EIkkOzjwbvTesywRJWKApDx0JgYjVe+CRlpfrFRF/SWY3wW65Ww39yrB+T5e2pH HNUTLN3rrXaRUkWmSsSNhdwZ66PZ9LipTkBM2eL/8/DrflO9xKJU4a81Ineexmg45bs1 AzSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=GGA3VuErKEMrj5/c4X+lzSoS+gRE+Cxmz13KXrKpTAw=; b=sZR0QbeOH0YGU5DExZFPsoPMXfTZXwSugsaoRQbXoQe4+t7R2OV3ovwFCbBaasfpyO NXaTQ42Jt2dV3J2rdtJFWslEy1ychgwt3GGoTQZ/K1HTX2zuNH3H5+bXlbzipsWT0Xah 28I3FaxUK5RafAaJSXNRPL3vfd2v+WL2WNU2zip+z4Tt1Q6SDBKGm9fZOB/WRXSwsMYJ Om8W1MCW3RxthPvvvy7Konoe93zrl3eH8pbTY/GMJWJTpckM8ho4NxJFwcx91VohcPvG mLUrJ6Y/VGmKxLzroTpG9HXWjdHVz1fBzuRwaHIUfVSJqn8lpReYlBM1udXpX9uaXMsn mMRA== X-Gm-Message-State: AKwxytf4Wjf7nEbrHKUouIjVKNO6HcuONWiTDlEMnG65k17aZpVSXOsq Pk7iPdlRkkAKLBvzvy5Sz2zsVQ== X-Google-Smtp-Source: AH8x225HZ0RnlvIIHKQVH0mvY8SzvDpEljPcQtc8o23ESye3yzNVVeaZP+MWJicE4mEhUebt2R0YVA== X-Received: by 10.55.93.194 with SMTP id r185mr17187086qkb.109.1516918250167; Thu, 25 Jan 2018 14:10:50 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id m123sm2443341qkd.55.2018.01.25.14.10.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 14:10:49 -0800 (PST) Date: Thu, 25 Jan 2018 17:10:45 -0500 From: Dmitri Tikhonov To: Charles 'Buck' Krasic Cc: Kazuho Oku , Jana Iyengar , IETF QUIC WG , Mike Bishop Subject: Re: Updated QCRAM Draft Message-ID: <20180125221044.GA32273@ubuntu-dmitri> Mail-Followup-To: Charles 'Buck' Krasic , Kazuho Oku , Jana Iyengar , IETF QUIC WG , Mike Bishop References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2018 22:10:53 -0000 On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck' Krasic wrote: > I ran some tests to compare hpack, qcram-03 and qcram-04. > > HolBs (%) > hpack 850 100 > qcram-03 27 3.2 > qcram-04 46 5.4 > > HolBs here are requests that experienced Hol blocking. ---8<---- > The har was a facebook of my own. I got it from chrome, using developer > tools For reference it has 299 requests, and 167955 uncompressed header > bytes. I am sure I misunderstand something: - How can the number of requests that experienced HoL blocking (850) be larger than the total number of requests (299)? - What does the percentage column (100, 3.2, 5.4) represent? - Dmitri. From nobody Thu Jan 25 14:12:16 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26041129C6F for ; Thu, 25 Jan 2018 14:12:15 -0800 (PST) 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 UrG6ZCsUXhy2 for ; Thu, 25 Jan 2018 14:12:13 -0800 (PST) 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 9ADFA12785F for ; Thu, 25 Jan 2018 14:12:11 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eepkM-0001Ix-It for quic@ietf.org; Thu, 25 Jan 2018 23:12:00 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eepk8-0006Zu-2K for quic@ietf.org; Thu, 25 Jan 2018 17:11:40 -0500 Received: (qmail 19636 invoked from network); 25 Jan 2018 22:11:28 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2018 22:11:27 -0000 To: "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" , "Brian Trammell (IETF)" References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> Cc: Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" From: Christian Huitema Message-ID: <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> Date: Thu, 25 Jan 2018 12:11:25 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tOw5WUfdgStRtio7EYuzuMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fujfEwooQGsyHv+Ukxjc4utB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUzVo6xqsY8KGF50vY/LmgeTZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPrkOnOitmVlVGEmCCKMSX xNRF78A7vHpiSb+8Z8tEBsQHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFirtlAtdsrBTAcAoY5WeLmsibYT4C2qF2lnc18bVJn67/ u9fgYp7Ebu762M62YItjO3Oj1h9z38gFDN/+Ro0+DDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTvLpZVaBCgo9IFgw1OrNwYFjI1dRH6f16eQCtvwPkeoxzBkc1CTpvaEJjkrbHF6v+l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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, 25 Jan 2018 22:12:15 -0000 On 1/25/2018 12:10 AM, De Schepper, Koen (Nokia - BE/Antwerp) wrote: > Some questions related to the remark of Christian: "We are heading towa= rds a single packet sequence number space shared by multiple paths" > What is the rationale behind this? > Is the reason for this that there are currently no per path states/comm= unications required? (because congestion control is currently out of scop= e, and it is currently the only per path processing required). In that ca= se I understand why the current design of QUIC is optimizing itself towar= ds application to application state, but we must make sure we don't make = our live difficult if we have per connection state (when it is needed, li= ke congestion control). This is related to encryption options for multipath. I explained the design choices in https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-req/. AEAD encryption requires that sequence numbers do not repeat for a given encryption context. For multipath, this requirement can be met by either having separate encryption contexts per path, or having a single encryption context for all paths and using the same sequence number space for every paths. This is also a requirement when multiple paths are used for connection migration. We had that discussion in Melbourne, and the sense of the room was clearly that having separate encryption contexts per paths was too complicated. Having a single sequence number space and a single encryption context is significantly simpler. There is a privacy issue, linkability via the sequence numbers, but that privacy issue can be addressed by encrypting the sequence numbers, and we pretty much agreed to do that. Hence my statement that "We are heading towards a single packet sequence number space shared by multiple paths". Of course we still need to maintain per path variables for RTT, PMTU and congestion control. As long as we only support migration, that could be finessed somewhat by resetting these variables to their initial state at the end of the migration. But when we do true multipath, there will be a need to associate congestion control signals with paths. If we have a single sequence number, the way to do that is to maintain associations between packets and path, e.g. having a path tag in the packet copy kept for retransmission purposes. That's sufficient for signals like ACK or losses, but it requires that ECN signals be tied to specific packets. -- Christian Huitema From nobody Thu Jan 25 14:53:47 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9860A12EAE3 for ; Thu, 25 Jan 2018 14:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vieOXk3sz96l for ; Thu, 25 Jan 2018 14:53:45 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 28F7012EAD9 for ; Thu, 25 Jan 2018 14:53:43 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id v5so8557366oth.5 for ; Thu, 25 Jan 2018 14:53:43 -0800 (PST) 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; bh=hniiXtuTqNPqa6ftNKt6V9aEHvzff385rJ5H1qXYmBg=; b=Q8izw8j8bDJT7diS2aRNuO3PwJh84c60GUmwDvLpkx97MKwwJmJR294eSW88+nJeiH UuFU2Mw3LyBcCRI0I4TWKYOVnm1EZzbY+7IqT2UHgK0nQy44a/87fnSFLtAVBlI5ogXk gluuUbW0j/pKsliQkQ7OHdpj6NYzYrb7R3qYe4+F3bIEri0Y1K6717iliyXB7wR9wBCx 06K3p4pQ6Y5forAFQoaEYVscscNyUyDYkU56LVLpNfftSWx/6Y0c+Tg1oCB2FWxb0kvU wjWAkYkMAP80ChKXjXNr1Hk3O2P/HDtjOIk/NGommfRKp8W6QHBuL65wS1hbSuUITVZ6 8A4g== 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=hniiXtuTqNPqa6ftNKt6V9aEHvzff385rJ5H1qXYmBg=; b=ARBKKVknyzvOovAD8OfZAPeXxfd86jJ5eSwbcSwUjE8BHO4wQ3xuOesIiN2cPimwvp ABaAViezC4meXPHwo7AjHnUD/9q3H2bZJP6oRH9xmk3LBBptwjPvxrfMBL1ux0+0J9aI 1v53KIxR8NbVYNW/+7QNzR0FdL78kZqBkaRELj0uqUTdSEPdEzQ75FhkrfLYBWuacP1/ +k9Gfh4t24lXuL/xOOYu1qb2H7htXo2g817t+7gC6c0cHNAhIBEqUlXbrSkgZ3iYlpx+ ucPGXVhMedibWnhAZ7JjxJoWErhlgSraqfCEBqWq+qRHMw/nhJ9akba6zspTcsU96Bxu lJsQ== X-Gm-Message-State: AKwxytcGDuXiVVs7Y2n7kulU/3zJg3mhNrG59MNXcWW4TirV3sovCOmB fOdJBC0r/fYbG8abvkcZ/0zmZn0WuWbuFP9emcim X-Google-Smtp-Source: AH8x226PjwLFLRZ65hvul8Pt6og80shNYLhjqwQAcbNO42DLbxrU8qWtuBZU6JoRp95SXkKYc6BA1ctMOqhPohJm0jE= X-Received: by 10.107.188.65 with SMTP id m62mr6864229iof.39.1516920822100; Thu, 25 Jan 2018 14:53:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.156.203 with HTTP; Thu, 25 Jan 2018 14:53:21 -0800 (PST) In-Reply-To: <20180125221044.GA32273@ubuntu-dmitri> References: <20180125221044.GA32273@ubuntu-dmitri> From: "Charles 'Buck' Krasic" Date: Thu, 25 Jan 2018 14:53:21 -0800 Message-ID: Subject: Re: Updated QCRAM Draft To: "Charles 'Buck' Krasic" , Kazuho Oku , Jana Iyengar , IETF QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="94eb2c073c20c198ef0563a1a602" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Jan 2018 22:53:47 -0000 --94eb2c073c20c198ef0563a1a602 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 25, 2018 at 2:10 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck' Krasic wrote: > > I ran some tests to compare hpack, qcram-03 and qcram-04. > > > > HolBs (%) > > hpack 850 100 > > qcram-03 27 3.2 > > qcram-04 46 5.4 > > > > HolBs here are requests that experienced Hol blocking. > > ---8<---- > > > The har was a facebook of my own. I got it from chrome, using developer > > tools For reference it has 299 requests, and 167955 uncompressed header > > bytes. > > I am sure I misunderstand something: > > - How can the number of requests that experienced HoL > blocking (850) be larger than the total number of > requests (299)? > > It is a total over ten runs. > - What does the percentage column (100, 3.2, 5.4) represent? > Just normalizing qcram-* against HPACK. E.g. for qcram-03, 27/850 = 3.2%. > > - Dmitri. > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --94eb2c073c20c198ef0563a1a602 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Thu, Jan 25, 2018 at 2:10 PM, Dmitri Tikhonov <= dtikhonov@= litespeedtech.com> wrote:
    <= span class=3D"">On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck= ' Krasic wrote:
    > I ran some tests to compare hpack, qcram-03 and qcram-04.
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HolBs=C2=A0 =C2=A0 =C2= =A0(%)
    > hpack=C2=A0 =C2=A0 =C2=A0 =C2=A0850=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01= 00
    > qcram-03=C2=A0 =C2=A027=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3.2 > qcram-04=C2=A0 =C2=A046=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5.4 >
    > HolBs here are requests that experienced Hol blocking.

    ---8<----

    > The har was a facebook of my own.=C2=A0 I got it from chrome, using de= veloper
    > tools For reference it has 299 requests, and 167955 uncompressed heade= r
    > bytes.

    I am sure I misunderstand something:

    - How can the number of requests that experienced HoL
    =C2=A0 blocking (850) be larger than the total number of
    =C2=A0 requests (299)?

    It is a total over ten runs.=C2=A0
    =C2=A0
    - What does the percentage column (100, 3.2, 5.4) represent?

    Just normalizing qcram-* against HPACK.=C2=A0 =C2=A0E= .g.=C2=A0 for qcram-03, 27/850 =3D 3.2%.=C2=A0

    =C2=A0 - Dmitri.



    --
    = Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-114= 1

    --94eb2c073c20c198ef0563a1a602-- From nobody Thu Jan 25 22:35:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1101312704A for ; Thu, 25 Jan 2018 22:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrvX5Av6uTrq for ; Thu, 25 Jan 2018 22:35:32 -0800 (PST) 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 9F53E126C2F for ; Thu, 25 Jan 2018 22:35:32 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eexbh-0000jN-Ku for quic@ietf.org; Fri, 26 Jan 2018 07:35:31 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eexba-0008SF-Ex for quic@ietf.org; Fri, 26 Jan 2018 01:35:22 -0500 Received: (qmail 24729 invoked from network); 26 Jan 2018 06:35:16 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jan 2018 06:35:16 -0000 To: Subodh Iyengar , Victor Vasiliev , IETF QUIC WG References: From: Christian Huitema Message-ID: Date: Thu, 25 Jan 2018 20:35:13 -1000 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="------------8D283CBAC2EF9592BDF84A66" Subject: Re: Mechanism for negotiating extensions X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.50) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rbrKJpT8hFeqD35NhbzbLEXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKUEn7OhK4I76mJkzllf+AB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XsxRC3Cl5agFgis4e3pTrPTmWL20QDaTB8w3xrEB2b t3OtYGxixLxoF7CSToMKY9MHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFirtlAtdsrBTAcAoY5WeLmsibYT4C2qF2lnc18bVJn66J 5H8GEBf1HjtQxaaLw1oLoz28fPEL/KhwPy3TmHj0kDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTvLpZVaBCgo9IFgw1OrNwYFjI1dRH6f16eQCtvwPkeoxzBkc1CTpvaEJjkrbHF6v+l1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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, 26 Jan 2018 06:35:35 -0000 This is a multi-part message in MIME format. --------------8D283CBAC2EF9592BDF84A66 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit I personally agree that a mapping mechanism makes sense. RTP/SDP ended up using a similar mechanism for the RTP media types, and that seems to have worked well. In fact, I proposed something similar in a comment to MT's extension proposal: Reserve a small number of extension frame types in the "frame type" space. Create a transport parameter option in which the client says "I want to use reserved frame type X to do XYZT". Server acknowledges with corresponding option, "Let's use frame type X to do XYZT". XYZT is a four letter acronym reserved in a Wiki. Victor, why don't you submit a PR, so we can have a discussion on the details? -- Christian Huitema On 1/25/2018 10:09 AM, Subodh Iyengar wrote: > > Alternatively, could we say that "You MUST not use extension frames in > IETF QUIC versions", i.e. if you want to use a extension frame, you > should have your own version of QUIC. > > > This makes extension frames less useful for IETF QUIC versions, but > private experimental QUIC versions do not have to rev that often, > which is super valuable as well. > > > Subodh > > ------------------------------------------------------------------------ > *From:* QUIC on behalf of Victor Vasiliev > > *Sent:* Thursday, January 25, 2018 8:34:24 AM > *To:* IETF QUIC WG > *Subject:* Mechanism for negotiating extensions > > I've been thinking about extension negotiation, and I'm not entirely > sure that "just put a transport parameter per extension" is a > sufficiently complete answer. There are at least two problems in > extending QUIC that we ought to address. > > The first problem is that the frame type field is only one byte long. > While this is enough for any single QUIC connection, if we try to > allocate those globally in a non-conflicting manner, we might exhaust > it sooner than we think (also, this would require coordinating two > extensions to be compatible). Thus, I believe we should to add a > general mechanism where every extension, when negotiated, would > specify which frame type numbers it's using on the wire for each > frame, so that this number allocation can be performed on > per-connection basis. I believe there are mechanisms similar to that > in other protocols (e.g. RTP does something like that in RFC 8285). > > The second problem is that the client list of offered extensions is > not protected by secure keys. I am not sure how much of an issue this > is in terms of ossification -- I don't remember off the top of my head > where it caused problems in TLS /per se/, and inventing a completely > new mechanism for it will surely run into a set of issues. Still, > it's worth discussing. > > If people believe that the mapping proposal is valuable, I can write > up a PR for this. --------------8D283CBAC2EF9592BDF84A66 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

    I personally agree that a mapping mechanism makes sense. RTP/SDP ended up using a similar mechanism for the RTP media types, and that seems to have worked well. In fact, I proposed something similar in a comment to MT's extension proposal: Reserve a small number of extension frame types in the "frame type" space. Create a transport parameter option in which the client says "I want to use reserved frame type X to do XYZT". Server acknowledges with corresponding option, "Let's use frame type X to do XYZT". XYZT is a four letter acronym reserved in a Wiki.


    Victor, why don't you submit a PR, so we can have a discussion on the details?


    -- Christian Huitema


    On 1/25/2018 10:09 AM, Subodh Iyengar wrote:

    Alternatively, could we say that "You MUST not use extension frames in IETF QUIC versions", i.e. if you want to use a extension frame, you should have your own version of QUIC.


    This makes extension frames less useful for IETF QUIC versions, but private experimental QUIC versions do not have to rev that often, which is super valuable as well.


    Subodh

    From: QUIC <quic-bounces@ietf.org> on behalf of Victor Vasiliev <vasilvv@google.com>
    Sent: Thursday, January 25, 2018 8:34:24 AM
    To: IETF QUIC WG
    Subject: Mechanism for negotiating extensions
     
    I've been thinking about extension negotiation, and I'm not entirely sure that "just put a transport parameter per extension" is a sufficiently complete answer.  There are at least two problems in extending QUIC that we ought to address.

    The first problem is that the frame type field is only one byte long.  While this is enough for any single QUIC connection, if we try to allocate those globally in a non-conflicting manner, we might exhaust it sooner than we think (also, this would require coordinating two extensions to be compatible).  Thus, I believe we should to add a general mechanism where every extension, when negotiated, would specify which frame type numbers it's using on the wire for each frame, so that this number allocation can be performed on per-connection basis.  I believe there are mechanisms similar to that in other protocols (e.g. RTP does something like that in RFC 8285).

    The second problem is that the client list of offered extensions is not protected by secure keys.  I am not sure how much of an issue this is in terms of ossification -- I don't remember off the top of my head where it caused problems in TLS per se, and inventing a completely new mechanism for it will surely run into a set of issues.  Still, it's worth discussing.

    If people believe that the mapping proposal is valuable, I can write up a PR for this.

    --------------8D283CBAC2EF9592BDF84A66-- From nobody Thu Jan 25 23:44:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460E712D871 for ; Thu, 25 Jan 2018 23:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 Xsa0z7ivyHM1 for ; Thu, 25 Jan 2018 23:44:18 -0800 (PST) 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 722A312D860 for ; Thu, 25 Jan 2018 23:44:18 -0800 (PST) X-AuditID: c1b4fb25-48bff7000000341b-2b-5a6adc50372d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id E4.EB.13339.05CDA6A5; Fri, 26 Jan 2018 08:44:16 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 26 Jan 2018 08:44:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CSo7z3DYvIG9dV/Zn9vgAf1PqbKgSiQsIjBQDINY9OI=; b=YECdy0beUqPMNA+RhV4pyVEiWUPGgrZzTPW4V5DCRmPVCl+BwcFoizZ7cG9nEauo/fwGzKpblkNhrUXVPKwQxbQf/fXI3UP4wvCCNpoeDrZLvgiVnyUbyLWEl5VquPKIL2Gwi5feoZwru3lw7BfzY0AZnQfW+7WuuTL/uVYLvvE= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3644.eurprd07.prod.outlook.com (52.133.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 26 Jan 2018 07:44:14 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::8468:8225:cde3:850c%13]) with mapi id 15.20.0444.016; Fri, 26 Jan 2018 07:44:14 +0000 From: Ingemar Johansson S To: Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" , "Brian Trammell (IETF)" CC: QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1AAAsI1AAACpr+AAA8DdQAAAO0UgAAGEbDQABrQR4AAE461EA== Date: Fri, 26 Jan 2018 07:44:13 +0000 Message-ID: References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> In-Reply-To: <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3644; 7:XVmj0txXnjcWadkbz4dJX/RbeX/lCnqrf98vlQGWeIMQXqehfkNux6qaSMK6dve7JtPPqoN4rpuU+z/L+t0tjHmGZUPEOzOT5t4/qRewgLIFPhZC4tX4QrxGYBkO9Nee4qZPl98IPUwQW1MkfS8RCuhW9Bep/SJ9VgEpHHaw244zcT31KZH/bhF1UIWC8mwMtz896w0YkFbFrMQQeVxnAho3kYlk9hygGoeDzJS+EBq1kpkBTIVwgUQqi0HLXHBD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1e29f41a-6780-4423-b1bf-08d56490988b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3644; x-ms-traffictypediagnostic: HE1PR0702MB3644: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231023)(2400081)(944501161)(3002001)(10201501046)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0702MB3644; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3644; x-forefront-prvs: 05641FD966 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39380400002)(39860400002)(346002)(376002)(366004)(13464003)(199004)(189003)(86362001)(33656002)(66066001)(102836004)(5660300001)(7116003)(2906002)(316002)(2950100002)(53546011)(6506007)(76176011)(59450400001)(3846002)(6116002)(74316002)(305945005)(7736002)(14454004)(93886005)(478600001)(966005)(97736004)(186003)(26005)(68736007)(99286004)(110136005)(54906003)(81156014)(8676002)(55016002)(3480700004)(8936002)(81166006)(53936002)(9686003)(6306002)(6436002)(229853002)(2900100001)(105586002)(106356001)(25786009)(7696005)(4326008)(3280700002)(3660700001)(6246003)(5250100002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3644; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: O6u+5O7yA9xIS5wecOLUNfX3/+sJ9fKRi1ayRnRUtOvTfXDRraezxsxrZAtHOqo77vUqHbRXjwiNnn959W9DBA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1e29f41a-6780-4423-b1bf-08d56490988b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2018 07:44:13.8590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3644 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffe3V2Xq7Ol+WSJNbLUfOvlwwjJ/OTEBC1BG4EuvTjnnLaZ aGHYMDLNcGo2zbdqaQaRiamZZM4QX4rCJHBKZpqyMikxRyXRbndB337P//yf8z/Pw2FIaZvA m8nQ5bJ6nUoro0VUbVJ3RHDctEYZ1mINkldduCGUPyxepuXGorukfGjtDiG/0rxBPltjREdo RdXzZlLxaea1QGEzj1IKi+UHoTCu3aIV8/21VBytFIWnsdqMPFYfejhFpP5sNKEcS2D+RJGd LkLmgFLkxgA+CPdnq+lSJGKkeBBByTcHxRfDCPrrloVcQeEVAswViwTXIsU1BHwdk/C8iGCx XcgxjcOhzepAHHvgCQSV9RqOSZwCJtMkxfFmDNA8VEnwnq2wvHqR4lkDFY6rAo4p7Acll/v/ 6mJn782ldpLPKhHA7T4nM4wbjoDxpihORtgHZhzvKD7KC2zzTQQ/GQZL3yuSZ0+wz/0W8P5U WJksF/D6Dlgf/0Dz7OO8sgzx3EVAb1khzyHwyPTFpceCo+q6gNsJ4FEExqlKV1gQWJ/YKJ6z Yc0+JeT5JMw1XEN8Qz0Ji9PDLtN2sHfZqAoUWvffw+ucs5E4AB70uuSdUF02K6z7uwoJjNTO U82Iuoc8DazhVFb6/gMhrD4j1WDI1oXo2NwO5PxAA52//HrQm6VIK8IMkrmLA7s0SqlAlWco yLIiYEiZh1gS7JTEaaqCs6w+O1l/RssarGgbQ8m8xCPRYqUUp6ty2UyWzWH1/04Jxs27CO3F MT3K9Bf1Af5h6gL/456D0gly9VLmiaTGhF2NvguP1b7PNKdtC9+7pYnrW0bHugYCYuyp+a0W ydvI6E3Cwigfv8Lo2fz4RFPn7vM/y/MbWhVae6wm/qX7xrTijqfn5mzv96gTgtvyFmQfjw4l H6KTSrSS9jWzutXaAlF5xxwyyqBW7Qsk9QbVHy5I37Y8AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 26 Jan 2018 07:44:21 -0000 SGkNCg0KSSBiZWxpZXZlIHRoYXQgSSBzdGFydCB0byB1bmRlcnN0YW5kIHRoZSBpc3N1ZS4gU3Rp bGwgSSBkb24ndCBiZWxpZXZlIHRoYXQgaXQgaXMgYW55IHByb2JsZW0gd2l0aCB1c2luZyBwYWNr ZXQgY291bnRlcnMuIEFzIEtvZW4gcG9pbnRlZCBvdXQgaXQgY2FuIHNpbXBsaWZ5IHByb2Nlc3Np bmcgYW5kIHRoaXMgd2FzIGFsc28gc3RhdGVkIHdoZW4gdGhpcyBxdWVzdGlvbiB3YXMgcmFpc2Vk IG9uIHRoZSB0cmFja2VyIChzZWUgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0 cy9pc3N1ZXMvODA1ICkuDQoNCkFzc3VtaW5nIHRoYXQgd2UgdGFnIHdoaWNoIHBhY2tldCBnb2Vz IHdoZXJlIGl0IHdpbGwgYmUgcG9zc2libGUgdG8gdHJhY2sgaG93IG1hbnkgcGFja2V0cyB0aGF0 IGdvbmUgaW4gd2hpY2ggZGlyZWN0aW9uLiBBbHNvIHRoZSBFQ1QvQ0UgY291bnRlcnMgaW5kaWNh dGUgdGhlIGNvdW50IG9mIEVDVC9DRSBtYXJrZWQgcGFja2V0cyB3aGVuIHRoZSBwYWNrZXQgd2l0 aCB0aGUgaGlnaGVzdCBrbm93biBzZXF1ZW5jZSBudW1iZXIgaXMgcmVjZWl2ZWQuIFNvIGlmIHdl IGtlZXAgc2VwYXJhdGUgImNvbmdlc3Rpb24gY29udHJvbCBhbmQgdHJhbnNtaXNzaW9uIGxpc3Qi IGNvbnRleHQgZm9yIHRoZSBkaWZmZXJlbnQgcGF0aCB0aGVuIGl0IHNob3VsZCB3b3JrIGFuZCB0 aGUgY29ycmVjdCBjb25nZXN0aW9uIGNvbnRyb2wgd2lsbCBiZSBhY2hpZXZlZCByZWdhcmRsZXNz IGl0IGlzIEVDVCgwKSBvciBFQ1QoMSkgYmFzZWQgY29uZ2VzdGlvbiBjb250cm9sLg0KSXQgd2ls bCBhbHNvIGJlIHBvc3NpYmxlIHRvIGRldGVjdCBFQ04gYmxlYWNoIGFsb25nIG5ldyBwYXRocyB3 aXRoIHRoaXMuIA0KICANCi9JbmdlbWFyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogQ2hyaXN0aWFuIEh1aXRlbWEgW21haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0XQ0K PiBTZW50OiBkZW4gMjUgamFudWFyaSAyMDE4IDIzOjExDQo+IFRvOiBEZSBTY2hlcHBlciwgS29l biAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS0NCj4gYmVsbC1s YWJzLmNvbT47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQnJpYW4gVHJh bW1lbGwNCj4gKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPg0KPiBDYzogSW5nZW1hciBKb2hhbnNz b24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBRVUlDIFdHDQo+IDxxdWlj QGlldGYub3JnPjsgQm9iIEJyaXNjb2UgKHJlc2VhcmNoQGJvYmJyaXNjb2UubmV0KQ0KPiA8cmVz ZWFyY2hAYm9iYnJpc2NvZS5uZXQ+DQo+IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQw0KPiANCj4g T24gMS8yNS8yMDE4IDEyOjEwIEFNLCBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3 ZXJwKSB3cm90ZToNCj4gDQo+ID4gU29tZSBxdWVzdGlvbnMgcmVsYXRlZCB0byB0aGUgcmVtYXJr IG9mIENocmlzdGlhbjogIldlIGFyZSBoZWFkaW5nDQo+IHRvd2FyZHMgYSBzaW5nbGUgcGFja2V0 IHNlcXVlbmNlIG51bWJlciBzcGFjZSBzaGFyZWQgYnkgbXVsdGlwbGUgcGF0aHMiDQo+ID4gV2hh dCBpcyB0aGUgcmF0aW9uYWxlIGJlaGluZCB0aGlzPw0KPiA+IElzIHRoZSByZWFzb24gZm9yIHRo aXMgdGhhdCB0aGVyZSBhcmUgY3VycmVudGx5IG5vIHBlciBwYXRoDQo+IHN0YXRlcy9jb21tdW5p Y2F0aW9ucyByZXF1aXJlZD8gKGJlY2F1c2UgY29uZ2VzdGlvbiBjb250cm9sIGlzIGN1cnJlbnRs eQ0KPiBvdXQgb2Ygc2NvcGUsIGFuZCBpdCBpcyBjdXJyZW50bHkgdGhlIG9ubHkgcGVyIHBhdGgg cHJvY2Vzc2luZyByZXF1aXJlZCkuIEluDQo+IHRoYXQgY2FzZSBJIHVuZGVyc3RhbmQgd2h5IHRo ZSBjdXJyZW50IGRlc2lnbiBvZiBRVUlDIGlzIG9wdGltaXppbmcgaXRzZWxmDQo+IHRvd2FyZHMg YXBwbGljYXRpb24gdG8gYXBwbGljYXRpb24gc3RhdGUsIGJ1dCB3ZSBtdXN0IG1ha2Ugc3VyZSB3 ZSBkb24ndA0KPiBtYWtlIG91ciBsaXZlIGRpZmZpY3VsdCBpZiB3ZSBoYXZlIHBlciBjb25uZWN0 aW9uIHN0YXRlICh3aGVuIGl0IGlzIG5lZWRlZCwNCj4gbGlrZSBjb25nZXN0aW9uIGNvbnRyb2wp Lg0KPiANCj4gVGhpcyBpcyByZWxhdGVkIHRvIGVuY3J5cHRpb24gb3B0aW9ucyBmb3IgbXVsdGlw YXRoLiBJIGV4cGxhaW5lZCB0aGUgZGVzaWduDQo+IGNob2ljZXMgaW4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVpdGVtYS1xdWljLW1wYXRoLXJlcS8uDQo+IEFFQUQg ZW5jcnlwdGlvbiByZXF1aXJlcyB0aGF0IHNlcXVlbmNlIG51bWJlcnMgZG8gbm90IHJlcGVhdCBm b3IgYSBnaXZlbg0KPiBlbmNyeXB0aW9uIGNvbnRleHQuIEZvciBtdWx0aXBhdGgsIHRoaXMgcmVx dWlyZW1lbnQgY2FuIGJlIG1ldCBieSBlaXRoZXINCj4gaGF2aW5nIHNlcGFyYXRlIGVuY3J5cHRp b24gY29udGV4dHMgcGVyIHBhdGgsIG9yIGhhdmluZyBhIHNpbmdsZSBlbmNyeXB0aW9uDQo+IGNv bnRleHQgZm9yIGFsbCBwYXRocyBhbmQgdXNpbmcgdGhlIHNhbWUgc2VxdWVuY2UgbnVtYmVyIHNw YWNlIGZvciBldmVyeQ0KPiBwYXRocy4gVGhpcyBpcyBhbHNvIGEgcmVxdWlyZW1lbnQgd2hlbiBt dWx0aXBsZSBwYXRocyBhcmUgdXNlZCBmb3INCj4gY29ubmVjdGlvbiBtaWdyYXRpb24uDQo+IA0K PiBXZSBoYWQgdGhhdCBkaXNjdXNzaW9uIGluIE1lbGJvdXJuZSwgYW5kIHRoZSBzZW5zZSBvZiB0 aGUgcm9vbSB3YXMgY2xlYXJseQ0KPiB0aGF0IGhhdmluZyBzZXBhcmF0ZSBlbmNyeXB0aW9uIGNv bnRleHRzIHBlciBwYXRocyB3YXMgdG9vIGNvbXBsaWNhdGVkLg0KPiBIYXZpbmcgYSBzaW5nbGUg c2VxdWVuY2UgbnVtYmVyIHNwYWNlIGFuZCBhIHNpbmdsZSBlbmNyeXB0aW9uIGNvbnRleHQgaXMN Cj4gc2lnbmlmaWNhbnRseSBzaW1wbGVyLiBUaGVyZSBpcyBhIHByaXZhY3kgaXNzdWUsIGxpbmth YmlsaXR5IHZpYSB0aGUgc2VxdWVuY2UNCj4gbnVtYmVycywgYnV0IHRoYXQgcHJpdmFjeSBpc3N1 ZSBjYW4gYmUgYWRkcmVzc2VkIGJ5IGVuY3J5cHRpbmcgdGhlDQo+IHNlcXVlbmNlIG51bWJlcnMs IGFuZCB3ZSBwcmV0dHkgbXVjaCBhZ3JlZWQgdG8gZG8gdGhhdC4gSGVuY2UgbXkNCj4gc3RhdGVt ZW50IHRoYXQgIldlIGFyZSBoZWFkaW5nIHRvd2FyZHMgYSBzaW5nbGUgcGFja2V0IHNlcXVlbmNl IG51bWJlcg0KPiBzcGFjZSBzaGFyZWQgYnkgbXVsdGlwbGUgcGF0aHMiLg0KPiANCj4gT2YgY291 cnNlIHdlIHN0aWxsIG5lZWQgdG8gbWFpbnRhaW4gcGVyIHBhdGggdmFyaWFibGVzIGZvciBSVFQs IFBNVFUgYW5kDQo+IGNvbmdlc3Rpb24gY29udHJvbC4gQXMgbG9uZyBhcyB3ZSBvbmx5IHN1cHBv cnQgbWlncmF0aW9uLCB0aGF0IGNvdWxkIGJlDQo+IGZpbmVzc2VkIHNvbWV3aGF0IGJ5IHJlc2V0 dGluZyB0aGVzZSB2YXJpYWJsZXMgdG8gdGhlaXIgaW5pdGlhbCBzdGF0ZSBhdCB0aGUNCj4gZW5k IG9mIHRoZSBtaWdyYXRpb24uIEJ1dCB3aGVuIHdlIGRvIHRydWUgbXVsdGlwYXRoLCB0aGVyZSB3 aWxsIGJlIGEgbmVlZCB0bw0KPiBhc3NvY2lhdGUgY29uZ2VzdGlvbiBjb250cm9sIHNpZ25hbHMg d2l0aCBwYXRocy4gSWYgd2UgaGF2ZSBhIHNpbmdsZSBzZXF1ZW5jZQ0KPiBudW1iZXIsIHRoZSB3 YXkgdG8gZG8gdGhhdCBpcyB0byBtYWludGFpbiBhc3NvY2lhdGlvbnMgYmV0d2VlbiBwYWNrZXRz IGFuZA0KPiBwYXRoLCBlLmcuIGhhdmluZyBhIHBhdGggdGFnIGluIHRoZSBwYWNrZXQgY29weSBr ZXB0IGZvciByZXRyYW5zbWlzc2lvbg0KPiBwdXJwb3Nlcy4gVGhhdCdzIHN1ZmZpY2llbnQgZm9y IHNpZ25hbHMgbGlrZSBBQ0sgb3IgbG9zc2VzLCBidXQgaXQgcmVxdWlyZXMgdGhhdA0KPiBFQ04g c2lnbmFscyBiZSB0aWVkIHRvIHNwZWNpZmljIHBhY2tldHMuDQo+IA0KPiAtLSBDaHJpc3RpYW4g SHVpdGVtYQ0KPiANCj4gDQoNCg== From nobody Fri Jan 26 11:56:17 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610DB12DA14 for ; Fri, 26 Jan 2018 11:56:15 -0800 (PST) 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=CVrHQQNK; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=OpILCcTU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDq_XJy29f-q for ; Fri, 26 Jan 2018 11:56:13 -0800 (PST) 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 D0C0A12DA2C for ; Fri, 26 Jan 2018 11:56:13 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0QJrrLH019914; Fri, 26 Jan 2018 11:56:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=8qt9W+Vpx25nzRuSQ1qFTD8luHTkQuu0kChwKYbOuvA=; b=CVrHQQNKt1xCRlEnLO+wNM/ADZr8Bk0YEnZRIwlDCuJOPt4eJ2dnlFJAYbziEDenG+TU /ILE5/Epx5Osi7DTVn/vfYb9gGQF7bf/vvVo7SwDXA7hEVMostRQ2q2lEQfglYMvd7wA dQla5BFHf6bsexUoBNGJzRBydOsTdik9/eQ= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fr8t78bpw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 26 Jan 2018 11:56:08 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 26 Jan 2018 14:56:06 -0500 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=8qt9W+Vpx25nzRuSQ1qFTD8luHTkQuu0kChwKYbOuvA=; b=OpILCcTUcOB25UXD+J3wJHM48BJk8qjCCjhSV08LjuNgT8MVg8AolbvMMthHKWEEZz3OTOl/EihWMEdBtNVfMmW+kTgAyfJvkO3UFNjxrO1upVC0jyAm4yvlxsgk2ScnJsGl1uvON0imdgK3fgqP3hEOr5WsXpzDR4CiyGM9DA0= Received: from DM5PR1501MB2183.namprd15.prod.outlook.com (52.132.131.33) by DM5PR1501MB1990.namprd15.prod.outlook.com (52.132.129.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.428.17; Fri, 26 Jan 2018 19:56:04 +0000 Received: from DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a]) by DM5PR1501MB2183.namprd15.prod.outlook.com ([fe80::d456:358e:8371:a44a%13]) with mapi id 15.20.0444.016; Fri, 26 Jan 2018 19:56:04 +0000 From: Roberto Peon To: Dmitri Tikhonov , Charles 'Buck' Krasic CC: Jana Iyengar , IETF QUIC WG , Mike Bishop , Kazuho Oku Subject: Re: Updated QCRAM Draft Thread-Topic: Updated QCRAM Draft Thread-Index: AdOU155bAsc1/g3LTZii92sX1uSC2gAG8R4AAAY51AAABuVXgAACrlmAAADCBIAAOpRhAAACWY+AABzS6AA= Date: Fri, 26 Jan 2018 19:56:04 +0000 Message-ID: References: <20180125221044.GA32273@ubuntu-dmitri> In-Reply-To: <20180125221044.GA32273@ubuntu-dmitri> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:bce] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR1501MB1990; 20:LdN96b9BvFehLzlhMKM5HBFWPhHOBnqxlPFhk5OHAb5S+xi7TmKJmgc7PharuPi0lJ0cW5hX9ebRWe7tTOYk5WA5DhB9fUM14eyvLrdmETPtPsGsBeFvLkD8PFVbO0RvjrU/9njh99xzHdXkM+jsddXbsfA0QoPrk6HSLmb19mc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0aca10cb-5b79-4f87-5f33-08d564f6d581 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR1501MB1990; x-ms-traffictypediagnostic: DM5PR1501MB1990: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(81227570615382); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231076)(11241501184)(2400081)(944501161)(10201501046)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR1501MB1990; BCL:0; PCL:0; RULEID:; SRVR:DM5PR1501MB1990; x-forefront-prvs: 05641FD966 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(396003)(39380400002)(189003)(199004)(478600001)(33656002)(2950100002)(2900100001)(76176011)(102836004)(8936002)(5660300001)(7116003)(110136005)(81166006)(81156014)(53546011)(6506007)(316002)(68736007)(106356001)(6116002)(99286004)(14454004)(54906003)(3660700001)(7736002)(82746002)(3280700002)(105586002)(3480700004)(305945005)(39060400002)(2906002)(6436002)(97736004)(53936002)(6486002)(36756003)(6512007)(229853002)(25786009)(6246003)(186003)(93886005)(4326008)(8676002)(5250100002)(83716003)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR1501MB1990; H:DM5PR1501MB2183.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0bbVqobUv1TskkOQHSfGcxM2bVxm4DySg3hLurkYZGOteqUuGbz+PwePxL1yMC3FI3CI1kTvvN7jIaL1NN9pMQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0aca10cb-5b79-4f87-5f33-08d564f6d581 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2018 19:56:04.8457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1501MB1990 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-26_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 26 Jan 2018 19:56:15 -0000 Q291bnRpbmcga2V5LXZhbHVlcyB2cyBjb3VudGluZyBoZWFkZXIgYmxvY2tzIHBlcmhhcHM/DQot PVINCg0KT24gMS8yNS8xOCwgMjoxMSBQTSwgIlFVSUMgb24gYmVoYWxmIG9mIERtaXRyaSBUaWto b25vdiIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgZHRpa2hvbm92QGxpdGVz cGVlZHRlY2guY29tPiB3cm90ZToNCg0KICAgIE9uIFRodSwgSmFuIDI1LCAyMDE4IGF0IDAxOjAz OjI4UE0gLTA4MDAsIENoYXJsZXMgJ0J1Y2snIEtyYXNpYyB3cm90ZToNCiAgICA+IEkgcmFuIHNv bWUgdGVzdHMgdG8gY29tcGFyZSBocGFjaywgcWNyYW0tMDMgYW5kIHFjcmFtLTA0Lg0KICAgID4g DQogICAgPiAgICAgICAgICAgICAgSG9sQnMgICAgICglKQ0KICAgID4gaHBhY2sgICAgICAgODUw ICAgICAgICAgMTAwDQogICAgPiBxY3JhbS0wMyAgIDI3ICAgICAgICAgICAgMy4yDQogICAgPiBx Y3JhbS0wNCAgIDQ2ICAgICAgICAgICAgNS40DQogICAgPiANCiAgICA+IEhvbEJzIGhlcmUgYXJl IHJlcXVlc3RzIHRoYXQgZXhwZXJpZW5jZWQgSG9sIGJsb2NraW5nLg0KICAgIA0KICAgIC0tLTg8 LS0tLQ0KICAgIA0KICAgID4gVGhlIGhhciB3YXMgYSBmYWNlYm9vayBvZiBteSBvd24uICBJIGdv dCBpdCBmcm9tIGNocm9tZSwgdXNpbmcgZGV2ZWxvcGVyDQogICAgPiB0b29scyBGb3IgcmVmZXJl bmNlIGl0IGhhcyAyOTkgcmVxdWVzdHMsIGFuZCAxNjc5NTUgdW5jb21wcmVzc2VkIGhlYWRlcg0K ICAgID4gYnl0ZXMuDQogICAgDQogICAgSSBhbSBzdXJlIEkgbWlzdW5kZXJzdGFuZCBzb21ldGhp bmc6DQogICAgDQogICAgLSBIb3cgY2FuIHRoZSBudW1iZXIgb2YgcmVxdWVzdHMgdGhhdCBleHBl cmllbmNlZCBIb0wNCiAgICAgIGJsb2NraW5nICg4NTApIGJlIGxhcmdlciB0aGFuIHRoZSB0b3Rh bCBudW1iZXIgb2YNCiAgICAgIHJlcXVlc3RzICgyOTkpPw0KICAgIA0KICAgIC0gV2hhdCBkb2Vz IHRoZSBwZXJjZW50YWdlIGNvbHVtbiAoMTAwLCAzLjIsIDUuNCkgcmVwcmVzZW50Pw0KICAgIA0K ICAgICAgLSBEbWl0cmkuDQogICAgDQogICAgDQoNCg== From nobody Fri Jan 26 12:32:59 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C029A12778D for ; Fri, 26 Jan 2018 12:32:57 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 lN3OxmAwjJp5 for ; Fri, 26 Jan 2018 12:32:55 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10CC124B17 for ; Fri, 26 Jan 2018 12:32:55 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id l17so1707526ioc.3 for ; Fri, 26 Jan 2018 12:32:55 -0800 (PST) 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=n0c58dhok5N8tGECu9G+4tmNBtrUS8q4n8U8dQXdpEo=; b=pC14NKxQljxMAWPUJ7QFhePmlcqdoMup3PIyskPiKmQxoavuCGtBft0+jatsC/ywSM BbnYDdC2sfpPJ8/TKmZ3thv+c3i1E1A0iuujVTY8SUrI6Z84ynrBtRqb8mlFAiZizjDA QvkU2/u/9kNUvfsXp2vPeAkyq3uLPHYT+kjZ6laiSg+NiBTRsB7rz2B20Sfbqv51gIeP NgIzIZ8XjIeZ4owho+xRNYANBTia2ami4F6Yubbt5ZZm8tyPIMvpVJ/9gFxbKE6ad1Cl dYhkEvWhwUO3oJBV6W77ZZVzBU5kCJCSM7meqRbVeanAlp7Qvyd6ddu4TP8KfKYpCfEL BiiA== 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=n0c58dhok5N8tGECu9G+4tmNBtrUS8q4n8U8dQXdpEo=; b=l+w94FEu1y+pirJVroRAaGXg1Z+bZzJWuFj9G9xCr5aIzk/liwJGCUlhnDqb5jdBXd T8BZznPaOLw0lJaq7uuNae1PQ6RRQuoAhmMOYJbJbIGixEYPUvlwF5PrTXNyfdv9Vun0 uc3W9f2laYmQseMrFoLWmeOLOvwHOx2eMb2Pmr2BQmnLpAkMKgiZG2o52JY28+jxeyQa bWJ+oq1SLGaapyCDd5ORpoQejbJfVOJGh8juE4IX5lVOF74FEI2F1/FsLjlCTVLbzrrZ PVYv5G+Z3hPhkIFJQ2+SN+lCHtqQ8C/IrNaNnrfIaJghmYP6ZqmrQlhFNQ8Hy5WJ4CRu joKg== X-Gm-Message-State: AKwxytdcIFIBvRA4dc94L+xZXaOE8RnvgWHc9zO56IzpHG4Kba4GSgbe Z3y6vj0OVoox3gkXT0fchNQ0jhYD5wuQ0owxDYng X-Google-Smtp-Source: AH8x226XLdHkApvSOAedPY8dupqaCKLkqOWKXSpUKtvtJq0KfNiwcj++xriE2Cc0iqKsHIoQu2qqbf8gaw+UK8iBPws= X-Received: by 10.107.3.160 with SMTP id e32mr13138027ioi.51.1516998774569; Fri, 26 Jan 2018 12:32:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.207 with HTTP; Fri, 26 Jan 2018 12:32:34 -0800 (PST) In-Reply-To: References: <20180125221044.GA32273@ubuntu-dmitri> From: "Charles 'Buck' Krasic" Date: Fri, 26 Jan 2018 12:32:34 -0800 Message-ID: Subject: Re: Updated QCRAM Draft To: Roberto Peon Cc: Dmitri Tikhonov , Jana Iyengar , IETF QUIC WG , Mike Bishop , Kazuho Oku Content-Type: multipart/alternative; boundary="001a113ea69215ec9f0563b3cd66" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 26 Jan 2018 20:32:58 -0000 --001a113ea69215ec9f0563b3cd66 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 26, 2018 at 11:56 AM, Roberto Peon wrote: > Counting key-values vs counting header blocks perhaps? > -=R > I think you missed my reply, but just in case: 10 runs * 299 requests in the har = 2990 total requests. > > On 1/25/18, 2:11 PM, "QUIC on behalf of Dmitri Tikhonov" < > quic-bounces@ietf.org on behalf of dtikhonov@litespeedtech.com> wrote: > > On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck' Krasic wrote: > > I ran some tests to compare hpack, qcram-03 and qcram-04. > > > > HolBs (%) > > hpack 850 100 > > qcram-03 27 3.2 > > qcram-04 46 5.4 > > > > HolBs here are requests that experienced Hol blocking. > > ---8<---- > > > The har was a facebook of my own. I got it from chrome, using > developer > > tools For reference it has 299 requests, and 167955 uncompressed > header > > bytes. > > I am sure I misunderstand something: > > - How can the number of requests that experienced HoL > blocking (850) be larger than the total number of > requests (299)? > > - What does the percentage column (100, 3.2, 5.4) represent? > > - Dmitri. > > > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 <(408)%20412-1141> --001a113ea69215ec9f0563b3cd66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable     --001a113ea69215ec9f0563b3cd66-- From nobody Fri Jan 26 12:52:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E969B1272E1 for ; Fri, 26 Jan 2018 12:52:43 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 ZyhGxc3Mm-SC for ; Fri, 26 Jan 2018 12:52:39 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA5E1201FA for ; Fri, 26 Jan 2018 12:52:38 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id o35so4520528qtj.13 for ; Fri, 26 Jan 2018 12:52:38 -0800 (PST) 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=22N/ukWguhFR9jmgbkwZFvShjznEuxMf4bTGwfgS9eI=; b=k9UkI3ttGBubS3ukggKq/fitvENB0+04dEMivShXdT1il9B7HUfkThf2MiAaRxRrTF 9Rt92HYmzi8yqmNEfIrD5F893pQobN6Jm6l9jPssAjHCxreYJej4WqOiw9cAtAOqteoU X5b8f+Mg0EPmgEVKZ4cVmaWyueTNRMcXmjdooJeV8dhmp7/daffLpVvmdYQt5PY9CHKt yqo9klBpVKQ4yxUt9bfDnDCJBKYb07hhpGe/EoYHHqAoC0q/A49jnTrPQP4//1teOMJL K7heJ+TMD94ANvADQmtWG0ZgEI2XfwYlLe2G+MFgjQ50G7hxsS6RIaL39Qrf9vkS56ag Dsmw== 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=22N/ukWguhFR9jmgbkwZFvShjznEuxMf4bTGwfgS9eI=; b=pXfX5xlaYRVDZzC6uK7qXfPLkMM3WFCRd6JiKJB210IT2GScCMthKPbBIDo0xco2OM klKPmS+QkEIl4VbYynYpl3lZ/6wv+UQmIjP+uyLrA0zT6zYfiqNMs/Q8TSf62FDAeuQa 0CnUMjITW8ta1ub/0RZi4WiimZXziKTEh/B7Ii87+kkFO8lzYTldqE/GK0z8tH2rEs+l h/3r0Cl9xgyKrrH2Or0CPg5NPOkJ89S6bAAclrT8IHQusrZKB9fsC+I0VIptnQIJ6/pT 1XuB1TMSfrOn9jy+5lYQfkheaYtBC9QptKXoj9J0nbZWayC4fR2KPDOaSfhTALqN4Aed N60A== X-Gm-Message-State: AKwxytdHMJR9se+pONGaKpcdeibKwKB4yzUh0Jb/SCkyXX6cXaiPFJCv 0Oixd//DWF48IULLBKcn1dfoXidcR4qfp+ow2yyIkg== X-Google-Smtp-Source: AH8x227c4cYH8m7ZFXKpalkzsnLjwhh8/LqEm5UUs4EW8gP+KEfXrfkbrmD7uBplZFE34yG1LuiMuKEFFLVSJhM8MP0= X-Received: by 10.55.191.69 with SMTP id p66mr23329127qkf.315.1516999957835; Fri, 26 Jan 2018 12:52:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.12.130 with HTTP; Fri, 26 Jan 2018 12:52:36 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Fri, 26 Jan 2018 15:52:36 -0500 Message-ID: Subject: Re: Mechanism for negotiating extensions To: Christian Huitema Cc: Subodh Iyengar , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c043d429d6d180563b413e0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 26 Jan 2018 20:52:44 -0000 --94eb2c043d429d6d180563b413e0 Content-Type: text/plain; charset="UTF-8" Sure. Here's my idea of how this would work: https://github.com/quicwg/base-drafts/pull/1072 On Fri, Jan 26, 2018 at 1:35 AM, Christian Huitema wrote: > I personally agree that a mapping mechanism makes sense. RTP/SDP ended up > using a similar mechanism for the RTP media types, and that seems to have > worked well. In fact, I proposed something similar in a comment to MT's > extension proposal: Reserve a small number of extension frame types in the > "frame type" space. Create a transport parameter option in which the client > says "I want to use reserved frame type X to do XYZT". Server acknowledges > with corresponding option, "Let's use frame type X to do XYZT". XYZT is a > four letter acronym reserved in a Wiki. > > > Victor, why don't you submit a PR, so we can have a discussion on the > details? > > > -- Christian Huitema > > On 1/25/2018 10:09 AM, Subodh Iyengar wrote: > > Alternatively, could we say that "You MUST not use extension frames in > IETF QUIC versions", i.e. if you want to use a extension frame, you should > have your own version of QUIC. > > > This makes extension frames less useful for IETF QUIC versions, but > private experimental QUIC versions do not have to rev that often, which is > super valuable as well. > > > Subodh > ------------------------------ > *From:* QUIC on behalf of > Victor Vasiliev > *Sent:* Thursday, January 25, 2018 8:34:24 AM > *To:* IETF QUIC WG > *Subject:* Mechanism for negotiating extensions > > I've been thinking about extension negotiation, and I'm not entirely sure > that "just put a transport parameter per extension" is a sufficiently > complete answer. There are at least two problems in extending QUIC that we > ought to address. > > The first problem is that the frame type field is only one byte long. > While this is enough for any single QUIC connection, if we try to allocate > those globally in a non-conflicting manner, we might exhaust it sooner than > we think (also, this would require coordinating two extensions to be > compatible). Thus, I believe we should to add a general mechanism where > every extension, when negotiated, would specify which frame type numbers > it's using on the wire for each frame, so that this number allocation can > be performed on per-connection basis. I believe there are mechanisms > similar to that in other protocols (e.g. RTP does something like that in > RFC 8285). > > The second problem is that the client list of offered extensions is not > protected by secure keys. I am not sure how much of an issue this is in > terms of ossification -- I don't remember off the top of my head where it > caused problems in TLS *per se*, and inventing a completely new mechanism > for it will surely run into a set of issues. Still, it's worth discussing. > > If people believe that the mapping proposal is valuable, I can write up a > PR for this. > > > --94eb2c043d429d6d180563b413e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Sure.=C2=A0 Here's my idea of how this would work:=C2= =A0https://gith= ub.com/quicwg/base-drafts/pull/1072
    On Fri, Jan 26, 2018 at 1:35 AM, Christian Huit= ema <huitema@huitema.net> wrote:
    =20 =20 =20

    I personally agree that a mapping mechanism makes sense. RTP/SDP ended up using a similar mechanism for the RTP media types, and that seems to have worked well. In fact, I proposed something similar in a comment to MT's extension proposal: Reserve a small number of extension frame types in the "frame type" space. = Create a transport parameter option in which the client says "I want to use reserved frame type X to do XYZT". Server acknowledges with corresponding option, "Let's use frame type X to do XYZT&quo= t;. XYZT is a four letter acronym reserved in a Wiki.


    Victor, why don't you submit a PR, so we can have a discussion o= n the details?


    -- Christian Huitema


    On 1/25/2018 10:09 = AM, Subodh Iyengar wrote:
    =20 =20

    Alternatively, could we say that "You MUST not use extension frames in IETF QUIC versions", i.e. if you want to use a extension frame, you should have your own version of QUIC.


    This makes extension frames less useful for IETF QUIC versions, but private experimental QUIC versions do not have to rev that often, which is super valuable as well.


    Subodh

    From= : QUIC <quic-bounces@ietf.org>= ; on behalf of Victor Vasiliev <vasilvv@google.com><= br> Sent: Thursday, January 25, 2018 8:34:24 AM
    To: IETF QUIC WG
    Subject: Mechanism for negotiating extensions
    =C2=A0
    I've been thinking about extension negotiation= , and I'm not entirely sure that "just put a transport par= ameter per extension" is a sufficiently complete answer.=C2=A0 Ther= e are at least two problems in extending QUIC that we ought to address.

    The first problem is that the frame type field is only one byte long.=C2=A0 While this is enough for any single QUIC connection, if we try to allocate those globally in a non-conflicting manner, we might exhaust it sooner than we think (also, this would require coordinating two extensions to be compatible).=C2=A0 Thus, I believe we should to add a general mechanism where every extension, when negotiated, would specify which frame type numbers it's using on the wire for each frame, so that this number allocation can be performed on per-connection basis.=C2=A0 I believe there are mechanisms similar to that in other protocols (e.g. RTP does something like that in RFC 8285).

    The second problem is that the client list of offered extensions is not protected by secure keys.=C2=A0 I am not sure how much of an issue this is in terms of ossification -- I don't remember off the top of my head where it caused problems in TLS per se, and inventing a completely new mechanism for it will surely run into a set of issues.=C2=A0 Still, it's = worth discussing.

    If people believe that the mapping proposal is valuable, I can write up a PR for this.


    --94eb2c043d429d6d180563b413e0-- From nobody Sat Jan 27 16:45:23 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87673127337 for ; Sat, 27 Jan 2018 16:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=S/SCGdE8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cPiDZ18C Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuAdEYhKyFaD for ; Sat, 27 Jan 2018 16:45:18 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26ABD127136 for ; Sat, 27 Jan 2018 16:45:18 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9702120F41 for ; Sat, 27 Jan 2018 19:45:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 27 Jan 2018 19:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7EakgonTZQ4Q51+Jz RYCVRtQSgBG33Ki7dzsxVfbqqE=; b=S/SCGdE8pckxnfyKi9BF9ZLXSWXDLUBzW Xhh/80EOS0hZ6l0sgOijc/gL8U2WUfAYGBmqKfuD4ikcbylna4xz6c+OJHoVIKN0 Ujz0p858IVr+4yWj1c0pt1yXWVcJPNkv5B2DrkwuQ+LImNjzHHd4HOp64FRyfcqN rt6i/JvcWJG+THTZNtbNatcLEILOGwv222Jnq6QnCHszmLUTxNvqTAKfdIWomQ8j dtQJEye8g68+bwdrnpYJPwPEHq8CXks5/wx3jBTGWEVW4UPCCslTKlcb8hdFSmhY YaekXo/wwb4tU+peNpJ15z2LhrSFvSykmhdW+WbptiuhgpQXC9Wqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=7EakgonTZQ4Q51+JzRYCVRtQSgBG33Ki7dzsxVfbqqE=; b=cPiDZ18C SAlj3hpJN2Cemc3cR3tXWsKkoQW3znKcPr91zyDc8ftVodgG26Y/hpOatq5L5p4p Qh8FT08R+OcMB0HxCURwrBpgneJ5PnWIwL8zzLl6EaZMH+isDrRNIN9Z9t7AOU22 6m1155XHZ9yJvdb+CouSzSijF2tyUAPxMq4h4HL2P0bY8ARLbbNEoqjtUr93UG/b 9WLHeBTE+PFsxSXOYZfXJ/TO9cIML1Ck+jEDFOVZLUkX/4yN6hAPW+XPYNgc9A/h 3KQyws/6bEbEF6FnJ71PoeKlIbzepvJA7A7/MShYg//97x7+Oh4ori8REF71uLrR 4aEbs1wzi1c5rg== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id DFCA924805 for ; Sat, 27 Jan 2018 19:45:16 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 15C3CC0FCC for ; Sun, 28 Jan 2018 00:45:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============6234439661072290784==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180128004514.15C3CC0FCC@cloud.mnot.net> Date: Sun, 28 Jan 2018 00:45:14 +0000 (UTC) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 28 Jan 2018 00:45:21 -0000 --===============6234439661072290784== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * quicwg/base-drafts (+3/-9/=F0=9F=92=AC31) 3 issues created: - Mechanism for correctly routing separate stateful L7+ messages with dif= fering priorities (by grmocg) https://github.com/quicwg/base-drafts/issues/1073 - Specify Version Negotiation and Crypto Failure (by huitema) https://github.com/quicwg/base-drafts/issues/1069 - Invariants are IP-version-independent (by martinthomson) https://github.com/quicwg/base-drafts/issues/1062 15 issues received 31 new comments: - #1063 Remove *BLOCKED frames (6 by marten-seemann, larseggert, MikeBish= op, ianswett) https://github.com/quicwg/base-drafts/issues/1063 - #630 handshake and 0rtt data in a single packet (4 by RyanAtGoogle, kaz= uho, ianswett) https://github.com/quicwg/base-drafts/issues/630 - #714 Multiple connections on the same port (3 by martinthomson, martind= uke, mikkelfj) https://github.com/quicwg/base-drafts/issues/714 - #1069 Specify Version Negotiation after Crypto Failure (3 by huitema, M= ikeBishop) https://github.com/quicwg/base-drafts/issues/1069 - #1023 Is zero a valid stream-ID in Transport Parameters? (3 by MikeBish= op, mikkelfj) https://github.com/quicwg/base-drafts/issues/1023 - #1067 Retry packet and PADDING (2 by marten-seemann, larseggert) https://github.com/quicwg/base-drafts/issues/1067 - #252 In-order delivery of stream data (2 by martinthomson, mcmanus) https://github.com/quicwg/base-drafts/issues/252 - #904 HTTP header compression: static table fit for QUIC (1 by LPardue) https://github.com/quicwg/base-drafts/issues/904 - #238 Memory commitment for header parsing (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/238 - #783 QUIC streams abstraction (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/783 - #520 State bikeshedding time (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/520 - #205 Public routing info (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/205 - #1006 Appendix on GQUIC transition (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1006 - #952 Define or cite NAT rebinding (1 by LPardue) https://github.com/quicwg/base-drafts/issues/952 - #426 QUIC header format/demultiplexing (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/426 9 issues closed: - In-order delivery of stream data https://github.com/quicwg/base-drafts/= issues/252 - Retry packet and Server-Chosen Connection ID https://github.com/quicwg/= base-drafts/issues/713 - Multiple connections on the same port https://github.com/quicwg/base-dr= afts/issues/714 - QUIC streams abstraction https://github.com/quicwg/base-drafts/issues/7= 83 - QUIC header format/demultiplexing https://github.com/quicwg/base-drafts= /issues/426 - Memory commitment for header parsing https://github.com/quicwg/base-dra= fts/issues/238 - Public routing info https://github.com/quicwg/base-drafts/issues/205 - Appendix on GQUIC transition https://github.com/quicwg/base-drafts/issu= es/1006 - State bikeshedding time https://github.com/quicwg/base-drafts/issues/520 Pull requests ------------- * quicwg/base-drafts (+6/-1/=F0=9F=92=AC16) 6 pull requests submitted: - Define a mechanism for negotiating extensions (by vasilvv) https://github.com/quicwg/base-drafts/pull/1072 - consistent artwork typing (by reschke) https://github.com/quicwg/base-drafts/pull/1071 - Pick a new connection ID with Retry packets (by martinthomson) https://github.com/quicwg/base-drafts/pull/1066 - Transport parameters are stream counts, not IDs (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1065 - fix tiemr typo (by mcmanus) https://github.com/quicwg/base-drafts/pull/1064 - Include max_ack_delay (by ianswett) https://github.com/quicwg/base-drafts/pull/1060 3 pull requests received 16 new comments: - #1065 Transport parameters are stream counts, not IDs (9 by martinthoms= on, marten-seemann, huitema, MikeBishop) https://github.com/quicwg/base-drafts/pull/1065 - #1068 Add EXTENSION frame (6 by mirjak, janaiyengar, martinduke, huitem= a, mikkelfj) https://github.com/quicwg/base-drafts/pull/1068 - #1072 Define a mechanism for negotiating extensions (1 by mikkelfj) https://github.com/quicwg/base-drafts/pull/1072 1 pull requests merged: - fix tiemr typo https://github.com/quicwg/base-drafts/pull/1064 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============6234439661072290784== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

    Sunday January 28, 2018

    Issues

    quicwg/base-drafts (+3/-9/=F0=9F=92=AC31)

    3 issues created:

    15 issues received 31 new comments:

    9 issues closed:

    Pull requests

    quicwg/base-drafts (+6/-1/=F0=9F=92=AC16)

    6 pull requests submitted:

    3 pull requests received 16 new comments:

    1 pull requests merged:

    Repositories tracked by this digest:

    --===============6234439661072290784==-- From nobody Sat Jan 27 18:23:58 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1B4127078 for ; Sat, 27 Jan 2018 18:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 pvbyNQswaz2l for ; Sat, 27 Jan 2018 18:23:56 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDF91200C1 for ; Sat, 27 Jan 2018 18:23:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,424,1511856000"; d="asc'?scan'208";a="234643841" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx142-out.netapp.com with ESMTP; 27 Jan 2018 18:23:55 -0800 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 27 Jan 2018 18:23:55 -0800 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 27 Jan 2018 18:23:55 -0800 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.1320.4 via Frontend Transport; Sat, 27 Jan 2018 18:23:55 -0800 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=USfV6DX/+9DrfKfrRw5EUXFGmMv7BodmXplrdt9grys=; b=O8yI6e74ZMqY8oup6wW1sNO/w4jhHpdWZy3zpiNs/XmHIlhvMu20emAyxnUMBWgvwXuss2fKQHOlfsbZisB8BIhcS37V4umJYBLKPE2q8MvdbEM7mhMwLI1SVZywVQSjlI8vKuWpq4GcJ7ll0QId+gPMkylvS1M6Lwh1oNtY8mQ= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB818.namprd06.prod.outlook.com (10.141.22.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Sun, 28 Jan 2018 02:23:52 +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.20.0444.016; Sun, 28 Jan 2018 02:23:51 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Doodle poll for Feb 2018 remote interop day Thread-Topic: Doodle poll for Feb 2018 remote interop day Thread-Index: AQHTlZWamOk6nfArGUuGr+le3k3//6OIkuUA Date: Sun, 28 Jan 2018 02:23:51 +0000 Message-ID: <5D489CC6-2C35-4486-86DE-95CCC7A3C21D@netapp.com> References: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> In-Reply-To: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [203.38.90.218] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB818; 7:GW/9tF47LdRGBtTkxaoPbkb5yLBdXMHGWNUlmWRj7viXDoBy7X7HeRHxXBPC163kGc15uw4A6sZnG5qq4O5n4WhGlX4SLaU3atoxA6C/UngXq2X+K93Qvse/3DktUbFcKq1zqzTGsKrgdegJR5pOGUhax9R/JIBxR/8lZiRFwxJpjaDy3BdW966hQ2ep3g55D+xyFuXkkqhzlkeGyAdyDJNlD/aIDcA/3XORgAv1HLNAe8eCDuGSMm4RwHNdc4Q+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cd826365-a599-40af-1eda-08d565f62beb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB818; x-ms-traffictypediagnostic: BLUPR06MB818: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(8121501046)(5005006)(3231096)(2400081)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BLUPR06MB818; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB818; x-forefront-prvs: 05669A7924 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39380400002)(39850400004)(396003)(366004)(377424004)(189003)(199004)(14454004)(2900100001)(66066001)(3660700001)(86362001)(316002)(105586002)(3280700002)(81166006)(4001150100001)(8676002)(57306001)(81156014)(99936001)(2906002)(97736004)(3846002)(6116002)(36756003)(99286004)(33656002)(25786009)(82746002)(53936002)(6436002)(2950100002)(6916009)(76176011)(8936002)(966005)(106356001)(68736007)(6306002)(6512007)(6486002)(305945005)(26005)(7736002)(478600001)(50226002)(53546011)(83716003)(5660300001)(6506007)(77096007)(186003)(102836004)(229853002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB818; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Rc3Igewwt2XH3J5pEL29KkoZW2X7pyUi3VC+WSLqOA/uT45nB9NFjAJ1KzGt+BWBytC6rHNz4Y62G4B2zTQziQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_5BF5188E-5D4C-47ED-81C9-98B324C77233"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cd826365-a599-40af-1eda-08d565f62beb X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2018 02:23:51.0357 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB818 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: Sun, 28 Jan 2018 02:23:58 -0000 --Apple-Mail=_5BF5188E-5D4C-47ED-81C9-98B324C77233 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii At the moment, it looks like Thu, Mar 1. Please respond soon, I'll pick = a date by the end of the coming week. Lars > On 2018-1-25, at 15:33, Eggert, Lars wrote: >=20 > Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/ee4gueyfve3azpqn >=20 > (This will be a remote interop day. Next physical one will be = Hackathon in London.) >=20 > Lars --Apple-Mail=_5BF5188E-5D4C-47ED-81C9-98B324C77233 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlptNDYACgkQVLXDCb9w wVcllQ//Qw4gLh8RhqsPoAUhq5aIWUlAGpuseCUo/jr9T3ZmXeIzBCYQMIA1a9Cq E/hp7baUIL4eLPF79TfXML+92MFp3dGpcm0Hs4EYRa2zoMwKjpy6GynM95kpVR4M mxoamq828nNjmWeEaYyBPVIhse9Y6drM4drwKpmkNuOtfzKEvECSqFNEbpqs9bGi 8NzlsNtH86hRk9aqXrbiRqCifnSbpR1Eh4oJskROcgL+KF8khr7V+KvAGG3ZRqhs gR06LENCvB89FQj4lbiovbT05Vy/uSgiKuWz7ARApmCH5BNZrWqnqUlLdDpEqhyo pHDvCNSI8ZBj48RSHiRcs2myQ4ydakj/VEZYaNpWxow95UHp2cyDoKcX4ZoQqHOv djpXTNNzULOAl2Eo52sZPFO8TxwomTLPWJqP8juBJTgf/G050OQSxYgnLUH/pnim z2sNuEiFhIMRnL+VW4a8qJLaFMJNZOz2p02B2aiJdhtp67xXpCg4eiDQOxgl/U+j hOySrWebqBmGiu7mvDKFDQXXMgF1X+wIz9pgH2JvF66RK/S9usZlcPZLie+7hLva jklUMn8RXC7AsAEddMLx4Miy1a9PsvmlA7dTiNW4N8iSvqtKpNZjuL9IU9qj0CAq 663fe1OjCOLKz1pe5g3oJiqryIuW159ArvxdP8gaWpJsIaCfyf4= =8aKa -----END PGP SIGNATURE----- --Apple-Mail=_5BF5188E-5D4C-47ED-81C9-98B324C77233-- From nobody Sat Jan 27 20:33:15 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86CF127863 for ; Sat, 27 Jan 2018 20:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 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_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=evequefou.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 TCeitFG0qlTx for ; Sat, 27 Jan 2018 20:33:09 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0095.outbound.protection.outlook.com [104.47.42.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E1F31200FC for ; Sat, 27 Jan 2018 20:33:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fq9Dpf9AETr3hTRrTT39/s5bWyDIrkdNZQevxQJjF0Y=; b=lmcbYZ9whHnUUddlK0FB/oCdLXgR8/b4QCWrGrQD4D7P6B8k2mjFEGv+pnLjVWk9Np43DnpEt9ha9Sqd5htBi96DKRiWWBVfqsFO7GDRMIaCx3usC+sMiKVHifIybhtIVMA6XEE5GP3ZSlRLjf8anYrlUDdjNd10RUFWdS0ew8k= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2621.namprd08.prod.outlook.com (10.173.231.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Sun, 28 Jan 2018 04:33:06 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0444.016; Sun, 28 Jan 2018 04:33:06 +0000 From: Mike Bishop To: Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" , "Brian Trammell (IETF)" CC: Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" Subject: RE: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdOU5RXtZ09Jc7GvQAiw71TPDqLU5QATWZUQAAeBn1AAAsI1AAACpr+AAA8DdQAAAO0UgAAGEbDQABrQR4AAcdVVYA== Date: Sun, 28 Jan 2018 04:33:05 +0000 Message-ID: References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> In-Reply-To: <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:5a28:2884:6ca0:cd5d:46b5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2621; 6:v6BVqWM7azu99XcxgbayIV2AqHOL/xNxoaSiXvIylxmGsUg3mUcb6SeToIeRUAcIzcRtzDfzUekIp85x10nymBY/HqdJmdD7rlXsiw/54jnFDUBmVJutnlXog5gFRKFsabpOxVnaAd0RvLhpbdkzGw8c1qcO85I9N3MU9xnJVUfw6hI693dWou/c9UWQddS9uG3AmEs5y7rxOrv8z2B5kMY/K61Jp+/LQc29W5Zhqap86OGRWlmsa8j+61oiMNEB+WkvqtLm5R36tO8kQe+VTAedPGNFBemLbkux312U1ECza3ftrcTeciri3tOoCJqpTdpIIBjmULArsPkRpjzKpUg1xHkXDgdCKaCiYRyP8kgVai/b8wG7kRMlvnfomNM3; 5:oE/CXRxCGO7P4aDG11bMl6HtN712mFkIyyBvemKhVa+jbhHphU/Z9f3wWETERaKl8Igu2dbTUx0fYPB9DuxJk/N8qaTfIUdE876qflzwGObS1KqRnjWJF9R1wcrnq/UQJHMQisDiWp+OoPjZXhjpzcph4yQ4m51yLaQnqbzpAuU=; 24:WadkLr/nnOIoU+FC7geNTBixR857nyzr4PUYAUe6cRcWQwoluDcVb5wsThpcXybgTw4Qrj2ziE6WQt2BRZRthYob+kf5BORqIKmKx8iprAo=; 7:NvuisGS4G1rQLoR9mEEOqvxg4gBK3uKFIoQFIvRU7xffGskKqqH44rPVLzX1XyR7tRYklkLvRYxNyPt1oAfI+disb6vMRg6fNJvZz8p0gfgG4PBYjVgEUscB2PXqAF2eyncdlAeaJGm5eici4OfF8h7WZ8tBh8WIr792iB9HMY/k+lPnO58FFqdulsox+x2Ox/SIZ/22yO0xpY5H7Y3u5ZyNkeaKzwivaRxuQDpm7vmbEFoExDGUwUTrH9pGMAui x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fcf2d4d9-ff64-4bad-c33c-08d566083a09 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2621; x-ms-traffictypediagnostic: MWHPR08MB2621: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231097)(2400081)(944501161)(6041288)(2016111802025)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2621; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2621; x-forefront-prvs: 05669A7924 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(39380400002)(39830400003)(396003)(189003)(199004)(13464003)(77096007)(97736004)(186003)(6436002)(81156014)(2906002)(55016002)(229853002)(9686003)(6306002)(81166006)(7736002)(8676002)(74316002)(6116002)(86362001)(305945005)(3480700004)(74482002)(53936002)(8936002)(102836004)(6506007)(106356001)(14454004)(3660700001)(3280700002)(53546011)(110136005)(6246003)(2900100001)(33656002)(54906003)(966005)(316002)(478600001)(25786009)(99286004)(68736007)(105586002)(93886005)(76176011)(7696005)(7116003)(5660300001)(2950100002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2621; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ab04owY6Q1mL2P5vApfMUJ4X3hTV4JwxqvjAG6gNhUDGWhRW+OmBnHqmNXH94dYbJNHdHsybgnaGgK2tukeyfA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: fcf2d4d9-ff64-4bad-c33c-08d566083a09 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jan 2018 04:33:05.8220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2621 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 28 Jan 2018 04:33:13 -0000 SSBtYXkgaGF2ZSBtaXNzZWQgdGhlIGZpbmFsIHN0YXRlIHdoZXJlIHRoaXMgbGFuZGVkLCBidXQg d2l0aCBNYXJ0aW4ncyByZXdvcmtpbmcgb2YgdGhlIGtleSBzY2hlZHVsZSB0aGF0IGluY2x1ZGVz IHRoZSBDb25uZWN0aW9uIElEIGluIHRoZSBrZXkgZ2VuZXJhdGlvbiwgd291bGRuJ3QgeW91IGF1 dG9tYXRpY2FsbHkgaGF2ZSBhIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHQgYW55IHRpbWUg eW91IGludGVudGlvbmFsbHkgY2hhbmdlZCBDb25uZWN0aW9uIElEcyAod2hpY2ggaXMgbGlrZWx5 IHdoZW4gY2hhbmdpbmcgcGF0aHMpIGFueXdheT8NCg0KQW5kIGlmIHlvdSBkb24ndCBjaGFuZ2Ug Q29ubmVjdGlvbiBJRCwgeW91J3JlIGFscmVhZHkgbGlua2FibGUgYmVjYXVzZSBvZiB0aGUgQ0lE LCBzbyB5b3UgZG9uJ3QgY2FyZSBpZiB5b3UncmUgY29udGludWluZyB0byB1c2UgdGhlIHNhbWUg c2VxdWVuY2UgbnVtYmVycy4gIChCdXQgd2UgYWdyZWVkIHRvIGVuY3J5cHQgdGhlbSBhbnl3YXku KQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpTZW50OiBU aHVyc2RheSwgSmFudWFyeSAyNSwgMjAxOCAyOjExIFBNDQpUbzogRGUgU2NoZXBwZXIsIEtvZW4g KE5va2lhIC0gQkUvQW50d2VycCkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNv bT47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQnJpYW4gVHJhbW1lbGwg KElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPg0KQ2M6IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEJv YiBCcmlzY29lIChyZXNlYXJjaEBib2JicmlzY29lLm5ldCkgPHJlc2VhcmNoQGJvYmJyaXNjb2Uu bmV0Pg0KU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDDQoNCk9uIDEvMjUvMjAxOCAxMjoxMCBBTSwg RGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgd3JvdGU6DQoNCj4gU29tZSBx dWVzdGlvbnMgcmVsYXRlZCB0byB0aGUgcmVtYXJrIG9mIENocmlzdGlhbjogIldlIGFyZSBoZWFk aW5nIHRvd2FyZHMgYSBzaW5nbGUgcGFja2V0IHNlcXVlbmNlIG51bWJlciBzcGFjZSBzaGFyZWQg YnkgbXVsdGlwbGUgcGF0aHMiDQo+IFdoYXQgaXMgdGhlIHJhdGlvbmFsZSBiZWhpbmQgdGhpcz8N Cj4gSXMgdGhlIHJlYXNvbiBmb3IgdGhpcyB0aGF0IHRoZXJlIGFyZSBjdXJyZW50bHkgbm8gcGVy IHBhdGggc3RhdGVzL2NvbW11bmljYXRpb25zIHJlcXVpcmVkPyAoYmVjYXVzZSBjb25nZXN0aW9u IGNvbnRyb2wgaXMgY3VycmVudGx5IG91dCBvZiBzY29wZSwgYW5kIGl0IGlzIGN1cnJlbnRseSB0 aGUgb25seSBwZXIgcGF0aCBwcm9jZXNzaW5nIHJlcXVpcmVkKS4gSW4gdGhhdCBjYXNlIEkgdW5k ZXJzdGFuZCB3aHkgdGhlIGN1cnJlbnQgZGVzaWduIG9mIFFVSUMgaXMgb3B0aW1pemluZyBpdHNl bGYgdG93YXJkcyBhcHBsaWNhdGlvbiB0byBhcHBsaWNhdGlvbiBzdGF0ZSwgYnV0IHdlIG11c3Qg bWFrZSBzdXJlIHdlIGRvbid0IG1ha2Ugb3VyIGxpdmUgZGlmZmljdWx0IGlmIHdlIGhhdmUgcGVy IGNvbm5lY3Rpb24gc3RhdGUgKHdoZW4gaXQgaXMgbmVlZGVkLCBsaWtlIGNvbmdlc3Rpb24gY29u dHJvbCkuDQoNClRoaXMgaXMgcmVsYXRlZCB0byBlbmNyeXB0aW9uIG9wdGlvbnMgZm9yIG11bHRp cGF0aC4gSSBleHBsYWluZWQgdGhlIGRlc2lnbiBjaG9pY2VzIGluIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtcXVpYy1tcGF0aC1yZXEvLiBBRUFEIGVuY3J5 cHRpb24gcmVxdWlyZXMgdGhhdCBzZXF1ZW5jZSBudW1iZXJzIGRvIG5vdCByZXBlYXQgZm9yIGEg Z2l2ZW4gZW5jcnlwdGlvbiBjb250ZXh0LiBGb3IgbXVsdGlwYXRoLCB0aGlzIHJlcXVpcmVtZW50 IGNhbiBiZSBtZXQgYnkgZWl0aGVyIGhhdmluZyBzZXBhcmF0ZSBlbmNyeXB0aW9uIGNvbnRleHRz IHBlciBwYXRoLCBvciBoYXZpbmcgYSBzaW5nbGUgZW5jcnlwdGlvbiBjb250ZXh0IGZvciBhbGwg cGF0aHMgYW5kIHVzaW5nIHRoZSBzYW1lIHNlcXVlbmNlIG51bWJlciBzcGFjZSBmb3IgZXZlcnkg cGF0aHMuIFRoaXMgaXMgYWxzbyBhIHJlcXVpcmVtZW50IHdoZW4gbXVsdGlwbGUgcGF0aHMgYXJl IHVzZWQgZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uLg0KDQpXZSBoYWQgdGhhdCBkaXNjdXNzaW9u IGluIE1lbGJvdXJuZSwgYW5kIHRoZSBzZW5zZSBvZiB0aGUgcm9vbSB3YXMgY2xlYXJseSB0aGF0 IGhhdmluZyBzZXBhcmF0ZSBlbmNyeXB0aW9uIGNvbnRleHRzIHBlciBwYXRocyB3YXMgdG9vIGNv bXBsaWNhdGVkLiBIYXZpbmcgYSBzaW5nbGUgc2VxdWVuY2UgbnVtYmVyIHNwYWNlIGFuZCBhIHNp bmdsZSBlbmNyeXB0aW9uIGNvbnRleHQgaXMgc2lnbmlmaWNhbnRseSBzaW1wbGVyLiBUaGVyZSBp cyBhIHByaXZhY3kgaXNzdWUsIGxpbmthYmlsaXR5IHZpYSB0aGUgc2VxdWVuY2UgbnVtYmVycywg YnV0IHRoYXQgcHJpdmFjeSBpc3N1ZSBjYW4gYmUgYWRkcmVzc2VkIGJ5IGVuY3J5cHRpbmcgdGhl IHNlcXVlbmNlIG51bWJlcnMsIGFuZCB3ZSBwcmV0dHkgbXVjaCBhZ3JlZWQgdG8gZG8gdGhhdC4g SGVuY2UgbXkgc3RhdGVtZW50IHRoYXQgIldlIGFyZSBoZWFkaW5nIHRvd2FyZHMgYSBzaW5nbGUg cGFja2V0IHNlcXVlbmNlIG51bWJlciBzcGFjZSBzaGFyZWQgYnkgbXVsdGlwbGUgcGF0aHMiLg0K DQpPZiBjb3Vyc2Ugd2Ugc3RpbGwgbmVlZCB0byBtYWludGFpbiBwZXIgcGF0aCB2YXJpYWJsZXMg Zm9yIFJUVCwgUE1UVSBhbmQgY29uZ2VzdGlvbiBjb250cm9sLiBBcyBsb25nIGFzIHdlIG9ubHkg c3VwcG9ydCBtaWdyYXRpb24sIHRoYXQgY291bGQgYmUgZmluZXNzZWQgc29tZXdoYXQgYnkgcmVz ZXR0aW5nIHRoZXNlIHZhcmlhYmxlcyB0byB0aGVpciBpbml0aWFsIHN0YXRlIGF0IHRoZSBlbmQg b2YgdGhlIG1pZ3JhdGlvbi4gQnV0IHdoZW4gd2UgZG8gdHJ1ZSBtdWx0aXBhdGgsIHRoZXJlIHdp bGwgYmUgYSBuZWVkIHRvIGFzc29jaWF0ZSBjb25nZXN0aW9uIGNvbnRyb2wgc2lnbmFscyB3aXRo IHBhdGhzLiBJZiB3ZSBoYXZlIGEgc2luZ2xlIHNlcXVlbmNlIG51bWJlciwgdGhlIHdheSB0byBk byB0aGF0IGlzIHRvIG1haW50YWluIGFzc29jaWF0aW9ucyBiZXR3ZWVuIHBhY2tldHMgYW5kIHBh dGgsIGUuZy4gaGF2aW5nIGEgcGF0aCB0YWcgaW4gdGhlIHBhY2tldCBjb3B5IGtlcHQgZm9yIHJl dHJhbnNtaXNzaW9uIHB1cnBvc2VzLiBUaGF0J3Mgc3VmZmljaWVudCBmb3Igc2lnbmFscyBsaWtl IEFDSyBvciBsb3NzZXMsIGJ1dCBpdCByZXF1aXJlcyB0aGF0IEVDTiBzaWduYWxzIGJlIHRpZWQg dG8gc3BlY2lmaWMgcGFja2V0cy4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg== From nobody Sun Jan 28 13:34:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D863512E741 for ; Sun, 28 Jan 2018 13:34:44 -0800 (PST) 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 U3pVNvvGMy_E for ; Sun, 28 Jan 2018 13:34:42 -0800 (PST) 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 86E6412D861 for ; Sun, 28 Jan 2018 13:34:42 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1efub0-0007e7-JO for quic@ietf.org; Sun, 28 Jan 2018 22:34:39 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1efuay-0003HC-MS for quic@ietf.org; Sun, 28 Jan 2018 16:34:37 -0500 Received: (qmail 2702 invoked from network); 28 Jan 2018 21:34:34 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Jan 2018 21:34:34 -0000 To: Mike Bishop , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" , "Brian Trammell (IETF)" References: <660743ab697443f4ac5500e649a80285@usma1ex-dag1mb5.msg.corp.akamai.com> <26dd29d9-ce96-e858-078b-cc867990e8c5@huitema.net> <26b97168c48047018d1dfe6400a36b16@usma1ex-dag1mb5.msg.corp.akamai.com> <3809b20a-a141-f6fc-64de-785593cd9bf1@huitema.net> Cc: Ingemar Johansson S , QUIC WG , "Bob Briscoe (research@bobbriscoe.net)" From: Christian Huitema Message-ID: <69e9aa3f-1db9-bdaf-8e6f-e66eb6c62bbb@huitema.net> Date: Sun, 28 Jan 2018 11:34:30 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: ECN in QUIC X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.36) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qpFpeMddrLKhliRv2ghy7YXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuUYd7YbUJEBLyho2hGptP+B98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXsyb8kPdw8E5fjseDcUSkOjZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XSWizyN/9VXiZ4elFzVDIjrsNHLD5iuK9LgA8bTWyd hdX4nH2CHsZ2HqqctHV3jgBZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWdVYLStU2rrUXX7KMr7Beuaf4b0gaZx7Nq9QqOn1O3qTI o66Nfu4mllkiqZd6CeRygd3Yx+3ERBUSBHLCzLqwPSG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhRaIWNqDyY6nOXa2Z6n1IVlAxXqQU4SUCmX1X8Fu4HDHzL0ZrmIKZ0kUi8MQlv6kpQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo 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: Sun, 28 Jan 2018 21:34:45 -0000 On 1/27/2018 6:33 PM, Mike Bishop wrote: > I may have missed the final state where this landed, but with Martin's = reworking of the key schedule that includes the Connection ID in the key = generation, wouldn't you automatically have a different encryption contex= t any time you intentionally changed Connection IDs (which is likely when= changing paths) anyway? > > And if you don't change Connection ID, you're already linkable because = of the CID, so you don't care if you're continuing to use the same sequen= ce numbers. (But we agreed to encrypt them anyway.) Martin presented his connection-ID based encryption proposal in https://github.com/quicwg/wg-materials/blob/master/interim-18-01/grease.p= df. The proposal is described in slide 10. The minutes should note that the WG was less than enthusiastic. The consensus was that most benefits claimed in slide 11 of that deck could be obtained in a simpler way, by just encrypting the packet sequence number. People then started designing encryption methods on the fly, which was fun but probably not the best use of our time. I think that we asked a small design team to come out with a packet sequence number encryption method, and that we leaved open the issue of greasing the packet type. Of course, you still need to use new connection-ID upon migration, nothing changed there. -- Christian Huitema From nobody Sun Jan 28 17:27:38 2018 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 7DF62127342; Sun, 28 Jan 2018 17:27:36 -0800 (PST) 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-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151718925647.2970.687833601568606527@ietfa.amsl.com> Date: Sun, 28 Jan 2018 17:27:36 -0800 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, 29 Jan 2018 01:27:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-09.txt Pages : 97 Date : 2018-01-28 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 17:28:00 2018 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 5FBDF1314C7; Sun, 28 Jan 2018 17:27:54 -0800 (PST) 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-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151718927433.2986.8839696777042504492@ietfa.amsl.com> Date: Sun, 28 Jan 2018 17:27:54 -0800 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, 29 Jan 2018 01:27:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-09.txt Pages : 38 Date : 2018-01-28 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 [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-tls [3]. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 17:28:19 2018 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 8924F127369; Sun, 28 Jan 2018 17:28:09 -0800 (PST) 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-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151718928952.3101.8334570612904427404@ietfa.amsl.com> Date: Sun, 28 Jan 2018 17:28:09 -0800 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, 29 Jan 2018 01:28:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-09.txt Pages : 27 Date : 2018-01-28 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 [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-recovery [3]. 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 19:09:31 2018 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 113F0131557; Sun, 28 Jan 2018 19:09:26 -0800 (PST) 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-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151719536605.3065.17325303067990811648@ietfa.amsl.com> Date: Sun, 28 Jan 2018 19:09:26 -0800 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, 29 Jan 2018 03:09:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-09.txt Pages : 37 Date : 2018-01-28 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-09 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 20:43:53 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0A61315DC for ; Sun, 28 Jan 2018 20:43:51 -0800 (PST) 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=oLNYX/oV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fTun5dUX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEP2VayDM-2Q for ; Sun, 28 Jan 2018 20:43:49 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 652311315ED for ; Sun, 28 Jan 2018 20:43:43 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id AFCD5206DE; Sun, 28 Jan 2018 23:43:42 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 28 Jan 2018 23:43:42 -0500 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; s= fm1; bh=ShUwO6yCRpDZwXfz0//bgPqPyzYt11sPBu9Xe1lzvOQ=; b=oLNYX/oV QB0yWnTsqTdRTfo+XSFD+Bz/U3G4I+0kf6TqmdXfF1lYr6cFkG6FfSU49WgLQtKa r1DIaYdWzgHJRwrd1M/LATxgOY4dIQyTafsbWUpqWtT4VRMM4XiOOo1w9am89lvQ 3Ds9+I4JwTTyxeuUy/IPYcGFaI0pPpoKzrgV5b/Ig1ONMGsANVb4e3uENNiATyGW DRy3XmyhG1cFSv2bRvxoNu8OYDlCwPhBstoDHVOAjCENl3bTrjBpGTufMvDTduSJ /LES10HkZUBEFgmV5bfatKJrl/096iS+R94X8SEIr5QACFIP7TP/rFClIRyVRijV UopVyY/cGJyJsQ== 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; s=fm1; bh=ShUwO6yCRpDZwXfz0//bgPqPyzYt1 1sPBu9Xe1lzvOQ=; b=fTun5dUX3XUlDqYWNYi6JFQBOpUC+LQCUUdtFg9qoNOWw dRmxveVb4we34C1Tu+QEMZVMF+nLtsgMfbXfJR03JfyCgT23XxXJnDzBaimiN4LQ IR7QMHEsh7XqiitqYVMH6I3c3x0yAxked3UzjaT1M1WzH+Ib5HPDHkPET/YCCB7m ovu8wdTLBELOMui06VXNrJAfMPuQCxMVTexN5Ch6dmg8KIQL6ACIuHPJ2Szl7n+l 6OS3Zb6g1Z1yfg4poYsGtCh1UKovunhkJ1DDV5mVBqUqqR68gh/EG1BzWNfNJvru i4VJSsHJYmW3/tBjRION758VdVm3Y4F+KjIsQfErg== X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B771E241E0; Sun, 28 Jan 2018 23:43:41 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: DRAFT minutes of the Melbourne interim meeting Message-Id: Date: Mon, 29 Jan 2018 15:43:37 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 29 Jan 2018 04:43:52 -0000 ... are at: https://github.com/quicwg/wg-materials/blob/master/interim-18-01/minutes.md Thanks again to all of our scribes. As usual, corrections welcome, either through a pull request or via e-mail. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jan 29 10:58:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D012EACD for ; Mon, 29 Jan 2018 10:58:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 yOEYnry4UJOT for ; Mon, 29 Jan 2018 10:58:02 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 D698F12EA7C for ; Mon, 29 Jan 2018 10:58:01 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 25so8726959ioj.9 for ; Mon, 29 Jan 2018 10:58:01 -0800 (PST) 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=28FH/N9RL2W0gIjcqlIkrMhBgnu3akncE1MK9tYs2cw=; b=bKbKFDj2zZJ9vlQyaJhAQpztMqCTqBGPcOR0Bc3ov0jRYDsHv4kDFfqEjF74jTLPjC fK9A4FZrlnFsSbHPam4dOdLQ9HL3SY5QWuIrj3cxHEwXNxReN2Na0jji8ZkU6UDYbEfM /bXMP2x7wig0ivd4fPT62vB1os7YOoqYm84uXZa//lDZEJwknPNnfbunkWwxfEjLubZ9 LUqGp43c1OGGPVX3Z5C9UT2Da0uBlWykLVjM0Ob9pIPTEigePpyC2+8AlJmb78AZTGmk 0Rw08lE93wtfcvX1DVo+hJ/d4F1b8JTWTQFRuIHZgrMZOsMC5c/sqx6D1bTTH7DCj/1I OAcw== 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=28FH/N9RL2W0gIjcqlIkrMhBgnu3akncE1MK9tYs2cw=; b=OnuIfladIdmlNz0wD1PxWNFGIkeq1wWOIA//Lf39W48A7xC/00LufpylbzMcklRwEP fAtotowoi4BtGX4PsZ2I7cJ2Au2blrZa+5rhq8v8Y0CtEwOT8SKLpQgtV1gCf6Q7vUeu fG4LvZIQfA6K/RmO7M7CRPQGjp/Z+kTObwjfSihkFcevaGq7zAqw8dYlGV++w5FE/cjN TebUpKApEsk5E0+Dpc3NpI4MK9zis1ByuLcQFRmdWJ5v0NrLeBduVeKZZxOw5xfne6/K skTEjmCahTJUjGCYLkEhWomRBDqdsFLRWdB8shY7lH8LRhabK+GX0sb81UyF0lX2hF7x 4oTw== X-Gm-Message-State: AKwxytdKrAj5h8Cgn0FGKRLCj7VXeziFSp98BSEzaF3NUeInAD9bRDJa NFBQLdnPkQ8pJW66XibQqdn6H6cpFUc0K2RyM3Ww X-Google-Smtp-Source: AH8x225o3IypJNwDmtrd6CvP2WCF67nIXIjjDgh3hMpKgXR2DdI+8mJ3Z6j63P5/MkP7V6wioN8/TwSAWxC84o7rwBA= X-Received: by 10.107.59.66 with SMTP id i63mr26340334ioa.220.1517252280752; Mon, 29 Jan 2018 10:58:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.207 with HTTP; Mon, 29 Jan 2018 10:57:40 -0800 (PST) In-Reply-To: References: <20180125221044.GA32273@ubuntu-dmitri> From: "Charles 'Buck' Krasic" Date: Mon, 29 Jan 2018 10:57:40 -0800 Message-ID: Subject: Re: Updated QCRAM Draft To: Roberto Peon Cc: Dmitri Tikhonov , Jana Iyengar , IETF QUIC WG , Mike Bishop , Kazuho Oku Content-Type: multipart/alternative; boundary="94eb2c0686863b9cf60563eed3e7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 29 Jan 2018 18:58:05 -0000 --94eb2c0686863b9cf60563eed3e7 Content-Type: text/plain; charset="UTF-8" Just an FYI, with mbishop@'s help and after sorting some issues with my qcram github repo , the pages now have working editor's copy and diff links. In recent days, I've made some simplifications and changes in response to afrind@'s and kazuhooku@'s comments. -- Buck On Fri, Jan 26, 2018 at 12:32 PM, Charles 'Buck' Krasic wrote: > > On Fri, Jan 26, 2018 at 11:56 AM, Roberto Peon wrote: > >> Counting key-values vs counting header blocks perhaps? >> -=R >> > > I think you missed my reply, but just in case: > > 10 runs * 299 requests in the har = 2990 total requests. > > > >> >> On 1/25/18, 2:11 PM, "QUIC on behalf of Dmitri Tikhonov" < >> quic-bounces@ietf.org on behalf of dtikhonov@litespeedtech.com> wrote: >> >> On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck' Krasic wrote: >> > I ran some tests to compare hpack, qcram-03 and qcram-04. >> > >> > HolBs (%) >> > hpack 850 100 >> > qcram-03 27 3.2 >> > qcram-04 46 5.4 >> > >> > HolBs here are requests that experienced Hol blocking. >> >> ---8<---- >> >> > The har was a facebook of my own. I got it from chrome, using >> developer >> > tools For reference it has 299 requests, and 167955 uncompressed >> header >> > bytes. >> >> I am sure I misunderstand something: >> >> - How can the number of requests that experienced HoL >> blocking (850) be larger than the total number of >> requests (299)? >> >> - What does the percentage column (100, 3.2, 5.4) represent? >> >> - Dmitri. >> >> >> >> > > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 <(408)%20412-1141> > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --94eb2c0686863b9cf60563eed3e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Just an FYI, with=C2=A0mbishop@'s help and after sorti= ng some issues with my qcram github repo, the pages now have working editor's co= py and diff links.

    In recent days, I've made some simplif= ications and changes in response to afrind@'s and kazuhooku@'s comm= ents.

    -- Buck


    On Fri, Jan 26, 2018 at 12:= 32 PM, Charles 'Buck' Krasic <ckrasic@google.com> w= rote:

    On Fri, Jan 26, 20= 18 at 11:56 AM, Roberto Peon <fenix@fb.com> wrote:
    Counting key-values vs counting header blocks perhaps?<= br> -=3DR

    I think you missed my reply, but just in case:

    = 10 runs * 299 requests in the har =3D 2990 total requests.

    =C2=A0

    On 1/25/18, 2:11 PM, "QUIC on behalf of Dmitri Tikhonov" <quic-bounces@ietf.or= g on behalf of dtikhonov@litespeedtech.com> wrote:

    =C2=A0 =C2=A0 On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck&#= 39; Krasic wrote:
    =C2=A0 =C2=A0 > I ran some tests to compare hpack, qcram-03 and qcram-04= .
    =C2=A0 =C2=A0 >
    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HolBs=C2= =A0 =C2=A0 =C2=A0(%)
    =C2=A0 =C2=A0 > hpack=C2=A0 =C2=A0 =C2=A0 =C2=A0850=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0100
    =C2=A0 =C2=A0 > qcram-03=C2=A0 =C2=A027=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 3.2
    =C2=A0 =C2=A0 > qcram-04=C2=A0 =C2=A046=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 5.4
    =C2=A0 =C2=A0 >
    =C2=A0 =C2=A0 > HolBs here are requests that experienced Hol blocking.
    =C2=A0 =C2=A0 ---8<----

    =C2=A0 =C2=A0 > The har was a facebook of my own.=C2=A0 I got it from ch= rome, using developer
    =C2=A0 =C2=A0 > tools For reference it has 299 requests, and 167955 unco= mpressed header
    =C2=A0 =C2=A0 > bytes.

    =C2=A0 =C2=A0 I am sure I misunderstand something:

    =C2=A0 =C2=A0 - How can the number of requests that experienced HoL
    =C2=A0 =C2=A0 =C2=A0 blocking (850) be larger than the total number of
    =C2=A0 =C2=A0 =C2=A0 requests (299)?

    =C2=A0 =C2=A0 - What does the percentage column (100, 3.2, 5.4) represent?<= br>
    =C2=A0 =C2=A0 =C2=A0 - Dmitri.






    --
    Charles &#= 39;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141<= /span>


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

    --94eb2c0686863b9cf60563eed3e7-- From nobody Mon Jan 29 17:59:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CFDA1314CD for ; Mon, 29 Jan 2018 17:59:21 -0800 (PST) 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 qgBbOEbDV93t for ; Mon, 29 Jan 2018 17:59:19 -0800 (PST) Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com [IPv6:2607:f8b0:4003:c0f::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 1D454131992 for ; Mon, 29 Jan 2018 17:59:19 -0800 (PST) Received: by mail-ot0-x233.google.com with SMTP id r23so7024547ote.8 for ; Mon, 29 Jan 2018 17:59:19 -0800 (PST) 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=ComD55vNZRrMhK3g1lOiHUO72OF0zXquiEuMudQB7Y8=; b=tp8ylm43cEVKEmZvb6umNQGH+SVT3kzIkjlG6cXsxrvcfByezRlwfkGommlJQw4cgg nghlLI/h5UBWPFzp/jFWkex2+z8DtWIV3yo9qTngCZSqvO35GIPKwkboz9jOJSYcnyhn v7U5/7sDL8JNbEiHj9nPstTMA/5T7DUCAFkDJ8SpTmLcDh9TacIsoFzmtq5RGByNBCqC BMS1dHcsh0kfDfAu5jyJWZKqofXfoluIClM3fCJQv8BDIXbIc8eK8iUwXU5/ymSE7aOt wE7bIv7OqF/sAj+A5ChH9fQASl5uCHW05P+2TpZ7kXT1NAOq/JBGfwot5iwZfDif0M8X T0QA== 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=ComD55vNZRrMhK3g1lOiHUO72OF0zXquiEuMudQB7Y8=; b=ceVmT1E2LfFSYOYZ3nftq8PbNuUclINc2OsyDxl/dL7kgasIm9Ue8OUx8aDwWMcD0H AeDQYqu8f/J7wd5ZGaGJHSRmRxZ6b/deE3AphhVoudYkUyF3EVh86nAjVSZTdsH7UIEn a5i3h9kj0D0vnzicCAQ11kxVqJqgPAQW3sUzlcyM7D4GpJdWwdoegsuN4q9EeIrOVwZ3 o6wyOo5Gc4Dfigy8FLiTw5vL+0WPB6QUcMcCmPvgbBPTsxoI/PUksdT/6GndN/y40A1+ eLr/j1JdILeBOQqiycdLwFeANWwfFfvOP3dkO/ePdUmslYyp6OtJzA5XDbi5p4OiNz4l 1SDg== X-Gm-Message-State: AKwxytdvHsYM94IPPJZnfySNdILKhikX6efv2pIfHG4sTzSZbtVUOL/b bJot7JoR1llEqIDaRxf0YTU6XthE8M3IaXFNSri4HpVX X-Google-Smtp-Source: AH8x2244yRV+c9xhGkwgfdVuAnsUvf+AEMRwXXh0aCxmuj/zQ3Im0w+D5DGXzPSGVSKZC3vh0ocMp+a1We/SeOSBOUk= X-Received: by 10.157.72.221 with SMTP id a29mr9911834otj.308.1517277558130; Mon, 29 Jan 2018 17:59:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Mon, 29 Jan 2018 17:59:17 -0800 (PST) From: Martin Thomson Date: Tue, 30 Jan 2018 12:59:17 +1100 Message-ID: Subject: Packet number encryption 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, 30 Jan 2018 01:59:21 -0000 Here's a PR: https://github.com/quicwg/base-drafts/pull/1079 In short, this builds on Kazuho's excellent suggestion to use ECB-mode to protect the packet number. It does this only slightly differently, using suggestions from ekr and others to allow for cryptographic agility and use of primitives that match the negotiated AEAD. In short, it takes some of the ciphertext of the packet payload, and uses that to encipher the packet number. My intuition is that this is pretty solid, but I want to check if the working group is happy that this is generally OK before seeking cryptographic review. For instance, the requirement for side-channel resistance is already controversial: https://github.com/quicwg/base-drafts/pull/1079/files#r164588705 For the record, I doubt that this can be proven to be secure without both breaking new ground and adding some constraints to the AEADs that we use. And that's before we get into actual breaks on the technique that I'm too thick-headed to think of. In any case, we're relying on this to protect against linkability, so I'd like to ensure that we're not completely crazy in doing so. In case people were wondering, and because it already came up: I intend to separately propose a change to the short header packet that would remove the type field and move the packet number length under encryption. See my response to Ian's question on the PR for an explanation of how this will likely work. From nobody Tue Jan 30 06:49:38 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0B2131896 for ; Tue, 30 Jan 2018 06:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 UKpjfX5wXJNi for ; Tue, 30 Jan 2018 06:49:34 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 39CA4131B7F for ; Tue, 30 Jan 2018 06:44:08 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id c16so863831itc.5 for ; Tue, 30 Jan 2018 06:44:08 -0800 (PST) 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=Ep952HF7EB/e7z55Co+pTK5ygGS5DMo5u5pAl3Svm+8=; b=PDJHmsdpgX6T+JQA0SXeLfNj8h0NR4kSGQuuTo5UAVc/kSac06laq5DgVnIt3j0NK/ c5DBHmoA+xsTcjmV4gD1+PN8HCbugmYC/7VuYzcSFj7zgGl14HCZUzEeZ+DXZFnnU55Z kS7OxlwVSGaoBcIC0XxXpnRFLsAR0SoPi/c9KVwWyU2AnMSYGfThqe3hhXz7GKS3qBbC 4M/FZ0Y/nF/5sLpQ/gD628mNAlc98YNoGAUxFgqoinY7cat47wqCiYT2r82CxAj6gddB DZtl4S/aZy4tI3pP39FHjUE3Pshi204WxX5+ZGwJGt0PwaOETQvBt59516TgjyWW9zdP cpZQ== 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=Ep952HF7EB/e7z55Co+pTK5ygGS5DMo5u5pAl3Svm+8=; b=sQyjQMEHTX0Q8p1kokGG5qakC6zB3NQN4onLTPTi83ZXP1eQ0XBNNvFGEGG8JqUwm3 u7TiSQxUVAlmhNS4zad2KMVrbXuhRqg9Woo7NDWyL5q1i2VVFQ3LOSN1b8BKjLo8YKmd TO1EEAGLFIoqy34+Rb9xA78brZFIZ07b9cQwRzI/dUatVEYT+dh2zJuqmaX669y2h2k4 M0N1KyFk4RHke1zb617PqUf4ikXzR+yVnjP/LT8PdpPUEKnJNk1IhjwyX4WQfi89fWnc AxdxmDzZynoQ2jooUm0/PC5hweYcccXRzsAq6EnGLkLC4n6+ZaHMvb/cqlqDlxWrvZA6 FoZA== X-Gm-Message-State: AKwxytePdm9nL5SD8OJ6LOcb1yMHprW2iIVq4EbVw0wmZ6uwPQw3xxpy vKxbXgy6/sy6ESdRPOg+FzQ6NnxcBj83Klb3NgNO6g== X-Google-Smtp-Source: AH8x226gFB1DUqr11tfpJ1IeeIIDYbVOfFqjI3XuHV8zrOO82iUJjTH0OimMwfSEu5MrUkqRLB4c2kKttR8b0Ko3+RA= X-Received: by 10.36.192.10 with SMTP id u10mr31567973itf.73.1517323447338; Tue, 30 Jan 2018 06:44:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 30 Jan 2018 06:43:46 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 30 Jan 2018 09:43:46 -0500 Message-ID: Subject: Re: Packet number encryption To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05a2c21722460563ff65dc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Jan 2018 14:49:37 -0000 --94eb2c05a2c21722460563ff65dc Content-Type: text/plain; charset="UTF-8" Thanks for writing this up Martin. I'm definitely supportive of something like this, and I'd like to see it land in time we can try to interop with it in London. My intuition favors simplicity over crypto agility in this case, since we're already forcing implementations to support AES-GCM for the handshake packets, but I'm happy with whatever the group prefers. On Mon, Jan 29, 2018 at 8:59 PM, Martin Thomson wrote: > Here's a PR: > > https://github.com/quicwg/base-drafts/pull/1079 > > In short, this builds on Kazuho's excellent suggestion to use ECB-mode > to protect the packet number. It does this only slightly differently, > using suggestions from ekr and others to allow for cryptographic > agility and use of primitives that match the negotiated AEAD. > > In short, it takes some of the ciphertext of the packet payload, and > uses that to encipher the packet number. My intuition is that this is > pretty solid, but I want to check if the working group is happy that > this is generally OK before seeking cryptographic review. > > For instance, the requirement for side-channel resistance is already > controversial: https://github.com/quicwg/base-drafts/pull/1079/files# > r164588705 > > For the record, I doubt that this can be proven to be secure without > both breaking new ground and adding some constraints to the AEADs that > we use. And that's before we get into actual breaks on the technique > that I'm too thick-headed to think of. In any case, we're relying on > this to protect against linkability, so I'd like to ensure that we're > not completely crazy in doing so. > > In case people were wondering, and because it already came up: I > intend to separately propose a change to the short header packet that > would remove the type field and move the packet number length under > encryption. See my response to Ian's question on the PR for an > explanation of how this will likely work. > > --94eb2c05a2c21722460563ff65dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for writing this up Martin.=C2=A0 I'm definitel= y supportive of something like this, and I'd like to see it land in tim= e we can try to interop with it in London.

    My intuition = favors simplicity over crypto agility in this case, since we're already= forcing implementations to support AES-GCM for the handshake packets, but = I'm happy with whatever the group prefers.

    On Mon, Jan 29, 2018 at 8:59 PM, M= artin Thomson <martin.thomson@gmail.com> wrote:
    Here's a PR:

    https://github.com/quicwg/base-drafts/pull/1079<= /a>

    In short, this builds on Kazuho's excellent suggestion to use ECB-mode<= br> to protect the packet number.=C2=A0 It does this only slightly differently,=
    using suggestions from ekr and others to allow for cryptographic
    agility and use of primitives that match the negotiated AEAD.

    In short, it takes some of the ciphertext of the packet payload, and
    uses that to encipher the packet number.=C2=A0 My intuition is that this is=
    pretty solid, but I want to check if the working group is happy that
    this is generally OK before seeking cryptographic review.

    For instance, the requirement for side-channel resistance is already
    controversial:     https://github.com/qu= icwg/base-drafts/pull/1079/files#r164588705

    For the record, I doubt that this can be proven to be secure without
    both breaking new ground and adding some constraints to the AEADs that
    we use.=C2=A0 And that's before we get into actual breaks on the techni= que
    that I'm too thick-headed to think of.=C2=A0 In any case, we're rel= ying on
    this to protect against linkability, so I'd like to ensure that we'= re
    not completely crazy in doing so.

    In case people were wondering, and because it already came up: I
    intend to separately propose a change to the short header packet that
    would remove the type field and move the packet number length under
    encryption.=C2=A0 See my response to Ian's question on the PR for an explanation of how this will likely work.


    --94eb2c05a2c21722460563ff65dc-- From nobody Tue Jan 30 06:57:07 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5BB12EB72 for ; Tue, 30 Jan 2018 06:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Si7ZvDsshVB for ; Tue, 30 Jan 2018 06:57:01 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F37131B42 for ; Tue, 30 Jan 2018 06:53:23 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 032EA340E97; Tue, 30 Jan 2018 15:53:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.3316); Tue, 30 Jan 2018 15:53:20 +0100 (CET) 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; Tue, 30 Jan 2018 15:53:20 +0100 (CET) Received: from [81.134.152.4] (account ietf@trammell.ch HELO [172.18.9.171]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43779964; Tue, 30 Jan 2018 15:53:20 +0100 From: Brian Trammell (IETF) Message-Id: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_29D15D94-3500-4924-AE19-FA07D1B2B473"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Tue, 30 Jan 2018 14:53:18 +0000 In-Reply-To: Cc: Martin Thomson To: QUIC WG 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: Tue, 30 Jan 2018 14:57:06 -0000 --Apple-Mail=_29D15D94-3500-4924-AE19-FA07D1B2B473 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, Thanks for the PR. > On 30 Jan 2018, at 01:59, Martin Thomson = wrote: >=20 > Here's a PR: >=20 > https://github.com/quicwg/base-drafts/pull/1079 >=20 > In short, this builds on Kazuho's excellent suggestion to use ECB-mode > to protect the packet number. It does this only slightly differently, > using suggestions from ekr and others to allow for cryptographic > agility and use of primitives that match the negotiated AEAD. >=20 > In short, it takes some of the ciphertext of the packet payload, and > uses that to encipher the packet number. My intuition is that this is > pretty solid, but I want to check if the working group is happy that > this is generally OK before seeking cryptographic review. >=20 > For instance, the requirement for side-channel resistance is already > controversial: = https://github.com/quicwg/base-drafts/pull/1079/files#r164588705 >=20 > For the record, I doubt that this can be proven to be secure without > both breaking new ground and adding some constraints to the AEADs that > we use. And that's before we get into actual breaks on the technique > that I'm too thick-headed to think of. In any case, we're relying on > this to protect against linkability, so I'd like to ensure that we're > not completely crazy in doing so. I'm not sure this isn't completely crazy. Our model for linkage attacks seems a little too fuzzy to me to be = useful for evaluating whether this proposal is an improvement on the = status quo. Of course, there's an inherent tension among the = identifiability of flows by 5-tuple, the explicit identifiability of = flows by CID (which we'll work to remedy at the same time as we stick = more bits in the CID, apparently), and the desire for two independent = 5-tuple flows to remain unlinkable. So this is inherently hard, because = we don't have internally consistent set of requirements for linkability = support and avoidance. Beyond this, though, we need to have a coherent idea of what we're = trying to prevent. =46rom discussions to date, I think these are the two = cases we care about: (1) An unprivileged on-path device that sees a packet from a flow that = is migrated on purpose by an endpoint (i.e., due to connection migration = or multipath) should not be able to associate that packet to the prior = flow. (2) An unprivileged on-path device that sees a packet from a flow that = is unintentionally migrated (i.e., one of its globally routable = addresses changes without the associated endpoint's knowledge) should = not be able to associate that packet to the prior flow. In the presence of any connection ID that has enough entropy to be used = for load balancing, linkability avoidance in case 2 is impossible. = Indeed, the CID exists in part to *allow* linkability in case 2. Any = packet number encryption approach is necessarily useless for linkability = avoidance in this case, unless the CID is also protected with a secret = known only to the endpoints and the load-balancer. We'll see where the = CID DT lands here. When the connection ID is absent or protected, and the packet number is = encrypted, case 2 is still problematic. In an unintentional migration, = only two values in the five-tuple change, and it's impossible to make = the first packet sent from the migrated endpoint to the non-migrated = endpoint look like a handshake packet. So to find an unintentional = migration, an observer only needs to look for all flows toward a 3-tuple = without being preceded by a valid handshake that started within 30 = seconds of another one ending on the same 3-tuple. Even for very large = load balancers, this is not a giant anonymity set. If you believe that greasing functions over packet numbers is necessary = -- I'm not sure I do, but that's a different, future message -- then = this proposal might be useful for that, but if linkability prevention is = the goal, I'm not convinced it's fit for purpose. This proposal also opens a trivial class of wasted-work attacks against = QUIC servers by malicious clients, which can now craft packets which = will require the server to partially decrypt them before realizing = they're not useful. Obviously bad packet numbers can be avoided with = simple heuristics. Less-obvious attacks might be crafted to incur = significant nonproductive cost on the server side. This seems to be an = unavoidable property of any approach to packet number encryption that = would actually work, though, so that's not an observation about this = specific proposal. I also haven't done the analysis to see if this is = all that bad. Note as well that this proposal comes with a manageability cost. On-path = measurement of upstream loss and reordering would become impossible, and = the fidelity of the spin bit under loss and reordering would be reduced. > In case people were wondering, and because it already came up: I > intend to separately propose a change to the short header packet that > would remove the type field and move the packet number length under > encryption. See my response to Ian's question on the PR for an > explanation of how this will likely work. Yep, this makes sense. We'll need to consider these changes closely in = concert with any change to the CID. As above, avoiding linkability with = PN encryption while aiding it with a CID is hard, and a varlen CID plus = a varint encrypted PN will make parsing fiddlier than it already is. As Christian noted, using the short header type field to provide a sort = of subsequence number or other packet-number independent explicit signal = would mitigate the damage packet number encryption would to do loss and = reordering observability, but not completely address them. Cheers, Brian --Apple-Mail=_29D15D94-3500-4924-AE19-FA07D1B2B473 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpwht4ACgkQihK3vwvq RqP3YhAAj2iij+k7QOfLfkmgrbg5dV6b7nXa/Eqb7jhtQ1/ZMu+an0O0FoZO8+8r afh7YeTjMHQJYlb712bV39YJDJ5HXr2zrbnSaTDAQ+BfnUX+tOJv5/NiVcjMLla6 PysYczm1GYsLnmKdw7oNIcjg72xcXWkpmnS5nj3LapUPGry32Ce02jF992gbhHmB 2iIdfx+FQlmWwPQe73g9Jhz3AtTukI0xBBq18DLtosIiER4L52EA3571pLq/fPcP ZaBwDUbNE4cuuxl/Y4HQD+hLWCtkcvD7lvlkWCbDWP4dyu7DCG5YqYl5kgIJPMVh 7hMx6XHeGk2RnmbRKdkEi+V8GkJ2ADzbkgkaAA8FyK3eb1lJ8A5WUI7G2lCpN+29 8Slr/SmSioERp4Um2hUnwYVU5tk6qkx4C2kTacAoJQLmV4qLQ61diMybi7tJ9pAa 5wWF9wgBLFDDSzlPJbD/SVRQNjEKjp+l7FUr4dVVrTNyD6eVg6iTcIv5xGKwWiiH fz3jJXiG4nz64P7NJYN/wsQ/kcoNfTk+AN2bBH/OJWdPPZGeGHdGxvQk45OiHtvc mXrjCOLvXr3Aqu8YY2d4s1Hs9iIQGU/hyPKr9MwYvC04hpeHHSTNgV4rEo6X/DD6 XQqUhMRZydz8IQ3z+lYhMbfIWMrHhGlWKgWo9Cf4yRKKEWFFVuA= =rrRr -----END PGP SIGNATURE----- --Apple-Mail=_29D15D94-3500-4924-AE19-FA07D1B2B473-- From nobody Tue Jan 30 07:03:21 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F03131853 for ; Tue, 30 Jan 2018 07:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 8xJR9fBHhwIs for ; Tue, 30 Jan 2018 07:03:17 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 0B833131928 for ; Tue, 30 Jan 2018 06:59:41 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id e1so891667ita.0 for ; Tue, 30 Jan 2018 06:59:41 -0800 (PST) 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=jYAwwQLrTPeZ7vrd/UKGT1iYS9C/oUNoEn1MekMEvQo=; b=s/DYqCof0jv5n/XwsvmRKLc5RCkoU+vKsSynDd9SfinQz9qSgIBBDKpujdVzP7wLsR XsBPMrauuOMHO2XduZ2JBaZda49p8t5e8aIDd9BwNs/a2yVKp5FvqumfCttK7RjdAIXK KJZnC/LedhmEjN5cyvIzF8KTaJsX0h7wjJTrUUAXxw+JzZajdB8H0wqM4M9IN/6fINk9 pdPXnClizS3KIsa48/zkZ0sL4/7iRKZwSwbPlkcpUE1sUFbo0NM/JwckwojzBEg6sqwv cT2Px6MNHRU7PME3t/XtMrQGBNKusp8098gloVmA6nggPHcG359M+A0i6VNesH8cjGCk IMNg== 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=jYAwwQLrTPeZ7vrd/UKGT1iYS9C/oUNoEn1MekMEvQo=; b=JAiI9BS75+LzFz+nKH0E+mHe5Z4JKLQtCaJvF2/vTlytJjlkjvM6wdvyf26m97BSLs jfBQos9ufs4Pu38bcByPpyR+i5WeMH6/pwZuU1rPXFpEKIANbmezB+OSWsf1ZQ+qbwSX xoIeMLFHGNKPMDOkJo6ioA40Bp5gmuS44c4a9XYD7LjzNG1e8qKjQ0Vdh4DQy3ctPiLY /K2oDk8RI06Kw4G4NPsORKkVfgZWLXz7IMvJm0/oNaSlydptfQt5ey+4zsnJdfzPb58i gNE6EYk+Eqgt+EoouABRvJ01FgQnIcykce1EGAbVYUIy0om1ldy9bwWpzubFL225dOkk e9Jg== X-Gm-Message-State: AKwxyter72QK0wEJONvAOGIgr9e5+JKQ69fRQ03wV0yabaCKG1aOVOYh pD0IfcYqIi3UZ5BAXrcf7MpWvntp/t4rLG8V0M+6ov58zVY= X-Google-Smtp-Source: AH8x224Xy/+iLmKx95g8uFffDNpdQgRMoRUm2FdNVYMC+E+7RB6cCGHROXEQxCCE9IqTZvicX45DWSFTBSGkaNYitWw= X-Received: by 10.36.73.102 with SMTP id z99mr33903784ita.72.1517324379866; Tue, 30 Jan 2018 06:59:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 30 Jan 2018 06:59:19 -0800 (PST) From: Ian Swett Date: Tue, 30 Jan 2018 09:59:19 -0500 Message-ID: Subject: Registering extensions To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c14e5eac97020563ff9c0e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Jan 2018 15:03:19 -0000 --001a11c14e5eac97020563ff9c0e Content-Type: text/plain; charset="UTF-8" There are two PRs out proposing two different models of extensions. How extensions are registered is largely orthogonal, so I'd like to break that off into a separate discussion. I propose three spaces: 1) Smallest(ie: 0-255) extensions are allocated by the IETF WG 2) Medium(ie: 256-65535) extensions are registered with IANA 3) The rest(ie: 65536+) are registered on a Wiki. This allows room for real experimentation with a very low bar on developers, which is ideal from a software and transport development perspective. I'm open to any reasonable split of the space into three parts, and I'm open to 4 bytes or a 62 bit varint, but I do think we should have >=4 bytes worth of extensions. --001a11c14e5eac97020563ff9c0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    There are two PRs out proposing two different models of ex= tensions.

    How extensions are registered is largely ortho= gonal, so I'd like to break that off into a separate discussion.
    <= div>
    I propose three spaces:
    =C2=A01) Smallest(ie: = 0-255) extensions are allocated by the IETF WG
    =C2=A02) Medium(ie= : 256-65535) extensions are registered with IANA
    =C2=A03) The res= t(ie: 65536+) are registered on a Wiki.

    This allow= s room for real experimentation with a very low bar on developers, which is= ideal from a software and transport development perspective.
    I'm open to any reasonable split of the space into three pa= rts, and I'm open to 4 bytes or a 62 bit varint, but I do think we shou= ld have >=3D4 bytes worth of extensions.
    --001a11c14e5eac97020563ff9c0e-- From nobody Tue Jan 30 08:26:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A1212EC3F for ; Tue, 30 Jan 2018 08:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 AH78qNmgVrFS for ; Tue, 30 Jan 2018 08:26:27 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E98131807 for ; Tue, 30 Jan 2018 08:23:40 -0800 (PST) Received: from BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w0UGNco1014465; Tue, 30 Jan 2018 16:23:38 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1003.national.core.bbc.co.uk ([10.184.50.53]) with mapi id 14.03.0361.001; Tue, 30 Jan 2018 16:23:36 +0000 From: Lucas Pardue To: Ian Swett , IETF QUIC WG Subject: RE: Registering extensions Thread-Topic: Registering extensions Thread-Index: AQHTmdwEtJZq0C/RZ0uxxQZVBJG7QqOMlzXg Date: Tue, 30 Jan 2018 16:23:35 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BACA57C@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.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23632.001 x-tm-as-result: No--17.191000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BACA57Cbgb01xud1012_" 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: Tue, 30 Jan 2018 16:26:29 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BACA57Cbgb01xud1012_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuLA0KDQpUaGVyZSBhcmUgdHdvIFBScyBvdXQgcHJvcG9zaW5nIHR3byBkaWZmZXJlbnQg bW9kZWxzIG9mIGV4dGVuc2lvbnMuDQoNCkhvdyBleHRlbnNpb25zIGFyZSByZWdpc3RlcmVkIGlz IGxhcmdlbHkgb3J0aG9nb25hbCwgc28gSSdkIGxpa2UgdG8gYnJlYWsgdGhhdCBvZmYgaW50byBh IHNlcGFyYXRlIGRpc2N1c3Npb24uDQoNCkNsYXJpZmljYXRpb24gcXVlc3Rpb246IGFyZSB5b3Ug dGFsa2luZyBzcGVjaWZpY2FsbHkgYWJvdXQgUVVJQyBUcmFuc3BvcnQgRXh0ZW5zaW9uIGZyYW1l cz8NCg0KT3BpbmlvbjogSSB0aGluayB0aGVyZSBpcyBhIGRpc3RpbmN0aW9uIHRvIGJlIG1hZGUg YmV0d2VlbiBRVUlDIFRyYW5zcG9ydCBleHRlbnNpb24gYW5kICBIVFRQL1FVSUMgZXh0ZW5zaW9u LCB0aGUgbGF0dGVyIG9mIHdoaWNoIGlzIGJhc2VkIG9uIEhUVFAvMuKAmXMgZXh0ZW5zaW9uIG1v ZGVsLg0KDQpSZWdhcmRzDQpMdWNhcw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpodHRwOi8vd3d3LmJiYy5jby51aw0KVGhpcyBlLW1haWwgKGFuZCBhbnkgYXR0YWNobWVu dHMpIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcGVyc29uYWwgdmlld3Mgd2hpY2gg YXJlIG5vdCB0aGUgdmlld3Mgb2YgdGhlIEJCQyB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC4N CklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGZyb20g eW91ciBzeXN0ZW0uDQpEbyBub3QgdXNlLCBjb3B5IG9yIGRpc2Nsb3NlIHRoZSBpbmZvcm1hdGlv biBpbiBhbnkgd2F5IG5vciBhY3QgaW4gcmVsaWFuY2Ugb24gaXQgYW5kIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5Lg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgQkJDIG1vbml0b3JzIGUtbWFp bHMgc2VudCBvciByZWNlaXZlZC4NCkZ1cnRoZXIgY29tbXVuaWNhdGlvbiB3aWxsIHNpZ25pZnkg eW91ciBjb25zZW50IHRvIHRoaXMuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_7CF7F94CB496BF4FAB1676F375F9666A3BACA57Cbgb01xud1012_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjwhLS0gVGVtcGxhdGUgZ2VuZXJhdGVkIGJ5IEV4Y2xh aW1lciBNYWlsIERpc2NsYWltZXJzIG9uIDA0OjIzOjM2IFR1ZXNkYXksIDMwIEphbnVhcnkgMjAx OCAtLT4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1s OyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+UC4wM2Y3NGEyYS0wZWZj LTQyMDgtYTk5ZC1jZjg2OGExZjliYWEgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkxJLjAz Zjc0YTJhLTBlZmMtNDIwOC1hOTlkLWNmODY4YTFmOWJhYSB7DQoJTUFSR0lOOiAwY20gMGNtIDBw dA0KfQ0KRElWLjAzZjc0YTJhLTBlZmMtNDIwOC1hOTlkLWNmODY4YTFmOWJhYSB7DQoJTUFSR0lO OiAwY20gMGNtIDBwdA0KfQ0KVEFCTEUuMDNmNzRhMmEtMGVmYy00MjA4LWE5OWQtY2Y4NjhhMWY5 YmFhVGFibGUgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQNCn0NCkRJVi5TZWN0aW9uMSB7DQoJcGFn ZTogU2VjdGlvbjENCn0NCjwvc3R5bGU+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9 Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1h dGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8cCBjbGFzcz0iMDNmNzRh MmEtMGVmYy00MjA4LWE5OWQtY2Y4NjhhMWY5YmFhIj48L3A+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5IaSBJYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB0d28gUFJzIG91dCBwcm9wb3NpbmcgdHdvIGRp ZmZlcmVudCBtb2RlbHMgb2YgZXh0ZW5zaW9ucy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBleHRlbnNpb25zIGFyZSByZWdpc3RlcmVkIGlzIGxhcmdl bHkgb3J0aG9nb25hbCwgc28gSSdkIGxpa2UgdG8gYnJlYWsgdGhhdCBvZmYgaW50byBhIHNlcGFy YXRlIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNsYXJpZmljYXRpb24gcXVlc3Rpb246IGFyZSB5b3UgdGFsa2luZyBzcGVjaWZpY2Fs bHkgYWJvdXQgUVVJQyBUcmFuc3BvcnQgRXh0ZW5zaW9uIGZyYW1lcz8NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PcGluaW9uOiBJIHRoaW5rIHRoZXJlIGlzIGEgZGlzdGluY3Rpb24gdG8gYmUg bWFkZSBiZXR3ZWVuIFFVSUMgVHJhbnNwb3J0IGV4dGVuc2lvbiBhbmQgJm5ic3A7SFRUUC9RVUlD IGV4dGVuc2lvbiwgdGhlIGxhdHRlciBvZiB3aGljaCBpcyBiYXNlZCBvbiBIVFRQLzLigJlzIGV4 dGVuc2lvbiBtb2RlbC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkczxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+THVjYXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHA+PC9wPg0KPHAgY2xhc3M9IjAzZjc0YTJhLTBlZmMtNDIwOC1hOTlkLWNmODY4YTFmOWJhYSI+ Jm5ic3A7PC9wPg0KPHAgY2xhc3M9IjAzZjc0YTJhLTBlZmMtNDIwOC1hOTlkLWNmODY4YTFmOWJh YSI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCjxmb250IHNpemU9IjMi IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PGEgaHJlZj0iaHR0cDovL3d3dy5iYmMuY28udWsiIHRh cmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LjxzcGFuIGNsYXNzPSJpbCI+YmJjPC9zcGFuPi48c3Bh biBjbGFzcz0iaWwiPmNvPC9zcGFuPi48c3BhbiBjbGFzcz0iaWwiPnVrPC9zcGFuPjwvYT48YnI+ DQpUaGlzIGUtbWFpbCAoYW5kIGFueSBhdHRhY2htZW50cykgaXMgY29uZmlkZW50aWFsIGFuZCBt YXkgY29udGFpbiBwZXJzb25hbCB2aWV3cyB3aGljaCBhcmUgbm90IHRoZSB2aWV3cyBvZiB0aGUN CjxzcGFuIGNsYXNzPSJpbCI+QkJDPC9zcGFuPiB1bmxlc3Mgc3BlY2lmaWNhbGx5IHN0YXRlZC48 YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBm cm9tIHlvdXIgc3lzdGVtLjxicj4NCkRvIG5vdCB1c2UsIGNvcHkgb3IgZGlzY2xvc2UgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSB3YXkgbm9yIGFjdCBpbiByZWxpYW5jZSBvbiBpdCBhbmQgbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkuPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCB0aGUgPHNwYW4g Y2xhc3M9ImlsIj5CQkM8L3NwYW4+IG1vbml0b3JzIGUtbWFpbHMgc2VudCBvciByZWNlaXZlZC48 YnI+DQpGdXJ0aGVyIGNvbW11bmljYXRpb24gd2lsbCBzaWduaWZ5IHlvdXIgY29uc2VudCB0byB0 aGlzLjwvZm9udD48L2ZvbnQ+PC9mb250PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iMDNmNzRhMmEt MGVmYy00MjA4LWE5OWQtY2Y4NjhhMWY5YmFhIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS08L3A+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_7CF7F94CB496BF4FAB1676F375F9666A3BACA57Cbgb01xud1012_-- From nobody Tue Jan 30 09:03:27 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F1A12EBB5 for ; Tue, 30 Jan 2018 09:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7cj1k88ZJ_C5 for ; Tue, 30 Jan 2018 09:03:24 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D1B12D77C for ; Tue, 30 Jan 2018 09:03:24 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id 68so1348268ite.4 for ; Tue, 30 Jan 2018 09:03:24 -0800 (PST) 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=8bil4g38cdz/AljI9Av7k9eYU29/eKlI114+GIiXlpc=; b=W/D7PE5SpX04I4k/kmubJpqzr9JTmQVZrcWa8eXP1XA/hXyiMWdgYIJf+cMq6CiE1h RyjDE47GfzBbUgtAPe6QS44/GCJlikK9/vOLMwnV5QDg0014ug9leZJfe/PbjVirCqOh iNWyqqsMQTAlgvNpblWa/PL3BMQz7t8r/fxswYREKLO0dxBzwg604SqinxcTMWsPANC2 +wPFIFWSpyZ1MSqH4/tUZNJXexuFnraB0xmxHqCTlNUVlKGLKdXq8lu6bsLXExZrX1X9 +j1EbksnTmYtUhRlTgCol2iLkP2kKeW7uHAQd2Kk0GxTVn7x/XgU+yc9Ywei/o3YcWwz HNQw== 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=8bil4g38cdz/AljI9Av7k9eYU29/eKlI114+GIiXlpc=; b=dr+FDvCEGnoLCyVr0DiDPNRNKOippmnb/1bqSEB8Dl5Vh4UhJoq1cLt7YAcilyEFX6 RkzVeBh5U37FDT6xE/SvXIhja7aDzmxkyMrgSP9BTXWWREr8HWMkgq4yHp6BSS4hEFV2 oXgNeHfHH143Xafz6ongAJGMEG3mrnh9nYEkm5xRpuzWTK0QW7m+fi2yYWjDmZgrUjgL 6yHuWYn2dGPsGG+bf4Rf5PbposWE4qrq7jHe2CoEmU+fu7iPDIPIbjbXc8jrl7bAjUX3 fX7u5oe6yYhfLgtm+LeoMXuX4F1up0upuiGblM3NX4N4jZ3x/ZEcBqM+uMP17cQUj1cj Uf9Q== X-Gm-Message-State: AKwxyteXeejPH7yclWR8RTM0m+wnaEcCAmQR+NPkI3cIANxRWPJD42he 6inwMACbiNvRJZs67rx0eYhpssTHeJPTHTMJdCdWUxqj X-Google-Smtp-Source: AH8x22610iM7rYmhRSCsVRhxE57xaEei2tQmgjbyNK9dBv5Ews8v4G0PW9v9rl5krVFykNEfEPSJYWBWd14FIfTUlsg= X-Received: by 10.36.73.102 with SMTP id z99mr34462837ita.72.1517331803495; Tue, 30 Jan 2018 09:03:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 30 Jan 2018 09:03:02 -0800 (PST) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BACA57C@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BACA57C@bgb01xud1012> From: Ian Swett Date: Tue, 30 Jan 2018 12:03:02 -0500 Message-ID: Subject: Re: Registering extensions To: Lucas Pardue Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c14e5e28192805640157ba" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Jan 2018 17:03:26 -0000 --001a11c14e5e28192805640157ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good question, I was thinking transport extensions. As you said, I expect HTTP/QUIC extensions to rely on an HTTP/2 style extension model. On Tue, Jan 30, 2018 at 11:23 AM, Lucas Pardue wrote: > Hi Ian, > > > > There are two PRs out proposing two different models of extensions. > > > > How extensions are registered is largely orthogonal, so I'd like to break > that off into a separate discussion. > > > > Clarification question: are you talking specifically about QUIC Transport > Extension frames? > > > > Opinion: I think there is a distinction to be made between QUIC Transport > extension and HTTP/QUIC extension, the latter of which is based on > HTTP/2=E2=80=99s extension model. > > > > Regards > > Lucas > > > > ---------------------------- > > http://www.bbc.co.uk > This e-mail (and any attachments) is confidential and may contain persona= l > 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. > > --------------------- > --001a11c14e5e28192805640157ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Good question, I was thinking transport extensions.=C2=A0 = As you said, I expect HTTP/QUIC extensions to rely on an HTTP/2 style exten= sion model.

    = On Tue, Jan 30, 2018 at 11:23 AM, Lucas Pardue <Lucas.Pardue@bbc.co.u= k> wrote:

    Hi Ian,

    =C2=A0

    There are two PRs out proposing two different models= of extensions.

    =C2=A0

    How extensions are registered is largely orthogonal,= so I'd like to break that off into a separate discussion.

    =C2=A0

    Clarification question: are you talking speci= fically about QUIC Transport Extension frames?

    =C2=A0

    Opinion: I think there is a distinction to be made b= etween QUIC Transport extension and =C2=A0HTTP/QUIC extension, the latter o= f which is based on HTTP/2=E2=80=99s extension model.

    =C2=A0

    Regards

    Lucas

    =C2= =A0

    ----= ------------------------

    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 stat= ed.
    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 mon= itors e-mails sent or received.
    Further communication will signify your consent to this.

    ----= -----------------


    --001a11c14e5e28192805640157ba-- From nobody Tue Jan 30 12:32:46 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B8412FA9D for ; Tue, 30 Jan 2018 12:32:44 -0800 (PST) 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 QPZH0dfCk__u for ; Tue, 30 Jan 2018 12:32:41 -0800 (PST) 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 C395512EB09 for ; Tue, 30 Jan 2018 12:32:40 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id j128so5779238ywg.7 for ; Tue, 30 Jan 2018 12:32:40 -0800 (PST) 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=ej6/Tn9gDQ8g6FaEHFKh+YbzpdFN0uwKJUsXt9E7MfU=; b=MxRbKPbrb/9C72xgs7tUEJXCk0Vkc05HQoXlKv8Z+C5XxJ8OTi5B9GFjbG56EBSKUg lG8MeoDDqjpGKmHNhmbyiOKm9G7NUUeATMUwQH3LRSifJ69J6a5rFB2PvFvw59aYOOKN 85D3oW26fI0UBktyqD/5gJxuYaemrPPlis7mBlLD7azwwdqbdvabiB+wrmPfRzx0GeLR /nON/D1OEowI266ivlj/S5X/iKe64vrZ5J3EcQ+cfZVdhe1fF1BP31RXVUdPRXLPZE9W /yY0IOLHGKxz+LaDD+Rw0JxTdA9KHiqUWgTejRT/JIGL1ic8rCFiMmM1CAGxEUtAV068 r8OQ== 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=ej6/Tn9gDQ8g6FaEHFKh+YbzpdFN0uwKJUsXt9E7MfU=; b=I8Sf51uCvVJDszZXvWEKzQy+cdxpS6BkOMMp7keAInmHTPqMDE+rRw/RW5LtorZcZJ juMkTn/zF+qeX3gjncgyCG1pB9MMN5VYpCRLZKMsoA5do/zB9Ou2cqx9JfNKYg4raWKB Bku1xvtu/LdMlo0J8coMNHqpoYJsauDuj+ovlaRz8yZmxV9dtQkqzo5oqDSgIO1YTZdK /dMBef7Bu7hPWUSLB32+JtU6SDvH4ye/Uio3/1UyL2Jy7kkXEJMMpDhfgLvgI+KGPuYO eR3koU+iEbtvinZUe+5MqJyL5JYebcAJ2a0SDm1lA9ZyFHchKFw4CaSiIk7pXRqOmAmt 3s3A== X-Gm-Message-State: AKwxyte2nzNs8FuLspMxYnDru3i+do5yDfQeudv6RvSSax+ZUXsc45H4 d4Qx4CzgRYQyJCgGRssiG5GjIb7GXTtAx4ZqucLDTw== X-Google-Smtp-Source: AH8x225HhLE+L6+R9Y4CsPkMq7Q1ugdJQsFseDOcl+uOWaE2Ap17bb+DoxYJxmQUosIQTa+4WTm8E6nkpdGvwlMaWjQ= X-Received: by 10.37.183.210 with SMTP id u18mr21385325ybj.416.1517344359664; Tue, 30 Jan 2018 12:32:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Tue, 30 Jan 2018 12:31:59 -0800 (PST) In-Reply-To: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> From: Eric Rescorla Date: Tue, 30 Jan 2018 12:31:59 -0800 Message-ID: Subject: Re: Packet number encryption To: Brian Trammell Cc: QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="089e0822ab5c8f62210564044399" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Jan 2018 20:32:44 -0000 --089e0822ab5c8f62210564044399 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell wrote: > hi Martin, > > Thanks for the PR. > > > On 30 Jan 2018, at 01:59, Martin Thomson > wrote: > > > > Here's a PR: > > > > https://github.com/quicwg/base-drafts/pull/1079 > > > > In short, this builds on Kazuho's excellent suggestion to use ECB-mode > > to protect the packet number. It does this only slightly differently, > > using suggestions from ekr and others to allow for cryptographic > > agility and use of primitives that match the negotiated AEAD. > > > > In short, it takes some of the ciphertext of the packet payload, and > > uses that to encipher the packet number. My intuition is that this is > > pretty solid, but I want to check if the working group is happy that > > this is generally OK before seeking cryptographic review. > > > > For instance, the requirement for side-channel resistance is already > > controversial: https://github.com/quicwg/base-drafts/pull/1079/files# > r164588705 > > > > For the record, I doubt that this can be proven to be secure without > > both breaking new ground and adding some constraints to the AEADs that > > we use. And that's before we get into actual breaks on the technique > > that I'm too thick-headed to think of. In any case, we're relying on > > this to protect against linkability, so I'd like to ensure that we're > > not completely crazy in doing so. > > I'm not sure this isn't completely crazy. > > Our model for linkage attacks seems a little too fuzzy to me to be useful > for evaluating whether this proposal is an improvement on the status quo. > Of course, there's an inherent tension among the identifiability of flows > by 5-tuple, the explicit identifiability of flows by CID (which we'll work > to remedy at the same time as we stick more bits in the CID, apparently), > and the desire for two independent 5-tuple flows to remain unlinkable. So > this is inherently hard, because we don't have internally consistent set of > requirements for linkability support and avoidance. > > Beyond this, though, we need to have a coherent idea of what we're trying > to prevent. From discussions to date, I think these are the two cases we > care about: > > (1) An unprivileged on-path device that sees a packet from a flow that is > migrated on purpose by an endpoint (i.e., due to connection migration or > multipath) should not be able to associate that packet to the prior flow. > > (2) An unprivileged on-path device that sees a packet from a flow that is > unintentionally migrated (i.e., one of its globally routable addresses > changes without the associated endpoint's knowledge) should not be able to > associate that packet to the prior flow. > > In the presence of any connection ID that has enough entropy to be used > for load balancing, linkability avoidance in case 2 is impossible. Indeed, > the CID exists in part to *allow* linkability in case 2. Any packet number > encryption approach is necessarily useless for linkability avoidance in > this case, unless the CID is also protected with a secret known only to the > endpoints and the load-balancer. We'll see where the CID DT lands here. > > When the connection ID is absent or protected, and the packet number is > encrypted, case 2 is still problematic. In an unintentional migration, only > two values in the five-tuple change, and it's impossible to make the first > packet sent from the migrated endpoint to the non-migrated endpoint look > like a handshake packet. So to find an unintentional migration, an observer > only needs to look for all flows toward a 3-tuple without being preceded by > a valid handshake that started within 30 seconds of another one ending on > the same 3-tuple. Even for very large load balancers, this is not a giant > anonymity set. > > If you believe that greasing functions over packet numbers is necessary -- > I'm not sure I do, but that's a different, future message -- then this > proposal might be useful for that, but if linkability prevention is the > goal, I'm not convinced it's fit for purpose. > > This proposal also opens a trivial class of wasted-work attacks against > QUIC servers by malicious clients, which can now craft packets which will > require the server to partially decrypt them before realizing they're not > useful. Obviously bad packet numbers can be avoided with simple heuristics. > Less-obvious attacks might be crafted to incur significant nonproductive > cost on the server side. This seems to be an unavoidable property of any > approach to packet number encryption that would actually work, though, so > that's not an observation about this specific proposal. I also haven't done > the analysis to see if this is all that bad. > Why isn't this already the case? I just take a valid packet, change a bit in the MAC, and resend it a bunch of times. -Ekr > Note as well that this proposal comes with a manageability cost. On-path > measurement of upstream loss and reordering would become impossible, and > the fidelity of the spin bit under loss and reordering would be reduced. > > > In case people were wondering, and because it already came up: I > > intend to separately propose a change to the short header packet that > > would remove the type field and move the packet number length under > > encryption. See my response to Ian's question on the PR for an > > explanation of how this will likely work. > > Yep, this makes sense. We'll need to consider these changes closely in > concert with any change to the CID. As above, avoiding linkability with PN > encryption while aiding it with a CID is hard, and a varlen CID plus a > varint encrypted PN will make parsing fiddlier than it already is. > > As Christian noted, using the short header type field to provide a sort of > subsequence number or other packet-number independent explicit signal would > mitigate the damage packet number encryption would to do loss and > reordering observability, but not completely address them. > > Cheers, > > Brian > > --089e0822ab5c8f62210564044399 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:
    hi Martin,

    Thanks for the PR.

    > On 30 Jan 2018, at 01:59, Martin Thomson <martin.thomson@gmail.com> wrote:
    >
    > Here's a PR:
    >
    > https://github.com/quicwg/base-drafts/pull/= 1079
    >
    > In short, this builds on Kazuho's excellent suggestion to use ECB-= mode
    > to protect the packet number.=C2=A0 It does this only slightly differe= ntly,
    > using suggestions from ekr and others to allow for cryptographic
    > agility and use of primitives that match the negotiated AEAD.
    >
    > In short, it takes some of the ciphertext of the packet payload, and > uses that to encipher the packet number.=C2=A0 My intuition is that th= is is
    > pretty solid, but I want to check if the working group is happy that > this is generally OK before seeking cryptographic review.
    >
    > For instance, the requirement for side-channel resistance is already > controversial: https://github.c= om/quicwg/base-drafts/pull/1079/files#r164588705
    >
    > For the record, I doubt that this can be proven to be secure without > both breaking new ground and adding some constraints to the AEADs that=
    > we use.=C2=A0 And that's before we get into actual breaks on the t= echnique
    > that I'm too thick-headed to think of.=C2=A0 In any case, we'r= e relying on
    > this to protect against linkability, so I'd like to ensure that we= 're
    > not completely crazy in doing so.

    I'm not sure this isn't completely crazy.

    Our model for linkage attacks seems a little too fuzzy to me to be useful f= or evaluating whether this proposal is an improvement on the status quo. Of= course, there's an inherent tension among the identifiability of flows= by 5-tuple, the explicit identifiability of flows by CID (which we'll = work to remedy at the same time as we stick more bits in the CID, apparentl= y), and the desire for two independent 5-tuple flows to remain unlinkable. = So this is inherently hard, because we don't have internally consistent= set of requirements for linkability support and avoidance.

    Beyond this, though, we need to have a coherent idea of what we're tryi= ng to prevent. From discussions to date, I think these are the two cases we= care about:

    (1) An unprivileged on-path device that sees a packet from a flow that is m= igrated on purpose by an endpoint (i.e., due to connection migration or mul= tipath) should not be able to associate that packet to the prior flow.

    (2) An unprivileged on-path device that sees a packet from a flow that is u= nintentionally migrated (i.e., one of its globally routable addresses chang= es without the associated endpoint's knowledge) should not be able to a= ssociate that packet to the prior flow.

    In the presence of any connection ID that has enough entropy to be used for= load balancing, linkability avoidance in case 2 is impossible. Indeed, the= CID exists in part to *allow* linkability in case 2. Any packet number enc= ryption approach is necessarily useless for linkability avoidance in this c= ase, unless the CID is also protected with a secret known only to the endpo= ints and the load-balancer. We'll see where the CID DT lands here.

    When the connection ID is absent or protected, and the packet number is enc= rypted, case 2 is still problematic. In an unintentional migration, only tw= o values in the five-tuple change, and it's impossible to make the firs= t packet sent from the migrated endpoint to the non-migrated endpoint look = like a handshake packet. So to find an unintentional migration, an observer= only needs to look for all flows toward a 3-tuple without being preceded b= y a valid handshake that started within 30 seconds of another one ending on= the same 3-tuple. Even for very large load balancers, this is not a giant = anonymity set.

    If you believe that greasing functions over packet numbers is necessary -- = I'm not sure I do, but that's a different, future message -- then t= his proposal might be useful for that, but if linkability prevention is the= goal, I'm not convinced it's fit for purpose.

    This proposal also opens a trivial class of wasted-work attacks against QUI= C servers by malicious clients, which can now craft packets which will requ= ire the server to partially decrypt them before realizing they're not u= seful. Obviously bad packet numbers can be avoided with simple heuristics. = Less-obvious attacks might be crafted to incur significant nonproductive co= st on the server side. This seems to be an unavoidable property of any appr= oach to packet number encryption that would actually work, though, so that&= #39;s not an observation about this specific proposal. I also haven't d= one the analysis to see if this is all that bad.

    <= /div>
    Why isn't this already the case? I just take a valid packet, = change a bit in the MAC, and resend it a bunch of times.

    -Ekr


    Note as well that this proposal comes with a manageability cost. On-path me= asurement of upstream loss and reordering would become impossible, and the = fidelity of the spin bit under loss and reordering would be reduced.

    > In case people were wondering, and because it already came up: I
    > intend to separately propose a change to the short header packet that<= br> > would remove the type field and move the packet number length under > encryption.=C2=A0 See my response to Ian's question on the PR for = an
    > explanation of how this will likely work.

    Yep, this makes sense. We'll need to consider these changes clos= ely in concert with any change to the CID. As above, avoiding linkability w= ith PN encryption while aiding it with a CID is hard, and a varlen CID plus= a varint encrypted PN will make parsing fiddlier than it already is.

    As Christian noted, using the short header type field to provide a sort of = subsequence number or other packet-number independent explicit signal would= mitigate the damage packet number encryption would to do loss and reorderi= ng observability, but not completely address them.

    Cheers,

    Brian


    --089e0822ab5c8f62210564044399-- From nobody Tue Jan 30 13:01:14 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC319126C3D for ; Tue, 30 Jan 2018 13:01:11 -0800 (PST) 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 K5iL_uwRPNvs for ; Tue, 30 Jan 2018 13:01:09 -0800 (PST) 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 3D5B5126C83 for ; Tue, 30 Jan 2018 13:01:09 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx18.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1egd1Y-00049f-3n for quic@ietf.org; Tue, 30 Jan 2018 22:01:06 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1egd1T-00023P-JZ for quic@ietf.org; Tue, 30 Jan 2018 16:00:59 -0500 Received: (qmail 4995 invoked from network); 30 Jan 2018 21:00:54 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jan 2018 21:00:53 -0000 To: Eric Rescorla , Brian Trammell References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> Cc: QUIC WG , Martin Thomson From: Christian Huitema Message-ID: <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> Date: Tue, 30 Jan 2018 11:00:54 -1000 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="------------2137470FCDF6842B8EB0036B" Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pyip6Kn0EKfLGbCBLMcDQIXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fte8RiINThtifjQGcKGwAj4B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYc8zYOZy1SS6ohN09nxrcu5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIx4AXarfh1O38bAuuIRigglQLLoevXSDb45gXomrF uFOyMgu/VzoqvLoDTP7eHxPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATvFVVOfJAYdBTniKgyyo60ONoJfh+XjGSeeT90H/uIG/ 3wQWvbZi3XZTBukuI2KKDNoFafZX+BQvtelCkij2VWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWi2LEHF33nMCnEPdDBPtPg/fFcHV2tQAVqGdj/zM7G/G3L31QGIB1LDs8uX49JL/W5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 21:01:12 -0000 This is a multi-part message in MIME format. --------------2137470FCDF6842B8EB0036B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 1/30/2018 10:31 AM, Eric Rescorla wrote: > > > On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell > wrote: > > hi Martin, > ... > I'm not sure this isn't completely crazy. > I think this beats the alternatives, either complex-but-fragile obfuscation schemes, or separate per-path encryption contexts. Also, I like that this is somewhat future-proof -- it allows building future multipath extension at an almost minimal cost. > ... > Beyond this, though, we need to have a coherent idea of what we're > trying to prevent. From discussions to date, I think these are the > two cases we care about: > > (1) An unprivileged on-path device that sees a packet from a flow > that is migrated on purpose by an endpoint (i.e., due to > connection migration or multipath) should not be able to associate > that packet to the prior flow. > Yes. > > (2) An unprivileged on-path device that sees a packet from a flow > that is unintentionally migrated (i.e., one of its globally > routable addresses changes without the associated endpoint's > knowledge) should not be able to associate that packet to the > prior flow. > No. That one can only be solved through a voluntary action from the sender. If the client is in the middle of sending a stream, correlation is trivial whatever we do. There are however two plausible improvements: a) Explicit migration after signalling by the NAT box. We would need some new protocol to do that, maybe ICMP based. It could work in the "mobile router" case. b) Opportunistic migration out of quiescence. NAT rebinding typically happen after a period of silence. Clients that just start sending after a long silence may decide to "simulate a migration", to break the correlation. Both of these improvements will benefit from packet number encryption. > ... > > As Christian noted, using the short header type field to provide a > sort of subsequence number or other packet-number independent > explicit signal would mitigate the damage packet number encryption > would to do loss and reordering observability, but not completely > address them. > Yes. We have to be serious about network manageability. There has to be a sweet spot between expose everything so network management sees it and encrypt everything so middle boxes do not breach privacy or ossify the protocol. I think tricks like the spin bit and/or a small-modulo sequence number may be close to that sweet spot. Part of me would want to see these spin bit and small modulo sequence number down in the IP header. That would look like a very nice use of the IPv6 flow-ID. Wouldn't it be nice if network management was based on the network header? But failing that, maybe we need to start something in QUIC. -- Christian Huitema --------------2137470FCDF6842B8EB0036B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



    On 1/30/2018 10:31 AM, Eric Rescorla wrote:


    On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell <ietf@trammell.ch> wrote:
    hi Martin,
    ...
    I'm not sure this isn't completely crazy.

    I think this beats the alternatives, either complex-but-fragile obfuscation schemes, or separate per-path encryption contexts. Also, I like that this is somewhat future-proof -- it allows building future multipath extension at an almost minimal cost.


    ...
    Beyond this, though, we need to have a coherent idea of what we're trying to prevent. From discussions to date, I think these are the two cases we care about:

    (1) An unprivileged on-path device that sees a packet from a flow that is migrated on purpose by an endpoint (i.e., due to connection migration or multipath) should not be able to associate that packet to the prior flow.

    Yes.


    (2) An unprivileged on-path device that sees a packet from a flow that is unintentionally migrated (i.e., one of its globally routable addresses changes without the associated endpoint's knowledge) should not be able to associate that packet to the prior flow.

    No. That one can only be solved through a voluntary action from the sender. If the client is in the middle of sending a stream, correlation is trivial whatever we do. There are however two plausible improvements:

    a) Explicit migration after signalling by the NAT box. We would need some new protocol to do that, maybe ICMP based. It could work in the "mobile router" case.

    b) Opportunistic migration out of quiescence. NAT rebinding typically happen after a period of silence. Clients that just start sending after a long silence may decide to "simulate a migration", to break the correlation.

    Both of these improvements will benefit from packet number encryption.

    ...
    As Christian noted, using the short header type field to provide a sort of subsequence number or other packet-number independent explicit signal would mitigate the damage packet number encryption would to do loss and reordering observability, but not completely address them.

    Yes. We have to be serious about network manageability. There has to be a sweet spot between expose everything so network management sees it and encrypt everything so middle boxes do not breach privacy or ossify the protocol. I think tricks like the spin bit and/or a small-modulo sequence number may be close to that sweet spot.

    Part of me would want to see these spin bit and small modulo sequence number down in the IP header. That would look like a very nice use of the IPv6 flow-ID. Wouldn't it be nice if network management was based on the network header? But failing that, maybe we need to start something in QUIC.

    -- Christian Huitema


    --------------2137470FCDF6842B8EB0036B-- From nobody Tue Jan 30 20:08:31 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928E41314EB for ; Tue, 30 Jan 2018 20:08:29 -0800 (PST) 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 K8_vUgC1zAYt for ; Tue, 30 Jan 2018 20:08:27 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 5ABC9127444 for ; Tue, 30 Jan 2018 20:08:27 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id d9so12143714oth.6 for ; Tue, 30 Jan 2018 20:08:27 -0800 (PST) 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=mvxPBvr368vqazouxkj8V2R1fgI4y/EDqOjJFlTTRlA=; b=sBVfn7O0FZFcl+yYp95V8o8zLAC4FgInUk9NTVEL2T4wdL7LEO6vLWKK3Jos+7DiaT 4GmPpK5rmk6V4Pmtc22WXXAxrcQtoJ9TeJEGC2x2WtSDGCKeF5abKET35yephiF3vpDO rlc3FRkYYFNM9EE9WKLzP4YWBAgtCUnoEA8Mog42KLCje7b1QipVTcmeUWY8132FArTl t/ASvHKnknDfhZaWmeD/WS3O2Wlfj2pBRL245WNZlZnmtXxbO+DDke4awjaoeL18SZm+ xIYMquWXCDFInC/G2nJhXoVPDgLd7XuuG+w0OzrehR5o3zhrQ46tH4xaKyQgSguwqbAO 3C4Q== 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=mvxPBvr368vqazouxkj8V2R1fgI4y/EDqOjJFlTTRlA=; b=d62sjNpfDbWpO4/7zPgykCXWh27kRlTE4ab2D8EppgWvO6f8GkaUdjcJOWWLsUlQ5D tu73VLHRCImtr0MCGvLQduYY4YH5j7T8aDgZStNDC1+PUE0IVMFm2o8yyeyN1NL/2XOO e9u2N6SpWv5SAaTSCWR9k2ffbDaWJICm2DlcMiiaeS5Lr7zd++EK9tDFQzgvP9Ms/0K2 hR3ULLeTb4HKsvWDEJ1+YyLEw21v0uc3glUZB2I/q/hurOlZwxasORi2On8HT4nwmO1Y 7lesY5SFIM8fXsn43+VrwHzCtbuGBk0TvwF6t9qOSFA7uO1g938qc6nMdW4NBgwpNIuM LhaQ== X-Gm-Message-State: AKwxytfh9W2smRQ4pOLQGnCa611uuHRKWPKqaT2F/weucNScTJ1z494h 9mdVpol9+Vfknc5NrK7c9PaIB8rSsXLaVM1ZWtg= X-Google-Smtp-Source: AH8x224DMtVfcFgsQKSknniJdPGqAkam4y7xkaiCY9YGkKdyrD6OWCxw1CNuIpMiFTrOiiUpS0FTVLp678kpzOm+Y2Q= X-Received: by 10.157.36.137 with SMTP id z9mr1770498ota.175.1517371706357; Tue, 30 Jan 2018 20:08:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Tue, 30 Jan 2018 20:08:25 -0800 (PST) In-Reply-To: <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> From: Martin Thomson Date: Wed, 31 Jan 2018 15:08:25 +1100 Message-ID: Subject: Re: Packet number encryption To: Christian Huitema Cc: Eric Rescorla , Brian Trammell , 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, 31 Jan 2018 04:08:30 -0000 On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema wrote: >> (1) An unprivileged on-path device that sees a packet from a flow that is >> migrated on purpose by an endpoint (i.e., due to connection migration or >> multipath) should not be able to associate that packet to the prior flow. > > Yes. Agreed. This remains the primary target. I don't think that there are any negatives with this design with respect to this use case (or at least I found nothing in Brian's email on this point). >> (2) An unprivileged on-path device that sees a packet from a flow that is >> unintentionally migrated (i.e., one of its globally routable addresses >> changes without the associated endpoint's knowledge) should not be able to >> associate that packet to the prior flow. > > No. That one can only be solved through a voluntary action from the sender. > If the client is in the middle of sending a stream, correlation is trivial > whatever we do. This might not be entirely true. In the current design, a client can opt out and refuse to send a connection ID even if the server wants one. However, I suspect that all you will get in that case is failure. Success would only be possible if a server used 5 tuple as its primary way of identifying connections, and it seems like we'll see that happen very rarely. The connection ID bit in the short header is a design point that I intend to address when the larger/variable-length connection ID changes come in. > There are however two plausible improvements: > > a) Explicit migration after signalling by the NAT box. We would need some > new protocol to do that, maybe ICMP based. It could work in the "mobile > router" case. This seems a little hopeful to me. Also, I can imagine a NAT dropping packets to "save" clients from exposing session continuity. I don't really want to see that sort of NAT feature being deployed. These boxes are already hard enough to deal with. > b) Opportunistic migration out of quiescence. NAT rebinding typically happen > after a period of silence. Clients that just start sending after a long > silence may decide to "simulate a migration", to break the correlation. This is what I have always assumed. Maybe we should write that little tip down. Doing so might increase the demand on new connection IDs so that those who actually need to use them will find that they are usable. https://github.com/quicwg/base-drafts/issues/1087 From nobody Tue Jan 30 23:44:48 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC9812F4C5 for ; Tue, 30 Jan 2018 23:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 1GjUfxhHpS55 for ; Tue, 30 Jan 2018 23:44:44 -0800 (PST) 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 77E48131962 for ; Tue, 30 Jan 2018 23:44:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zWZyg0kDsz15N8b; Wed, 31 Jan 2018 08:44:43 +0100 (CET) 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 mTEMfu5hWQ7M; Wed, 31 Jan 2018 08:44:41 +0100 (CET) X-MtScore: NO score=0 Received: from [172.20.10.5] (ip-109-40-2-39.web.vodafone.de [109.40.2.39]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 31 Jan 2018 08:44:40 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 31 Jan 2018 07:44:32 +0000 Cc: Christian Huitema , Brian Trammell , Eric Rescorla , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Jan 2018 07:44:47 -0000 > Am 31.01.2018 um 04:08 schrieb Martin Thomson = : >=20 > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema = wrote: >>> (1) An unprivileged on-path device that sees a packet from a flow = that is >>> migrated on purpose by an endpoint (i.e., due to connection = migration or >>> multipath) should not be able to associate that packet to the prior = flow. >>=20 >> Yes. >=20 > Agreed. This remains the primary target. I don't think that there > are any negatives with this design with respect to this use case (or > at least I found nothing in Brian's email on this point). If that is the goal, I think the complexity of the proposed solution is = not justified. Just select a new random offset when you migrate but = increase the packet number monotonously otherwise to support = manageability. I=E2=80=99m really concerned about complexity here. Even though this = scheme is not very complex, any complexity is a potential source for = future implementation errors which can also led to restrictions in what = changes can be deploy with future versions. Making a protocol as simple = as possible and thereby the spec as easy understandable as possible is = also key for deployment. If we add complexity here without making it = clear what the goal or additional benefit is of the complexity, I think = that is just wrong. My 2c. Mirja From nobody Wed Jan 31 01:57:26 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A409131738 for ; Wed, 31 Jan 2018 01:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 CzFYL6X-a-oi for ; Wed, 31 Jan 2018 01:57:18 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA7D131AE3 for ; Wed, 31 Jan 2018 01:53:09 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id EEA2A1B0016A; Wed, 31 Jan 2018 09:52:30 +0000 (GMT) Message-ID: <5A7191E0.6010003@erg.abdn.ac.uk> Date: Wed, 31 Jan 2018 09:52:32 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: Martin Thomson , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Subject: Re: Packet number encryption References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 09:57:25 -0000 +1 - Simply: This *is* complicated and seems to add little. Gorry On 31/01/2018, 07:44, Mirja Kühlewind wrote: > >> Am 31.01.2018 um 04:08 schrieb Martin Thomson: >> >> On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema wrote: >>>> (1) An unprivileged on-path device that sees a packet from a flow that is >>>> migrated on purpose by an endpoint (i.e., due to connection migration or >>>> multipath) should not be able to associate that packet to the prior flow. >>> Yes. >> Agreed. This remains the primary target. I don't think that there >> are any negatives with this design with respect to this use case (or >> at least I found nothing in Brian's email on this point). > If that is the goal, I think the complexity of the proposed solution is not justified. Just select a new random offset when you migrate but increase the packet number monotonously otherwise to support manageability. > > I’m really concerned about complexity here. Even though this scheme is not very complex, any complexity is a potential source for future implementation errors which can also led to restrictions in what changes can be deploy with future versions. Making a protocol as simple as possible and thereby the spec as easy understandable as possible is also key for deployment. If we add complexity here without making it clear what the goal or additional benefit is of the complexity, I think that is just wrong. > > My 2c. > Mirja From nobody Wed Jan 31 01:59:56 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06264131B9C for ; Wed, 31 Jan 2018 01:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_TP6CJnJB6r for ; Wed, 31 Jan 2018 01:59:50 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B41131AEA for ; Wed, 31 Jan 2018 01:54:54 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB38340EA6; Wed, 31 Jan 2018 10:54:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.6029); Wed, 31 Jan 2018 10:54:50 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 31 Jan 2018 10:54:49 +0100 (CET) Received: from [81.134.152.4] (account ietf@trammell.ch HELO [172.18.9.171]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43870581; Wed, 31 Jan 2018 10:54:49 +0100 From: "Brian Trammell (IETF)" Message-Id: <07021975-8E71-4602-A98B-27E33DAE6A28@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_F2A7FFDB-AE84-4B0D-92F0-C070E221BA60"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Wed, 31 Jan 2018 09:54:51 +0000 In-Reply-To: Cc: QUIC WG , Martin Thomson To: Eric Rescorla References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> 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, 31 Jan 2018 09:59:55 -0000 --Apple-Mail=_F2A7FFDB-AE84-4B0D-92F0-C070E221BA60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Jan 2018, at 20:31, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell = wrote: > hi Martin, >=20 > Thanks for the PR. >=20 > > On 30 Jan 2018, at 01:59, Martin Thomson = wrote: > > > > Here's a PR: > > > > https://github.com/quicwg/base-drafts/pull/1079 > > > > In short, this builds on Kazuho's excellent suggestion to use = ECB-mode > > to protect the packet number. It does this only slightly = differently, > > using suggestions from ekr and others to allow for cryptographic > > agility and use of primitives that match the negotiated AEAD. > > > > In short, it takes some of the ciphertext of the packet payload, and > > uses that to encipher the packet number. My intuition is that this = is > > pretty solid, but I want to check if the working group is happy that > > this is generally OK before seeking cryptographic review. > > > > For instance, the requirement for side-channel resistance is already > > controversial: = https://github.com/quicwg/base-drafts/pull/1079/files#r164588705 > > > > For the record, I doubt that this can be proven to be secure without > > both breaking new ground and adding some constraints to the AEADs = that > > we use. And that's before we get into actual breaks on the = technique > > that I'm too thick-headed to think of. In any case, we're relying = on > > this to protect against linkability, so I'd like to ensure that = we're > > not completely crazy in doing so. >=20 > I'm not sure this isn't completely crazy. >=20 > Our model for linkage attacks seems a little too fuzzy to me to be = useful for evaluating whether this proposal is an improvement on the = status quo. Of course, there's an inherent tension among the = identifiability of flows by 5-tuple, the explicit identifiability of = flows by CID (which we'll work to remedy at the same time as we stick = more bits in the CID, apparently), and the desire for two independent = 5-tuple flows to remain unlinkable. So this is inherently hard, because = we don't have internally consistent set of requirements for linkability = support and avoidance. >=20 > Beyond this, though, we need to have a coherent idea of what we're = trying to prevent. =46rom discussions to date, I think these are the two = cases we care about: >=20 > (1) An unprivileged on-path device that sees a packet from a flow that = is migrated on purpose by an endpoint (i.e., due to connection migration = or multipath) should not be able to associate that packet to the prior = flow. >=20 > (2) An unprivileged on-path device that sees a packet from a flow that = is unintentionally migrated (i.e., one of its globally routable = addresses changes without the associated endpoint's knowledge) should = not be able to associate that packet to the prior flow. >=20 > In the presence of any connection ID that has enough entropy to be = used for load balancing, linkability avoidance in case 2 is impossible. = Indeed, the CID exists in part to *allow* linkability in case 2. Any = packet number encryption approach is necessarily useless for linkability = avoidance in this case, unless the CID is also protected with a secret = known only to the endpoints and the load-balancer. We'll see where the = CID DT lands here. >=20 > When the connection ID is absent or protected, and the packet number = is encrypted, case 2 is still problematic. In an unintentional = migration, only two values in the five-tuple change, and it's impossible = to make the first packet sent from the migrated endpoint to the = non-migrated endpoint look like a handshake packet. So to find an = unintentional migration, an observer only needs to look for all flows = toward a 3-tuple without being preceded by a valid handshake that = started within 30 seconds of another one ending on the same 3-tuple. = Even for very large load balancers, this is not a giant anonymity set. >=20 > If you believe that greasing functions over packet numbers is = necessary -- I'm not sure I do, but that's a different, future message = -- then this proposal might be useful for that, but if linkability = prevention is the goal, I'm not convinced it's fit for purpose. >=20 > This proposal also opens a trivial class of wasted-work attacks = against QUIC servers by malicious clients, which can now craft packets = which will require the server to partially decrypt them before realizing = they're not useful. Obviously bad packet numbers can be avoided with = simple heuristics. Less-obvious attacks might be crafted to incur = significant nonproductive cost on the server side. This seems to be an = unavoidable property of any approach to packet number encryption that = would actually work, though, so that's not an observation about this = specific proposal. I also haven't done the analysis to see if this is = all that bad. >=20 > Why isn't this already the case? I just take a valid packet, change a = bit in the MAC, and resend it a bunch of times. It seems to me that the borked MAC replay is easy to distinguish and = dynamically filter at the receiver: if you see this, someone is screwing = with you, and you can safely blackhole them. On the other hand, a stream = of packets that look valid to the decryption stage but that will be = rejected as irrelevant but not insane seems harder to reject and = blackhole in the general case Cheers, Brian > -Ekr >=20 >=20 > Note as well that this proposal comes with a manageability cost. = On-path measurement of upstream loss and reordering would become = impossible, and the fidelity of the spin bit under loss and reordering = would be reduced. >=20 > > In case people were wondering, and because it already came up: I > > intend to separately propose a change to the short header packet = that > > would remove the type field and move the packet number length under > > encryption. See my response to Ian's question on the PR for an > > explanation of how this will likely work. >=20 > Yep, this makes sense. We'll need to consider these changes closely in = concert with any change to the CID. As above, avoiding linkability with = PN encryption while aiding it with a CID is hard, and a varlen CID plus = a varint encrypted PN will make parsing fiddlier than it already is. >=20 > As Christian noted, using the short header type field to provide a = sort of subsequence number or other packet-number independent explicit = signal would mitigate the damage packet number encryption would to do = loss and reordering observability, but not completely address them. >=20 > Cheers, >=20 > Brian >=20 >=20 --Apple-Mail=_F2A7FFDB-AE84-4B0D-92F0-C070E221BA60 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpxkmsACgkQihK3vwvq RqNJmw//XaWTDemAp+zfO42+KSPsuLmo0HWV9rgzKBeV9UnRINDnDYQoEXnLKHgC 7bib2atbmh6k76iTI2b5wNsaYHHyIjvEFGHuCE5FcUt+NO1q6yZHdEZvlGjgrQYl LIG7PCPJv22P9DMFAwZLEvAERvxCfJV9rJL3laRUk/2v9gYV+bCK480VK9v9Gmy9 P2C9D1qgVN7l2pYEq0h7R3XTSiMsNoIcFTqiDdQqJAtsP4ZOeh1aJUaaO1Wt9mgf BQ5wlHnUX78QqYPSovJ4kKgkoS0/TpGtoe/dEhXQMQ+f058DfNplZ774cH+6akR0 r71GRM5B4n2MYWaavSHfq+VkHBCCpv7r4aQHuLRELbw3f5IMn3L5GsfDawO6QoMp U2jukyQdeBBNZEp0DzpqKgbgBAcZfWjCKwfx2+0jQ9LipSYEyn8j8iIuIgwRijK9 vzt9Ymo2TC1GhqL8cRv6tvDPhiRb9MDfISwcuWcgKF5KQCDReYgzQnWIo2Ei7JdE 4RSW+BSi4vmycs6oKBQPj1vMGvuiwGAxJ+nVDrzdeoSleDB5qodE08MZJOyl2D36 DsaZwuwPuWLudeXTbGZPMio0Z0un/7ACAzB7VA113zPZNnvmrGnY0RYkoHSR7+Sf iR/LUmNtBsF4CwpCkx2gzeAiu9JTc5TgUrI+CMlacgPivF6UQNs= =0O01 -----END PGP SIGNATURE----- --Apple-Mail=_F2A7FFDB-AE84-4B0D-92F0-C070E221BA60-- From nobody Wed Jan 31 02:06:32 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0001E1319DC for ; Wed, 31 Jan 2018 02:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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=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 nizHSdyUiPPc for ; Wed, 31 Jan 2018 02:06:28 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7312912D7F5 for ; Wed, 31 Jan 2018 02:00:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,439,1511856000"; d="asc'?scan'208";a="235161028" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx142-out.netapp.com with ESMTP; 31 Jan 2018 02:00:16 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 31 Jan 2018 02:00:17 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 31 Jan 2018 02:00:17 -0800 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=TgIC0NZE1cHWfV/jFQaRjly5WQ2ah65JrtZ2a5lEnxg=; b=nt7U6MhN2lS9JkZgt65TquOBkXv6W1nyDqLs9EZejW2m6KLL1wT91IwKb2BJXecmYgK+8nn0XunEDySek2fat4iKfdgGGv8OnMGvr6KBrLtexOtaeHJrS4Fcek5tWwkQQP9HtBGdDUuSsLZT7hvOGVxQaODFDxzHKw5Q3I0Xndw= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB017.namprd06.prod.outlook.com (10.242.190.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Wed, 31 Jan 2018 10:00: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.20.0464.012; Wed, 31 Jan 2018 10:00:14 +0000 From: "Eggert, Lars" To: Gorry Fairhust CC: =?iso-8859-1?Q?Mirja_K=FChlewind?= , Brian Trammell , Eric Rescorla , QUIC WG , Martin Thomson , Christian Huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW4N20iqCvtUQkeoUTLrfs9vLqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPDAIAAAiaA Date: Wed, 31 Jan 2018 10:00:14 +0000 Message-ID: <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> In-Reply-To: <5A7191E0.6010003@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB017; 7:4ypyVII8GjTPdss4JTGRDZ9xHC5ftZgvH01WWQJz3Bl7bIEvZVy3k6ibrfv259RTIL/FCH6hU4w0vqR6nKG1kAC8YLY9OCerFLZ/J1DAWWcllUYWOYcCm/m0DVTOTbLR2jaGem4til//6BgDhqI5OynK7i9zgU4lUXijDVuL1cb9yeDaPPsdeVyEafEpV1N7hf0iO8ZkiHgVkz/VcdAYIfpGQh7VxA9yyQd/ImQ0ZXxI+nvccck6I/YWCc9EmNfq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 392c5453-2408-4a86-59d7-08d568916c99 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB017; x-ms-traffictypediagnostic: BLUPR06MB017: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR06MB017; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB017; x-forefront-prvs: 056929CBB8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(39380400002)(396003)(366004)(376002)(189003)(199004)(377424004)(6436002)(6512007)(6506007)(25786009)(83716003)(36756003)(6246003)(3846002)(86362001)(39060400002)(2906002)(57306001)(6116002)(3480700004)(53546011)(14454004)(478600001)(50226002)(6916009)(558084003)(105586002)(102836004)(53936002)(2950100002)(6486002)(97736004)(229853002)(66066001)(305945005)(68736007)(4326008)(54906003)(26005)(81166006)(76176011)(3280700002)(8676002)(93886005)(77096007)(81156014)(99286004)(33656002)(8936002)(7116003)(106356001)(99936001)(82746002)(316002)(186003)(2900100001)(5660300001)(7736002)(3660700001)(4001150100001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB017; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: tD0CfNqMP3Xy6/GbnfYLJ88Eh/T/tXHO1lhRoV9Lx/HvhXg1d367gusHX0MUOIJVfENpCzlnRRdPtg5fvLesiA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_03A4C2C5-446A-42F4-B91F-F58DB2722D7B"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 392c5453-2408-4a86-59d7-08d568916c99 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2018 10:00:14.2141 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB017 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: Wed, 31 Jan 2018 10:06:31 -0000 --Apple-Mail=_03A4C2C5-446A-42F4-B91F-F58DB2722D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > +1 - Simply: This *is* complicated and seems to add little. So as an implementor (chair hat off), this adds very little to the = overall complexity of the protocol. Lars --Apple-Mail=_03A4C2C5-446A-42F4-B91F-F58DB2722D7B 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlpxk60ACgkQVLXDCb9w wVc8yQ/9HA629g3N+xTlX435oruFjoE8ZmIrzngdh472fb4M58w75P4vRGutigKq QH5HjMv+zS552bXaSvVfLNvXWldcLFbT81JFVLgmuItul7B5jtk7abBd9o9Ei0jQ vl8v9rr8uFQDc8pLYSoQx9Hvpwb82MWoBc9LCu/cvbkIylyy23JwkX0VgPUpq0JO buYTQ8jW8nl553PtsQx9+Ou4fl1vfKolfBKHPbT89PSrIoofJxnEQDbZCRj9f5Qd WsgzwNG4HvArfY1LyGPhHmESpkpumXOAM6aj6DIOYLWuX7BfcddiKfwlPYuhqfiF uRH9++jM+mv/BB9XKDTR72Q7in0CG+LJ5V4rZZ+wVE7ZuLE8p1wBPFWB89rVROUg ey9AlPchthC5IxXlszin7oh7PdK3k3ZXeb9PKUshFTkDVdEHUNhPVfjXIOoC4YnB 5ArIxsbjwqQAPG3nQi5jxV4Io5A91er5unFagVffakBH5Ax4iyUv4EqdWs6lEFRa x+5nwx1QDp+kfIdcYtvFrbXoKfhB0JEqpezyc3vxrqsLYFil03FaBNcPew4Mrw4W 9df3wq1fkA97bl/daUkLRMmnDLXMuiSEmalOqz07CcFplP+dAopBVeXiLH4jHYqG Z6J8Pp3RQZzkCXVwCvH83tSL7cNixZLArkVc7GRL3Hto3xWpLFU= =frIn -----END PGP SIGNATURE----- --Apple-Mail=_03A4C2C5-446A-42F4-B91F-F58DB2722D7B-- From nobody Wed Jan 31 02:14:37 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF061316D0 for ; Wed, 31 Jan 2018 02:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQjjZoMGtM3d for ; Wed, 31 Jan 2018 02:14:32 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB89F12D7F7 for ; Wed, 31 Jan 2018 02:14:21 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B77A3340EBF; Wed, 31 Jan 2018 11:14:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.10323); Wed, 31 Jan 2018 11:14:20 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Wed, 31 Jan 2018 11:14:20 +0100 (CET) Received: from [81.134.152.4] (account ietf@trammell.ch HELO [172.18.9.171]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43874202; Wed, 31 Jan 2018 11:14:20 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_44D44E57-F4E8-4FF7-8BAF-1C33D772CD18"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Wed, 31 Jan 2018 10:14:22 +0000 In-Reply-To: <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> Cc: Eric Rescorla , QUIC WG , Martin Thomson To: Christian Huitema References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> 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, 31 Jan 2018 10:14:35 -0000 --Apple-Mail=_44D44E57-F4E8-4FF7-8BAF-1C33D772CD18 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Jan 2018, at 21:00, Christian Huitema = wrote: >=20 >=20 >=20 > On 1/30/2018 10:31 AM, Eric Rescorla wrote: >>=20 >>=20 >> On Tue, Jan 30, 2018 at 6:53 AM, Brian Trammell = wrote: >> hi Martin, >> ... >> I'm not sure this isn't completely crazy. >=20 > I think this beats the alternatives, either complex-but-fragile = obfuscation schemes, or separate per-path encryption contexts. Also, I = like that this is somewhat future-proof -- it allows building future = multipath extension at an almost minimal cost. I'll note that this presupposes a class of designs for MPQUIC. There's = another entire class where a higher-layer end-to-end multistream = association maps down to a set of completely separate QUIC connections. = I don't know that we're at a point where we can say that we should = prefer one over the other (and indeed, we shouldn't try to be before = QUIC version 2). >> ... >> Beyond this, though, we need to have a coherent idea of what we're = trying to prevent. =46rom discussions to date, I think these are the two = cases we care about: >>=20 >> (1) An unprivileged on-path device that sees a packet from a flow = that is migrated on purpose by an endpoint (i.e., due to connection = migration or multipath) should not be able to associate that packet to = the prior flow. >=20 > Yes. Okay. This seems like a reasonable goal. >> (2) An unprivileged on-path device that sees a packet from a flow = that is unintentionally migrated (i.e., one of its globally routable = addresses changes without the associated endpoint's knowledge) should = not be able to associate that packet to the prior flow. >=20 > No. That one can only be solved through a voluntary action from the = sender. If the client is in the middle of sending a stream, correlation = is trivial whatever we do. Yep. > There are however two plausible improvements: >=20 > a) Explicit migration after signalling by the NAT box. We would need = some new protocol to do that, maybe ICMP based. It could work in the = "mobile router" case. You could bind this to something like a future, more dynamic PvD. Or you = could have done it inline with PLUS, had that been a thing we'd decided = to do. In either case deployment before the end of next decade seems = optimistic. > b) Opportunistic migration out of quiescence. NAT rebinding typically = happen after a period of silence. Clients that just start sending after = a long silence may decide to "simulate a migration", to break the = correlation. Seems like it'd be simpler just to always try to 0RTT resume after being = quiet for more than 30s, though that would require the application = mapping to be resumption-aware. > Both of these improvements will benefit from packet number encryption. >=20 >> ... >> As Christian noted, using the short header type field to provide a = sort of subsequence number or other packet-number independent explicit = signal would mitigate the damage packet number encryption would to do = loss and reordering observability, but not completely address them. >=20 > Yes. We have to be serious about network manageability. There has to = be a sweet spot between expose everything so network management sees it = and encrypt everything so middle boxes do not breach privacy or ossify = the protocol. I think tricks like the spin bit and/or a small-modulo = sequence number may be close to that sweet spot. >=20 > Part of me would want to see these spin bit and small modulo sequence = number down in the IP header. That would look like a very nice use of = the IPv6 flow-ID. As I understand it, the currently (spottily) deployed uses of the = flow-ID, which ECMP based on it, would prevent that. I've only seen = anecdata here though. > Wouldn't it be nice if network management was based on the network = header? But failing that, maybe we need to start something in QUIC. That ship sailed a long while ago (cf. RFC 7872). We have indeed = specified relatively higher-overhead DO headers for diagnostics (RFC = 8250), though given Internet deployment issues with extension headers = and DO, it's really only intended for usage in local networks. There's are reasons practice has migrated to passive observation of TCP = for this sort of thing, and building a protocol to address TCP = ossification won't fix them. Cheers, Brian --Apple-Mail=_44D44E57-F4E8-4FF7-8BAF-1C33D772CD18 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpxlv4ACgkQihK3vwvq RqPkGA//VOAnrL2gHMN86/zDbKDMssGzxJXScED6ysAVGtsSq2MeuelkFKLRVskR lN+w75WbiK1v9p3XyXDagux6Bmiznj+A3gKvAlcJBVV/Me1cAtr4erjmnf6DBoHg 9KIrCuiPtbX4R9urBb/ZFQj0aRmlRcyPq63RjxV8A23Trb3baLXCLCTdicelzc6r wUN/JEuhiqH9WzNe6KDpqfVtk074eqBz2zxpiEqcLTeCno7gNloDwmWiX2JykGDk fXF8lM+WL63uMit2Wgb71MSKY9HZlfW/135Q0df0AONyC5uNtjFI/eI5Z+BbPktf 07LYr4p/RKSyjrt+OL3kLMePKh2o2s6hTQ59SKangR7kh9K9AaI3nF45Ft6BBCIu 1/zvYiMo4CJZF/qRxGrATjiGGrW0x4kKW+FdOAyYeI7Rc9H5A42DsRdJw0JjF6iP lCFYL70sFa9Q1DgH7L/v0Kfvm83wnfj1BnH0CIz571665GyNBfF1y5SLnJtgzsUF pc7E3fqYlTBk51OSJYjwgtZEYpLyyhyLvPMxAJWyqe3r4IbF+35Phql2VXTsjaAj zAq0lZr6z0453HuPM39WiXxxmfmbA4q+DwF4JsE514qcojKDxZVdLp5jAXaV1V8R kVPd/ifxRh8KmDByXudYRq5AeFOb0uhjdWmUzbNmcZH2JJBYeHE= =tIFY -----END PGP SIGNATURE----- --Apple-Mail=_44D44E57-F4E8-4FF7-8BAF-1C33D772CD18-- From nobody Wed Jan 31 02:42:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52836131714 for ; Wed, 31 Jan 2018 02:42:42 -0800 (PST) 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 bv7lyS4Gq-C9 for ; Wed, 31 Jan 2018 02:42:40 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::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 0D0BB1319E1 for ; Wed, 31 Jan 2018 02:40:05 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id c189so9473078oib.12 for ; Wed, 31 Jan 2018 02:40:05 -0800 (PST) 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=xOumLKUeIZ8TrvnwS080ut+/oEL+In1mLXPiwtyxU6A=; b=CqxJaIC2pJqkqfRPHHa/pzMsfdW1e/lxq+h7l4QUPdLgOfDCVEk4RaPmIAeCWCWoPy PB64/7cuDoDUWcFGrTtICtmL+p9duOUOpPbrCz93t4x0ix4PdeJ+xUWrPKnGi5zBUFJG ivHSXgB2qbvbBP0RcR9oa+c6UIaLtnBsX0u/JfQ/7gPqe1WDhCGRgxMxeZOJwMw0kgzg dADT+muuJA2tOjjOv6JN5IEmJpajcClx8Gepw1pQO71EdOOje6nTC2bDbwtShWEPOQEV 4J/pYN4MBsjqR9rT4uxcHYq0FFX+ugsxqWSfOVVcCvJb1hKkpfh7A8A/bemrag7YNYWl 6w6w== 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=xOumLKUeIZ8TrvnwS080ut+/oEL+In1mLXPiwtyxU6A=; b=gGlTixrNYfY6UnqVmmggA1JaYj/gaG+lCzt+MtN3HGn2vBUbire8SLQx6GZ4QgmEa2 duzERCLMj6waN2oBUwPC2sIqZ2lAy/KRCmJzvZfzQTNDY84BjDYvjs/Mi35FuV1sFnBi +QGVhSANP8HxRJLHK9jxPZ7EdrQ853Y+bboCZoniHatUp/0AfAxdDl0hjgjMpeH5pl6K lcTM8uG1mvWSJG2wJ6cGMYHvUZ2U/LigQSSHsphRyTbIy03uA4FxSWhzOIUBYgYzQGk1 I7CBnDGgYVrduax7pvZ3I2biylAP7IlXf0GltMlP/+Tji5GMQMow/mIflKlCQUQbO3tT Zb/g== X-Gm-Message-State: AKwxytdjjW89e6MgFWzuExjM9UZMcxq0ltdKHhcQAK2x8zdIaUv9vLcg fAqgaMuslRCMnvVh2Df8TC3+YjnujF/l/lFMtUo= X-Google-Smtp-Source: AH8x224Hw9v35y8zlqAjvGvTPBnUiM8xEkU0KjxU9Q/cM7g6YAVy0Lr/kMMhxrVQcGjDvUyZq4vcmAGv8IJVHYpTBS0= X-Received: by 10.202.23.9 with SMTP id j9mr6344958oii.50.1517395204269; Wed, 31 Jan 2018 02:40:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 02:40:03 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> From: Martin Thomson Date: Wed, 31 Jan 2018 21:40:03 +1100 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" Cc: Christian Huitema , Eric Rescorla , 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, 31 Jan 2018 10:42:42 -0000 On Wed, Jan 31, 2018 at 9:14 PM, Brian Trammell (IETF) wrote: > Seems like it'd be simpler just to always try to 0RTT resume after being quiet for more than 30s, though that would require the application mapping to be resumption-aware. You would lose a lot of state that way (absent some way of preserving that state, which we don't have). 0-RTT also has a bunch of drawbacks, including but not limited to: a pretty significant crypto hit, a non-zero risk of not working, replay exposure, limitations on number of bytes. From nobody Wed Jan 31 04:49:22 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AED12EA5A for ; Wed, 31 Jan 2018 04:49:21 -0800 (PST) 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 6BjjL6ktAwMT for ; Wed, 31 Jan 2018 04:49:18 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E21112E89A for ; Wed, 31 Jan 2018 04:49:18 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id m11so15083473iob.2 for ; Wed, 31 Jan 2018 04:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=KcCcEC1ks9EIiAiLW6EqFSc3T9yjW17HwiH7bqfVnRo=; b=UPTarHr3A+R6Isvy1cqeyD9L36a4aTjz0F2SuNC8O7V/Pd9tgegIhXzCpRMimwCE2h yCRKOLLniMNr+OdplPLmjv4u1M9TJCEWjkcL2sbRrgrnf32PG6+mYOxQ9IUlFO/CViQv hDiLuq2ErYgwfQj6SJDoh4crOH5exlUx6xrQYqsLjHkeC1dkmqpk4BKwCG4SgzPj8TET 05qYxgM5pIN2P2IqTQZVA8ofIi+TGShLvR9N6a4AoX1dqQXwRIqdbtVsSlyVLKXEVGuU nIGJIjXBODEl65gG5tH8/gXPpBxNY3c5Izd2U55FPgf09txUANapacRqVDl4A7qA+s4q ns3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=KcCcEC1ks9EIiAiLW6EqFSc3T9yjW17HwiH7bqfVnRo=; b=MisE3K5R13Avy7iiiH+wwvDsEIZfsSeM+Gpg6iWBcrn6hwWKjcSUyGbGi57XxqyV5P 6cTBnyzlLEJ+Q86DnWbw6Pqjef8KUtsMh/tzJU4TQ8Dz7rMPNIgv1AK5czNYOJj9ZrSr jFP920NWKZQ8L+018d91/fSXZ6gVCTwgOHEsZaiIRksKd71N+OJTvEIuJrDWvt238v+Y 4WWf7GmPcEi+wrpbJsDOPVPLB7ZM/j1Jdwcu5PSH90N5t0lbKtptpJi9BIrALlSVpP7g lDpH7Q30AgXdLWGSR/qoSDOB3OOfHjLjnk8S0g5yVbaYae2q8Hi3osBa+EgxkxtPRr5W JAqg== X-Gm-Message-State: AKwxytf8o6OLqLKeFaLOAOIuvgg28apI/JMABYnnQln0R61IRmui53xI YxxLG9gZ2ri6ekc/TI523K40hJDHawuhcqQs2uI= X-Google-Smtp-Source: AH8x226oCkKG54CaCc+6Hjd0oLYbhX/ytYTOd6zjmPfUci9pGBIA6o44dI8RHl/+SOZHs+h4oUehjZBuenMXkgH9tD8= X-Received: by 10.107.34.199 with SMTP id i190mr35115558ioi.297.1517402957718; Wed, 31 Jan 2018 04:49:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 31 Jan 2018 04:49:16 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 31 Jan 2018 04:49:16 -0800 Message-ID: Subject: Re: Packet number encryption To: Martin Thomson , =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Eric Rescorla , QUIC WG , Brian Trammell , Christian Huitema Content-Type: multipart/alternative; boundary="001a1140d94446b77f056411e86b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Jan 2018 12:49:21 -0000 --001a1140d94446b77f056411e86b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Originally I liked the idea of packet number encryption, but I am no longer fully convinced considering that the gains are limited and the data being protected are not likely secret to a powerful attacker anyway. It is no longer possible to do AEAD in-place without first unwrapping the packet number. I don=E2=80=99t have any numbers on AES-NI setup cost, but it could be significantly more expensive per byte to decrypt a single block compared to decrypting a full packet, and there are also constrained devices to consider. This can lead to additional latency in packet handling and more per connection storage requirement for crypto keys, and it strains the limited crypto core resources. With 17 byte connection ID=E2=80=99s they may be a (self-imposed) crypto ov= erhead on this as well using yet another crypto context. There is also additional implementation complexity as Mirja mentions, though I=E2=80=99m not sure that it is that much of a burden - the main iss= ue is to correctly derive the packet number key. However, this must also be balanced against the alternatives in relation to migration (though not all connections want/need the overhead and complexity of migration): Packet numbers MUST be unique across migration when using the same crypto context, so a) using separate packet number space per CID is separate crypto context per CID b) using a separate connection but allow streams to continue on a new connection. c) using a random gap (as is the case now), which might not be as secure is desired (debatable I think) d) doing nothing at all to protect packet number linkage A separate packet number space has crypto overhead and so does a separate connection (a, b), so not really simpler. Getting rid of random gap c) would be a gain, but only if gaps were also removed elsewhere, notably as protection abasing optimistic ACK attack from hostile peer. Options c, and d would allow the multi-path design to evolve for QUIC v2 without doing some half-baked stop-gap solution that might fit poorly into that design. Doing nothing at all would kind of be the same as giving up. But it would be really nice to get rid of all packet number gaps, and it, it is really really dubious that encrypting packet numbers would prevent linkage due to timing analysis etc. So in conclusion, perhaps packet number encryption is not without merits, but perhaps it is getting a bit ahead of other design elements that need to be in place first. Mikkel On 31 January 2018 at 08.44.51, Mirja K=C3=BChlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: > Am 31.01.2018 um 04:08 schrieb Martin Thomson : > > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema wrote: >>> (1) An unprivileged on-path device that sees a packet from a flow that is >>> migrated on purpose by an endpoint (i.e., due to connection migration or >>> multipath) should not be able to associate that packet to the prior flow. >> >> Yes. > > Agreed. This remains the primary target. I don't think that there > are any negatives with this design with respect to this use case (or > at least I found nothing in Brian's email on this point). If that is the goal, I think the complexity of the proposed solution is not justified. Just select a new random offset when you migrate but increase the packet number monotonously otherwise to support manageability. I=E2=80=99m really concerned about complexity here. Even though this scheme= is not very complex, any complexity is a potential source for future implementation errors which can also led to restrictions in what changes can be deploy with future versions. Making a protocol as simple as possible and thereby the spec as easy understandable as possible is also key for deployment. If we add complexity here without making it clear what the goal or additional benefit is of the complexity, I think that is just wrong. My 2c. Mirja --001a1140d94446b77f056411e86b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Originally I liked t= he idea of packet number encryption, but I am no longer fully convinced con= sidering that the gains are limited and the data being protected are not li= kely secret to a powerful attacker anyway.

    It is no longer possible to do AEAD in-place without= first unwrapping the packet number.

    I don=E2=80=99t have any numbers on AES-NI setup cost, but = it could be significantly more expensive per byte to decrypt a single block= compared to decrypting a full packet, and there are also constrained devic= es to consider.

    This = can lead to additional latency in packet handling and more per connection s= torage requirement for crypto keys, and it strains the limited crypto core = resources.
    With 17 by= te connection ID=E2=80=99s they may be a (self-imposed) crypto overhead on = this as well using yet another crypto context.

    There is also additional implementation complexit= y as Mirja mentions, though I=E2=80=99m not sure that it is that much of a = burden - the main issue is to correctly derive the packet number key.
    =


    However, this must also be balanc= ed against the alternatives in relation to migration (though not all connec= tions want/need the overhead and complexity of migration):

    Packet numbers MUST be unique across = migration when using the same crypto context, so

    a) using separate packet number space per CID i= s separate crypto context per CID
    b)= using a separate connection but allow streams to continue on a new connect= ion.
    c)= using a random gap (as is the case now), which might not be as secure is d= esired (debatable I think)
    d) doing nothing at all to protect packet number linkage

    A separate packet number = space has crypto overhead and so does a separate connection (a, b), so not = really simpler.

    Getti= ng rid of random gap c) would be a gain, but only if gaps were also removed= elsewhere, notably as protection abasing optimistic ACK attack from hostil= e peer.

    <= /div>
    Options c, an= d d would allow the multi-path design to evolve for QUIC v2 without doing s= ome half-baked stop-gap solution that might fit poorly into that design.

    Doing nothing at all wo= uld kind of be the same as giving up. But it would be really nice to get ri= d of all packet number gaps, and it, it is really really dubious that encry= pting packet numbers would prevent linkage due to timing analysis etc.

    So in conclusion, perhaps= packet number encryption is not without merits, but perhaps it is getting = a bit ahead of other design elements that need to be in place first.
    <= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
    Mikkel


    On 31 January 2018 at 08.44.51, Mirja K=C3=BChlewind (mirja.kuehlewind@tik.ee.ethz.ch) = wrote:



    > Am 31.01.2018 um 04:08 schrieb Martin Thomson <martin.thomson@gmail.com>:
    > =20
    > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema <huitema@huitema.net> wrote:
    >>> (1) An unprivileged on-path device that sees a packet from= a flow that is
    >>> migrated on purpose by an endpoint (i.e., due to connectio= n migration or
    >>> multipath) should not be able to associate that packet to = the prior flow.
    >> =20
    >> Yes.
    > =20
    > Agreed. This remains the primary target. I don't think that = there
    > are any negatives with this design with respect to this use case (= or
    > at least I found nothing in Brian's email on this point).

    If that is the goal, I think the complexity of the proposed solution is= not justified. Just select a new random offset when you migrate but increa= se the packet number monotonously otherwise to support manageability.

    I=E2=80=99m really concerned about complexity here. Even though this sc= heme is not very complex, any complexity is a potential source for future i= mplementation errors which can also led to restrictions in what changes can= be deploy with future versions. Making a protocol as simple as possible an= d thereby the spec as easy understandable as possible is also key for deplo= yment. If we add complexity here without making it clear what the goal or a= dditional benefit is of the complexity, I think that is just wrong.

    My 2c.
    Mirja

    --001a1140d94446b77f056411e86b-- From nobody Wed Jan 31 10:47:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5026012F27B for ; Wed, 31 Jan 2018 10:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Cf7ZXX_7sCM3 for ; Wed, 31 Jan 2018 10:47:09 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3902512ECEF for ; Wed, 31 Jan 2018 10:47:07 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v139so8347772ywg.4 for ; Wed, 31 Jan 2018 10:47:07 -0800 (PST) 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=wNEjCa3ibGst/5eoCbc24Aw+JgNmBENO+aluIiq31Rc=; b=bayj6aeUcYV9HzUjEqi19Vfekeg/F0waIpp7MeRoRDhPBWjP1c052yRVrZNqSK9GBd DuxczG2MGQqAmGOaiJ7GY+9NCq/SLJs5pBTUBbr7u3yRyq8WBiWikzpQIo3UQbwEcf8L /Jl19NzYQKLiQE8LNRK107GD/bC9FI4i9tFgqYWDbFuoryk32vxngPiKL5oT5mwBX/FC b+VDYyvPTnrD9Q4d2nhC8ViebR80ZeDZkyoe6fdHFRh9niKxhvnjKiBHcjMkov1KDfGp SUxKr1rGNqbPTBg6dBfETE6guH21o20zt3BrfthLOd8ildcFUZ1ObVP1XQffDhDrttB7 b1/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=wNEjCa3ibGst/5eoCbc24Aw+JgNmBENO+aluIiq31Rc=; b=j55VA1VpbL4IH0BpQzR8mGrQFYgNBQ5KrZl2OZOEudQa9Nj1beirvi9xVtYdXOfqkW yvQOjBgbhk+DZ0peGp5fED2Iw1V5Nn03C/2Wdg1jbaL3itnMJGBXvn7z4KPxjWIFYl5S f46IhOfb7zrrWr+tH12JmQm2eydYHHpRxhXLN0WW3narwU7sKjUxqAZFSGCfm1laZ6gO /IVXD8u8NkDgOAhx4fZ19d5jP7UIWFx5idrtWU1UbT7eE2cKsRJQVwSaPCG9Mro1e+ck exSmkg6UOLUqQ7tg8g59k+reMbw9BFdWTx6k/pwR7/qnUJwnAPb3A2xxbqSD8egQd+V/ 0inQ== X-Gm-Message-State: AKwxytdfTshSbWSqgnN4FOmgjwLJ3QfPgs/eJmK70ePxpGjXCMLjLHvH kgbdcDJebTk+XFH35w+7RGx+2rCFYkQHHoj7Tl+oPvcJ X-Google-Smtp-Source: AH8x227MGSH/0lPioKnItio5qdDLvoG7UE17BICFsRYjqO4S5e+APLSFKC9vUMJnOPWApcLKcfNcC/i3C2i3ijwAhGA= X-Received: by 10.129.118.70 with SMTP id j6mr23501767ywk.434.1517424425291; Wed, 31 Jan 2018 10:47:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.16.8 with HTTP; Wed, 31 Jan 2018 10:47:04 -0800 (PST) In-Reply-To: References: From: Wenbo Zhu Date: Wed, 31 Jan 2018 10:47:04 -0800 Message-ID: Subject: Re: DRAFT minutes of the Melbourne interim meeting To: Mark Nottingham Cc: QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="f403045ef0c2d8b98e056416e7d0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Jan 2018 18:47:11 -0000 --f403045ef0c2d8b98e056416e7d0 Content-Type: text/plain; charset="UTF-8" Thanks for the minutes! === Curious about what's been discussed further about http/1.1 over quic? Is it the case that there shouldn't even be a spec on how to do http/1.1 over quic, i.e. a "quic socket" should be able to support any (non-multiplexed) L7 protocols, more or less transparently? Or this is not yet the case with the current state of quic spec? ) Re: regression, is it mainly from the loss of header compression? On Sun, Jan 28, 2018 at 8:43 PM, Mark Nottingham wrote: > ... are at: > https://github.com/quicwg/wg-materials/blob/master/interim- > 18-01/minutes.md > > Thanks again to all of our scribes. > > As usual, corrections welcome, either through a pull request or via e-mail. > > Regards, > > > -- > Mark Nottingham https://www.mnot.net/ > > --f403045ef0c2d8b98e056416e7d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks for the minutes!

    =3D=3D=3D

    Curious about what's been discussed further about htt= p/1.1 over quic?

    Is it the case that there shouldn= 't even be a spec on how to do http/1.1 over quic, i.e. a "quic so= cket" should be able to support any (non-multiplexed) L7 protocols, mo= re or less transparently? Or this is not yet the case with the current stat= e of quic spec?
    )
    Re: regression, is it mainly from the= loss of header compression?=C2=A0

    =C2=A0





    On Sun, Jan 28, 2018 at= 8:43 PM, Mark Nottingham <mnot@mnot.net> wrote:
    ... are at:
    =C2=A0 https://github.com= /quicwg/wg-materials/blob/master/interim-18-01/minutes.md

    Thanks again to all of our scribes.

    As usual, corrections welcome, either through a pull request or via e-mail.=

    Regards,


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


    --f403045ef0c2d8b98e056416e7d0-- From nobody Wed Jan 31 13:05:09 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5220B12FAA7 for ; Wed, 31 Jan 2018 13:05:08 -0800 (PST) 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 6S1Zvyks3GcA for ; Wed, 31 Jan 2018 13:05:06 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 75E9A12FAA9 for ; Wed, 31 Jan 2018 13:05:05 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id v5so14775265oth.5 for ; Wed, 31 Jan 2018 13:05:05 -0800 (PST) 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=e7tXIb3JOV5dux2LzYEmsd+VVro0AsUQcWHvDiFzQEw=; b=pCbBHgXJm4eSJmbt1D+5PFJmVQK5mtEZX9XTi1gE9o2DCdgiFP9jRVn14nU2PwFMEi 361U6ZH8MBgHX/PJP2H2PnyqcfMKrjgvL/cpea5SqUR+5VtehL+CwY2K2g7f1vqqPQjT mmoPbPJOjIN61UPt/fG1yTbEtnAhr0LyeBrCb6ogGGSEvpGulXtwNAVAEBvEzINcVVA6 zjWIVMVthfa1PWh9BX04UG/KIUzsQubtYW9Esl8ej8ioA83Oy2IVNuszAx1vmrlMnyK8 UYW9MYya42LhwSppQ6YmWvHnGmYhmY/FbVdMoSpfEeE5dMn3B2qSxUfSQTuH7voSxj78 wgwQ== 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=e7tXIb3JOV5dux2LzYEmsd+VVro0AsUQcWHvDiFzQEw=; b=D1Ov2eqmZjoNY/9WttvPrpgtE95YaQsMlNRpEsXh0Bw2kWy+9pkx42CW5M5ARPvzrB JtAxq9vjpmRXe6kmgtLMvvVDcABEtNkwITRP1u8KMtR0A/VgSy/F7Lam/6NOMXtDthOu dhn89GCvGZEt+8lhKBYfXBeow4JTqYxZOu7JWrluqP+X/gVXWjdntUz7hadGKqgM4cd4 K9vgi8ZoQhRdj1qQDwbpwIoOvlTJ4UPTCsuEO07iy4Z8FCZO2P2laCyJVi9yNKIIjXjR QXZrdnicClWt4ln9zWS6lBMt1OAMAK77R9ray0KcGrBydWRXBBbrOQIgf9zYOdYfRA5u SC+g== X-Gm-Message-State: AKwxytd1sfQ6de2Vt5dn5K6i2YyaUw9PE83Y66gA9qxwRjfg9JP1T2l5 X64/N8gER0YfcwdTASty2RDHBnDOOJ/ovyzmo6U= X-Google-Smtp-Source: AH8x2256Ac1I7uRugvk3xyqq+HdwvEDSld+pG413ccRn6ToPtIL/qZij0inGxW071QYePanyASAxKUCO+9iByKtK1Uc= X-Received: by 10.157.46.206 with SMTP id w72mr15227257ota.16.1517432704788; Wed, 31 Jan 2018 13:05:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 13:05:04 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> From: Martin Thomson Date: Thu, 1 Feb 2018 08:05:04 +1100 Message-ID: Subject: Re: Packet number encryption To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , QUIC WG , Brian Trammell , Christian Huitema Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 21:05:08 -0000 On Wed, Jan 31, 2018 at 11:49 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I don=E2=80=99t have any numbers on AES-NI setup cost, but it could be si= gnificantly > more expensive per byte to decrypt a single block compared to decrypting = a > full packet, and there are also constrained devices to consider. It's true that AES has some costs that relate to the installation of a key, but those costs are paid just once per key. Once a key is installed, the per-packet cost is a single block, which - with AES-NI - is a handful of cycles. Even on very limited devices doesn't take that much effort (though ChaCha is still cheaper. Keep in mind that we already have the GCM costs paid, since the packet number is part of the AAD. From nobody Wed Jan 31 15:26:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A9E12D777 for ; Wed, 31 Jan 2018 15:26:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=KivhHl+l; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=hmAHY65b Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AaQGZf8vtaK for ; Wed, 31 Jan 2018 15:26:09 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FEE3124234 for ; Wed, 31 Jan 2018 15:26:09 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w0VNMHPp017500; Wed, 31 Jan 2018 15:26:01 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=2spqMCw+8CykhxKFQNNg7SEEiAsbTWcawaU1IdWYFeo=; b=KivhHl+l5KoQ5tvWxWf10hUtsl2LU94XPWxi0jDrFKTEbUGgkX0wKP/4Mbt4DivxwXMS pG82QUgjazKml8hx1rkWghlZlAJl65vwHt1XvZ+6kt1eaBLDmMqmtlPEJhn9AJKHWPx5 U9eM1Z0zSY0UZRqKodIwwa0cTQ9/X5AQrPc= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2fuk5uhgkq-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jan 2018 15:26:01 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.16) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 31 Jan 2018 15:25:54 -0800 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=2spqMCw+8CykhxKFQNNg7SEEiAsbTWcawaU1IdWYFeo=; b=hmAHY65bpuQzRU7omRRg2ijxoVCMTjsFhADfDmWzY0YNUrxFCWI+5jwGM7mxxrGgwn7RTaymXzOj8zhUnbeOfMHezYJW6Qza1ikz0F9vb84eUpJtAy4XJDLIM2LpqIP1UeD3GCX58+F2/FDCB2Q4KUAvmWniyb5FuF3J13T8PPU= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0278.namprd15.prod.outlook.com (10.163.64.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Wed, 31 Jan 2018 23:25:51 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0444.016; Wed, 31 Jan 2018 23:25:51 +0000 From: Roberto Peon To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Thomson CC: Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAAIDjAA== Date: Wed, 31 Jan 2018 23:25:51 +0000 Message-ID: <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:1bde] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0278; 20:UjFohEE71S+Fp0ioUtuyv/syyrL7biy7c9kaAN3vpHuQJUjdvOKSGaLcwf5KUbgUTU/8bGyp2tsWCUOSsNGvlcuqBvQYHpeTi58WCZsvfCWCeJ8SjOJ2dzdPhqy+VF04iesic3sz9IwPUmtExt1WTDSclAQCBy1x9M39Qtb7A/o= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9068f64c-635e-46f5-4d2a-08d56901f7ce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0278; x-ms-traffictypediagnostic: BY2PR15MB0278: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(11241501184)(2400082)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BY2PR15MB0278; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0278; x-forefront-prvs: 056929CBB8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(366004)(376002)(346002)(51444003)(189003)(199004)(36756003)(316002)(6436002)(6486002)(33656002)(229853002)(2906002)(4326008)(53936002)(3480700004)(6246003)(6512007)(59450400001)(86362001)(7736002)(105586002)(14454004)(53546011)(8676002)(478600001)(5660300001)(106356001)(7116003)(102836004)(39060400002)(186003)(6116002)(76176011)(25786009)(3660700001)(97736004)(8936002)(83716003)(54906003)(82746002)(81166006)(2900100001)(2950100002)(3280700002)(68736007)(110136005)(99286004)(81156014)(305945005)(93886005)(6506007)(77096007)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0278; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZDZC03BVSX1JOe1peiAV/mAy9Vy/tTIhDMvPfAl8dLtPImsmjYMxx9TwyqOoduSwzPN9VFw3f+tahE4ndN6I9w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9068f64c-635e-46f5-4d2a-08d56901f7ce X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2018 23:25:51.4294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0278 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Jan 2018 23:26:11 -0000 VGhlcmUgYXJlIHR3byBvYnZpb3VzIGdvYWxzL2JlbmVmaXRzOg0KMSkgU2xvdy9wcmV2ZW50IG9z c2lmaWNhdGlvbi4NCjIpIFJhaXNlIHRoZSBiYXJyaWVyIGhpZ2hlciBmb3IgdHJhY2tpbmcvZmxv dyBjb3JyZWxhdGluZy4NCg0KSWYgd2UgaGF2ZSBtdWx0aXBsZSBDSURzICh3aGljaCBhcmUgdmFs aWQgb24gbW9yZSB0aGFuIG9uZSA1LXR1cGxlKSBhbmQg4oCcbXVsdGlwYXRo4oCdIChvbmUgY291 bGQgaW1hZ2luZSBzd2l0Y2hpbmcgYmV0d2VlbiBhIGJ1bmNoIG9mIElQdjYgYWRkcmVzc2VzIHdo aWNoIGdvIHRvIHRoZSBzYW1lIGhvc3RzKSB3ZSBjYW4gcmVxdWlyZSBhIGhpZ2hlciBzdG9yYWdl IGJhc2VsaW5lIGJlZm9yZSB0cmFmZmljIGNhbiBiZSBjb3JyZWxhdGVkLiBUaGlzIGlzIHdoZXJl IEkgYmVsaWV2ZSAjMiByZWFsbHkgY29tZXMgaW50byBwbGF5LiANCg0KIzEgaXMgbm90aGluZyB0 byBzbmVlemUgYXQ6IGV4cGVyaWVuY2Ugd2l0aCBUQ1AgaGFzIHNob3duIHZlcnkgcmVhbCBoYXJt IGZyb20gaGF2aW5nIHRoaW5ncyB3aGljaCBhbGxvdyBzZXF1ZW5jaW5nIG9mIHBhY2tldHMgaW4g dGhlIGNsZWFyICh1bmFibGUgdG8gcm9sbCBvdXQgY2hhbmdlcyB3aGljaCBzaG91bGQgaGF2ZSBi ZWVuIGNvbXBhdGlibGUpLiBUbyBtZSwgdGhpcyBpcyB0aGUgcHJpbWFyeSB1c2UtY2FzZTogbWFp bnRhaW5pbmcgZnV0dXJlIGZsZXhpYmlsaXR5Lg0KDQotPVINCg0KT24gMS8zMC8xOCwgMTE6NDUg UE0sICJRVUlDIG9uIGJlaGFsZiBvZiBNaXJqYSBLw7xobGV3aW5kIiA8cXVpYy1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPiB3cm90 ZToNCg0KICAgIA0KICAgIA0KICAgID4gQW0gMzEuMDEuMjAxOCB1bSAwNDowOCBzY2hyaWViIE1h cnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Og0KICAgID4gDQogICAgPiBP biBXZWQsIEphbiAzMSwgMjAxOCBhdCA4OjAwIEFNLCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVt YUBodWl0ZW1hLm5ldD4gd3JvdGU6DQogICAgPj4+ICgxKSBBbiB1bnByaXZpbGVnZWQgb24tcGF0 aCBkZXZpY2UgdGhhdCBzZWVzIGEgcGFja2V0IGZyb20gYSBmbG93IHRoYXQgaXMNCiAgICA+Pj4g bWlncmF0ZWQgb24gcHVycG9zZSBieSBhbiBlbmRwb2ludCAoaS5lLiwgZHVlIHRvIGNvbm5lY3Rp b24gbWlncmF0aW9uIG9yDQogICAgPj4+IG11bHRpcGF0aCkgc2hvdWxkIG5vdCBiZSBhYmxlIHRv IGFzc29jaWF0ZSB0aGF0IHBhY2tldCB0byB0aGUgcHJpb3IgZmxvdy4NCiAgICA+PiANCiAgICA+ PiBZZXMuDQogICAgPiANCiAgICA+IEFncmVlZC4gIFRoaXMgcmVtYWlucyB0aGUgcHJpbWFyeSB0 YXJnZXQuICBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUNCiAgICA+IGFyZSBhbnkgbmVnYXRpdmVz IHdpdGggdGhpcyBkZXNpZ24gd2l0aCByZXNwZWN0IHRvIHRoaXMgdXNlIGNhc2UgKG9yDQogICAg PiBhdCBsZWFzdCBJIGZvdW5kIG5vdGhpbmcgaW4gQnJpYW4ncyBlbWFpbCBvbiB0aGlzIHBvaW50 KS4NCiAgICANCiAgICBJZiB0aGF0IGlzIHRoZSBnb2FsLCBJIHRoaW5rIHRoZSBjb21wbGV4aXR5 IG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBpcyBub3QganVzdGlmaWVkLiBKdXN0IHNlbGVjdCBh IG5ldyByYW5kb20gb2Zmc2V0IHdoZW4geW91IG1pZ3JhdGUgYnV0IGluY3JlYXNlIHRoZSBwYWNr ZXQgbnVtYmVyIG1vbm90b25vdXNseSBvdGhlcndpc2UgdG8gc3VwcG9ydCBtYW5hZ2VhYmlsaXR5 Lg0KICAgIA0KICAgIEnigJltIHJlYWxseSBjb25jZXJuZWQgYWJvdXQgY29tcGxleGl0eSBoZXJl LiBFdmVuIHRob3VnaCB0aGlzIHNjaGVtZSBpcyBub3QgdmVyeSBjb21wbGV4LCBhbnkgY29tcGxl eGl0eSBpcyBhIHBvdGVudGlhbCBzb3VyY2UgZm9yIGZ1dHVyZSBpbXBsZW1lbnRhdGlvbiBlcnJv cnMgd2hpY2ggY2FuIGFsc28gbGVkIHRvIHJlc3RyaWN0aW9ucyBpbiB3aGF0IGNoYW5nZXMgY2Fu IGJlIGRlcGxveSB3aXRoIGZ1dHVyZSB2ZXJzaW9ucy4gTWFraW5nIGEgcHJvdG9jb2wgYXMgc2lt cGxlIGFzIHBvc3NpYmxlIGFuZCB0aGVyZWJ5IHRoZSBzcGVjIGFzIGVhc3kgdW5kZXJzdGFuZGFi bGUgYXMgcG9zc2libGUgaXMgYWxzbyBrZXkgZm9yIGRlcGxveW1lbnQuIElmIHdlIGFkZCBjb21w bGV4aXR5IGhlcmUgd2l0aG91dCBtYWtpbmcgaXQgY2xlYXIgd2hhdCB0aGUgZ29hbCBvciBhZGRp dGlvbmFsIGJlbmVmaXQgaXMgb2YgdGhlIGNvbXBsZXhpdHksIEkgdGhpbmsgdGhhdCBpcyBqdXN0 IHdyb25nLg0KICAgIA0KICAgIE15IDJjLg0KICAgIE1pcmphDQogICAgDQogICAgDQoNCg== From nobody Wed Jan 31 16:00:29 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B873F12EB05 for ; Wed, 31 Jan 2018 16:00:18 -0800 (PST) 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 EelJTgUWVgb0 for ; Wed, 31 Jan 2018 16:00:16 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537A412EC7F for ; Wed, 31 Jan 2018 16:00:16 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id e15so1891665oiy.2 for ; Wed, 31 Jan 2018 16:00:16 -0800 (PST) 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=RxgN15OKkrUrfti7FFrYvJM5SmFp8w8u19oATId6Vho=; b=jzhP/jazY8M78SeCl2WKQjmbctMEIrKn/h5mfPhot1OPK5TQK+vURlAq6Aq0YVLkN/ oBsBqvGpE3zkpJxQsB3p/AgHYMzGFX9w7zNbbvsr19o9ej8KGXZXY7qBSBHtQL0UZSxt gS3dFxbBQKyWRCd+v21mta9/ksQr4+nTlbTlJMJPI+R0HL+DFWS7tYxaZixUOTzkeVnI 3yyYm37SgvQGUmGV/gd8jb8iLDD4s7XrQZWDoUrw4ZutY6BrGiUvBgK0pMTPjDJ4acnI g92AbthEOOcpXFzhYj0ADQKSbQ06lnd/au+evU9dPuvZtN/F17WkyksA8xh4RHgpx1C3 2fIw== 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=RxgN15OKkrUrfti7FFrYvJM5SmFp8w8u19oATId6Vho=; b=eR5vi0f2M0UFGg2GIe0nKIne/Y9L0ctjf5UXywp/LeW17Ct0E7218h0SxDu+obrN3g S/Cl3ghWyH9Q89rzFI2Xdv6cQ9c5K5ah2Xwq+kKnoiPxTD37sEXXZs/o4oRbiidV8wV1 dmq+prIOFjjYn+4TXT9IpL4M+hK3VUrEq6aMq9tvj4rSqqMxpyGPwQZ8PvFvp7vMtzek lCEg1iRHCLjsOWfVxFv8o4hYxzloxDxj1yM2mkzXAt1q+LOC4rzuesSR26mqwN7qih2x gvg53uZ8PqtJe80jgZ7hOD1ejdF9Q5Mfw8YziQGliJjXhP/7C1B86f6jEWDR17/qWZ2m v74Q== X-Gm-Message-State: AKwxytesQdfmA2na0wmTsFWGDoGQ1JkMi8FsAZ3JhhG1xHc/cIvGjV1E EjCRdS4zrQyocr6flYvWp4Xr8jVXHTdHBUS3L/I= X-Google-Smtp-Source: AH8x224RHMyRM9Cd+bHV6RbAqbVhN0qkPUX9NKaG109i7c5mdtuR6bMgGeCgcuMjLgDjkSW6H6Baf8drGZknvdvAooU= X-Received: by 10.202.1.86 with SMTP id 83mr14093495oib.84.1517443215514; Wed, 31 Jan 2018 16:00:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 16:00:15 -0800 (PST) In-Reply-To: <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> From: Martin Thomson Date: Thu, 1 Feb 2018 11:00:15 +1100 Message-ID: Subject: Re: Packet number encryption To: Roberto Peon Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 00:00:18 -0000 Roberto makes a point I keep forgetting. This would allow clients to alternate between connection IDs in a way that the protocol currently cannot support. And that reminds me of another thing: Jana/Eric's connection migration design depends on something like this. Simpler designs that use a gap or randomized offset for each connection ID make linkability trivial if you are alternating between paths in the same way that alternating between connection IDs might. On Thu, Feb 1, 2018 at 10:25 AM, Roberto Peon wrote: > There are two obvious goals/benefits: > 1) Slow/prevent ossification. > 2) Raise the barrier higher for tracking/flow correlating. > > If we have multiple CIDs (which are valid on more than one 5-tuple) and = =E2=80=9Cmultipath=E2=80=9D (one could imagine switching between a bunch of= IPv6 addresses which go to the same hosts) we can require a higher storage= baseline before traffic can be correlated. This is where I believe #2 real= ly comes into play. > > #1 is nothing to sneeze at: experience with TCP has shown very real harm = from having things which allow sequencing of packets in the clear (unable t= o roll out changes which should have been compatible). To me, this is the p= rimary use-case: maintaining future flexibility. > > -=3DR > > On 1/30/18, 11:45 PM, "QUIC on behalf of Mirja K=C3=BChlewind" wrote: > > > > > Am 31.01.2018 um 04:08 schrieb Martin Thomson : > > > > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema wrote: > >>> (1) An unprivileged on-path device that sees a packet from a flow= that is > >>> migrated on purpose by an endpoint (i.e., due to connection migra= tion or > >>> multipath) should not be able to associate that packet to the pri= or flow. > >> > >> Yes. > > > > Agreed. This remains the primary target. I don't think that there > > are any negatives with this design with respect to this use case (o= r > > at least I found nothing in Brian's email on this point). > > If that is the goal, I think the complexity of the proposed solution = is not justified. Just select a new random offset when you migrate but incr= ease the packet number monotonously otherwise to support manageability. > > I=E2=80=99m really concerned about complexity here. Even though this = scheme is not very complex, any complexity is a potential source for future= implementation errors which can also led to restrictions in what changes c= an be deploy with future versions. Making a protocol as simple as possible = and thereby the spec as easy understandable as possible is also key for dep= loyment. If we add complexity here without making it clear what the goal or= additional benefit is of the complexity, I think that is just wrong. > > My 2c. > Mirja > > > From nobody Wed Jan 31 16:17:44 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE65812D861 for ; Wed, 31 Jan 2018 16:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy0-3JIAltvG for ; Wed, 31 Jan 2018 16:17:37 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 8739112ECBE for ; Wed, 31 Jan 2018 16:17:36 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id a7so12323227otk.9 for ; Wed, 31 Jan 2018 16:17:36 -0800 (PST) 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=qnq58GKJbxlpaY6mBHUBAamHC5I5kOQtfgcKyFnGBGs=; b=m4rrOF6tg++pBvh4sRMTKbh5YqIkfAZYXCLPEF01dKHPWNRcJnE8Qwz4xO7lPnbQCS gHdbIIpjXD2ox2cv/EIvf7Z6BRaZzxje6XdSrL/1OREXpqtlJFTrYFHv5m+UTRg65urC w9fDn835pzP92+5/M068bUFL0ZB3Agk+J3FlYL/qzIpwR3BevZnUnAY7+pBMqvNWatld K7+YazZF5gpd00Oa6snXw0EhAKZeK4lGlg2b+UzbCY8x8eui0CZn0IDRPHDz8NwXCjfJ jAe21cmwspGgDFLBE3EUuFN8ByhRswVFv21gLmbWbQ7SwOfAPi0vw1iivWxaHyur9yG6 Igbw== 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=qnq58GKJbxlpaY6mBHUBAamHC5I5kOQtfgcKyFnGBGs=; b=paPalt0aFUQ/BUC49yDaYizy9KVt3rqOfqgOjfLzAY8M7+6+GwhQ7UpHNwRSSX8fD8 u+nrgCmDE6agHNbTcDNDOKbHUFhgwWqRXelK3VnvIbJT3RBIcDbxT+InKLWusXFWSTxv tUpRGpRlG5W1KBRGmTicnyopFwJjDTF6CDR9f46TS/5Jt5rZzhHKNQBBjVRL88kMM7OU DeO8Luh90fIbtgFTl4yoRdB12a4IQSKgudiv+zbebfJQWsFykuB7kLuu+zoI6lkK9XN4 oShjF3lr1xA5S7POZLdWYlHmR+37mCMLRLAg1iQA0jtk6dvgFZcKzxD9jy6sSgFasRWb LDeg== X-Gm-Message-State: AKwxytfV31uzrrlpfyIgkwEx/FDGnjcOlZOAFeXP89jwJiFgKU9XItMm wnyrOHZxFIV6Mlvbvb6ayJkRZy3qB9Hw8bBG4gA= X-Google-Smtp-Source: AH8x2264paWxitxLb/2YU0NGt3WVCVdFqh7GtkQUpFLQ/QQ9qC9ChYYPO7I/9rgodI4pDF2T/EaCITFf6dbW85o/1r8= X-Received: by 10.157.114.157 with SMTP id t29mr10036804otj.252.1517444255429; Wed, 31 Jan 2018 16:17:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Wed, 31 Jan 2018 16:17:05 -0800 (PST) In-Reply-To: <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> From: Ted Hardie Date: Wed, 31 Jan 2018 16:17:05 -0800 Message-ID: Subject: Re: Packet number encryption To: Roberto Peon Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Martin Thomson , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Content-Type: multipart/alternative; boundary="f403045d9562cfc12105641b8595" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Feb 2018 00:17:41 -0000 --f403045d9562cfc12105641b8595 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2018 at 3:25 PM, Roberto Peon wrote: > There are two obvious goals/benefits: > 1) Slow/prevent ossification. > 2) Raise the barrier higher for tracking/flow correlating. > > If we have multiple CIDs (which are valid on more than one 5-tuple) and > =E2=80=9Cmultipath=E2=80=9D (one could imagine switching between a bunch = of IPv6 addresses > which go to the same hosts) we can require a higher storage baseline befo= re > traffic can be correlated. This is where I believe #2 really comes into > play. > Clarifying question: when you says "multiple CIDs which are valid on more than one 5-tuple" do you mean CID 1 is valid for 5-tuple A while CID 2 is valid for 5-tuple B and CID 3 is valid for 5-tuple C, but the communicating peers are really Alice'sPhone and Bob'sBank'sServer93 for all of the above? Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same communicating peers Alice'sPhone and Bob'sBankServer93? Ted --f403045d9562cfc12105641b8595 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Jan 31, 2018 at 3:25 PM, Roberto Peon <fenix@fb.com> wrote:
    There are two obvious goals/benefits:
    1) Slow/prevent ossification.
    2) Raise the barrier higher for tracking/flow correlating.

    If we have multiple CIDs (which are valid on more than one 5-tuple) and =E2= =80=9Cmultipath=E2=80=9D (one could imagine switching between a bunch of IP= v6 addresses which go to the same hosts) we can require a higher storage ba= seline before traffic can be correlated. This is where I believe #2 really = comes into play.
    Clarifying question:=C2=A0 when you says = "multiple CIDs which are valid on more than one 5-tuple" do you m= ean CID 1 is valid for 5-tuple A while CID 2 is valid for 5-tuple B and CID= 3 is valid for 5-tuple C, but the communicating peers are really Alice'= ;sPhone and Bob'sBank'sServer93 for all of the above?=C2=A0=C2=A0 O= r do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same= communicating peers=C2=A0 Alice'sPhone and Bob'sBankServer93?

    Ted
    --f403045d9562cfc12105641b8595-- From nobody Wed Jan 31 16:33:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB3BD12E037 for ; Wed, 31 Jan 2018 16:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi1qXncnMH8w for ; Wed, 31 Jan 2018 16:33:10 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 E5D1A12D835 for ; Wed, 31 Jan 2018 16:33:09 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id a2so3860609otf.2 for ; Wed, 31 Jan 2018 16:33:09 -0800 (PST) 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=lY31CdCIaN97IldnCkaIZBM9diCOdcUUb8Pd/P2QdHQ=; b=FMCD3UnqZ1WBsbImOp4vLHAe3+K4c74WmuR76gULVepW49MAEi8ptgxQ+tsZy2xplq l5zUIFIk0FVt49+fu90P/pLDIJgY9yIFxhEzsB2x7gf99RCONDq9EdE50F7/RV7LFIdE IEqKrxeqglYVFErweegnGdvYrJf588Q1+qx7zSic9HswYKxsIGDWh2+h3k9qO7iE7FCN IzswI8CwTMtmXWqwDb/AbpnzbJgXowbuvSoSwrAK1LTnj9H3lNsF8L834JnbM+hb7PVo FdEEFDl1WDx0dT763ONHoSn+OeWPT07JHbryvoiBOOi+crLoXJOxN0Ns0SGxCneFEYix SSyg== 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=lY31CdCIaN97IldnCkaIZBM9diCOdcUUb8Pd/P2QdHQ=; b=Y7YNWoq2H1j0NJv4qeTErjwR/XpRrT7saOyClbiIUEXsAT+lccQltYA0jaUnHOkM6q 6X1/KcoYsQ3w+jYy6dqXxQkoh/S/g+gDByYX4Gdk3AgJccY/keMv8pc3KcfhPRewrFsr YEaNUtHSDn/6M6FFavHL6XLbzVEFdmjBD9N8/6GuRSwsHCbTZy0r+KMKPzr7AJ+U8igt P6zGrJHMu4+QmW7VBxH22ars1yT1lhWVZT3wNqL5JSPk3aZLyeS1lzgmaEtV9pKciZeZ 8J4SoVHuBL87/f4Etff6KSzFj7MiBjWtjLwmQCz7BbbxMSLM186Rav2Uqj8hvIuHUi9n Vz2w== X-Gm-Message-State: AKwxytcc/NCO3aRR7Y+HntOuS7tweG8mzTAvwUpMX1Db87CzxkHHRYVn CWLIk2080C4+uI5qMBk4Yw1EY3V2uWguJktfyeE= X-Google-Smtp-Source: AH8x226CcUjFhZn7Lav2s96NdKgnOJIElzmifFtt8916vcZput/v8coB7TBT+VszYaM0AzAUegXrkoNWavsbIgDKw4M= X-Received: by 10.157.31.47 with SMTP id x44mr1007761otd.165.1517445189087; Wed, 31 Jan 2018 16:33:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Wed, 31 Jan 2018 16:32:38 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> From: Ted Hardie Date: Wed, 31 Jan 2018 16:32:38 -0800 Message-ID: Subject: Re: Packet number encryption To: Martin Thomson Cc: Roberto Peon , Brian Trammell , Eric Rescorla , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema Content-Type: multipart/alternative; boundary="001a113e2b3076362405641bbdeb" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Feb 2018 00:33:13 -0000 --001a113e2b3076362405641bbdeb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 31, 2018 at 4:00 PM, Martin Thomson wrote: > Roberto makes a point I keep forgetting. This would allow clients to > alternate between connection IDs in a way that the protocol currently > cannot support. > > And that reminds me of another thing: Jana/Eric's connection migration > design depends on something like this. Simpler designs that use a gap > or randomized offset for each connection ID make linkability trivial > if you are alternating between paths in the same way that alternating > between connection IDs might. > > If you are using a standard pattern to probe for path availability before immediate switching, a timing based correlation will work in many cases. If you can break that linkage, what you need is the ability to use packet numbers on each path that do not directly correlate in a way visible to the non-cooperating path elements. If you only care about the make-before-break case of probing, you can achieve that much more simply, but having probe packets use a designated packet number space that doesn't overlap with the actual connection's packet number space until the connection is confirmed, and then does random offset. If you want to use both paths at the same time, then you have the same problem MPTCP sees with sequence number offsets in TCP. That's where I think hiding the packet numbers actually helps, but we haven't gotten any where close to that design in the protocol, and there are other ways to achieve the same thing. I still like this design, but I think we have to be careful in how we describe its benefits; it's not going to break all linkability and it's not going to make connection migration or multipath that much easier. I think that means we should take Mirja's comments on the implementation costs seriously. Ekr has already given an estimate, and I would appreciate estimates from other groups as well. Ted > On Thu, Feb 1, 2018 at 10:25 AM, Roberto Peon wrote: > > There are two obvious goals/benefits: > > 1) Slow/prevent ossification. > > 2) Raise the barrier higher for tracking/flow correlating. > > > > If we have multiple CIDs (which are valid on more than one 5-tuple) and > =E2=80=9Cmultipath=E2=80=9D (one could imagine switching between a bunch = of IPv6 addresses > which go to the same hosts) we can require a higher storage baseline befo= re > traffic can be correlated. This is where I believe #2 really comes into > play. > > > > #1 is nothing to sneeze at: experience with TCP has shown very real har= m > from having things which allow sequencing of packets in the clear (unable > to roll out changes which should have been compatible). To me, this is th= e > primary use-case: maintaining future flexibility. > > > > -=3DR > > > > On 1/30/18, 11:45 PM, "QUIC on behalf of Mirja K=C3=BChlewind" < > quic-bounces@ietf.org on behalf of mirja.kuehlewind@tik.ee.ethz.ch> wrote= : > > > > > > > > > Am 31.01.2018 um 04:08 schrieb Martin Thomson < > martin.thomson@gmail.com>: > > > > > > On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema < > huitema@huitema.net> wrote: > > >>> (1) An unprivileged on-path device that sees a packet from a > flow that is > > >>> migrated on purpose by an endpoint (i.e., due to connection > migration or > > >>> multipath) should not be able to associate that packet to the > prior flow. > > >> > > >> Yes. > > > > > > Agreed. This remains the primary target. I don't think that the= re > > > are any negatives with this design with respect to this use case > (or > > > at least I found nothing in Brian's email on this point). > > > > If that is the goal, I think the complexity of the proposed solutio= n > is not justified. Just select a new random offset when you migrate but > increase the packet number monotonously otherwise to support manageabilit= y. > > > > I=E2=80=99m really concerned about complexity here. Even though thi= s scheme > is not very complex, any complexity is a potential source for future > implementation errors which can also led to restrictions in what changes > can be deploy with future versions. Making a protocol as simple as possib= le > and thereby the spec as easy understandable as possible is also key for > deployment. If we add complexity here without making it clear what the go= al > or additional benefit is of the complexity, I think that is just wrong. > > > > My 2c. > > Mirja > > > > > > > > --001a113e2b3076362405641bbdeb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Jan 31, 2018 at 4:00 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
    Roberto makes a= point I keep forgetting.=C2=A0 This would allow clients to
    alternate between connection IDs in a way that the protocol currently
    cannot support.

    And that reminds me of another thing: Jana/Eric's connection migration<= br> design depends on something like this.=C2=A0 Simpler designs that use a gap=
    or randomized offset for each connection ID make linkability trivial
    if you are alternating between paths in the same way that alternating
    between connection IDs might.

    If you are using a standard patt= ern to probe for path availability before immediate switching, a timing bas= ed correlation will work in many cases. =C2=A0 If you can break that linkag= e, what you need is the ability to use packet numbers on each path that do = not directly correlate in a way visible to the non-cooperating path element= s. =C2=A0 If you only care about the make-before-break case of probing, you= can achieve that much more simply, but having probe packets use a designat= ed packet number space that doesn't overlap with the actual connection&= #39;s packet number space until the connection is confirmed, and then does = random offset.=C2=A0 If you want to use both paths at the same time, then y= ou have the same problem MPTCP sees with sequence number offsets in TCP.=C2= =A0 That's where I think hiding the packet numbers actually helps, but = we haven't gotten any where close to that design in the protocol, and t= here are other ways to achieve the same thing.

    I s= till like this design, but I think we have to be careful in how we describe= its benefits; it's not going to break all linkability and it's not= going to make connection migration or multipath that much easier.=C2=A0 I = think that means we should take Mirja's comments on the implementation = costs seriously.=C2=A0 Ekr has already given an estimate, and I would appre= ciate estimates from other groups as well.

    Ted
    =
    =C2=A0
    On Thu, Feb 1, 2018 at 10:25 AM, Roberto Peon <fenix@fb.com> wrote:
    > There are two obvious goals/benefits:
    > 1) Slow/prevent ossification.
    > 2) Raise the barrier higher for tracking/flow correlating.
    >
    > If we have multiple CIDs (which are valid on more than one 5-tuple) an= d =E2=80=9Cmultipath=E2=80=9D (one could imagine switching between a bunch = of IPv6 addresses which go to the same hosts) we can require a higher stora= ge baseline before traffic can be correlated. This is where I believe #2 re= ally comes into play.
    >
    > #1 is nothing to sneeze at: experience with TCP has shown very real ha= rm from having things which allow sequencing of packets in the clear (unabl= e to roll out changes which should have been compatible). To me, this is th= e primary use-case: maintaining future flexibility.
    >
    > -=3DR
    >
    > On 1/30/18, 11:45 PM, "QUIC on behalf of Mirja K=C3=BChlewind&quo= t; <quic-boun= ces@ietf.org on behalf of mirja.kuehlewind@tik.ee.ethz.ch> wrote:=
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0> Am 31.01.2018 um 04:08 schrieb Martin Thomson = <martin.th= omson@gmail.com>:
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> On Wed, Jan 31, 2018 at 8:00 AM, Christian Hui= tema <huitema@h= uitema.net> wrote:
    >=C2=A0 =C2=A0 =C2=A0>>> (1) An unprivileged on-path device tha= t sees a packet from a flow that is
    >=C2=A0 =C2=A0 =C2=A0>>> migrated on purpose by an endpoint (i.= e., due to connection migration or
    >=C2=A0 =C2=A0 =C2=A0>>> multipath) should not be able to assoc= iate that packet to the prior flow.
    >=C2=A0 =C2=A0 =C2=A0>>
    >=C2=A0 =C2=A0 =C2=A0>> Yes.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Agreed.=C2=A0 This remains the primary target.= =C2=A0 I don't think that there
    >=C2=A0 =C2=A0 =C2=A0> are any negatives with this design with respec= t to this use case (or
    >=C2=A0 =C2=A0 =C2=A0> at least I found nothing in Brian's email = on this point).
    >
    >=C2=A0 =C2=A0 =C2=A0If that is the goal, I think the complexity of the = proposed solution is not justified. Just select a new random offset when yo= u migrate but increase the packet number monotonously otherwise to support = manageability.
    >
    >=C2=A0 =C2=A0 =C2=A0I=E2=80=99m really concerned about complexity here.= Even though this scheme is not very complex, any complexity is a potential= source for future implementation errors which can also led to restrictions= in what changes can be deploy with future versions. Making a protocol as s= imple as possible and thereby the spec as easy understandable as possible i= s also key for deployment. If we add complexity here without making it clea= r what the goal or additional benefit is of the complexity, I think that is= just wrong.
    >
    >=C2=A0 =C2=A0 =C2=A0My 2c.
    >=C2=A0 =C2=A0 =C2=A0Mirja
    >
    >
    >


    --001a113e2b3076362405641bbdeb-- From nobody Wed Jan 31 16:44:51 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3F112D835 for ; Wed, 31 Jan 2018 16:44:49 -0800 (PST) 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 YkmgG5GdgZQe for ; Wed, 31 Jan 2018 16:44:47 -0800 (PST) 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 DC17A12E899 for ; Wed, 31 Jan 2018 16:44:42 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eh2zM-0006dY-57 for quic@ietf.org; Thu, 01 Feb 2018 01:44:28 +0100 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 1eh2zI-0000xy-JI for quic@ietf.org; Wed, 31 Jan 2018 19:44:26 -0500 Received: (qmail 3515 invoked from network); 1 Feb 2018 00:44:19 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Feb 2018 00:44:18 -0000 To: quic@ietf.org References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> From: Christian Huitema Message-ID: <7502d843-d164-1846-064a-d214325ddfe2@huitema.net> Date: Wed, 31 Jan 2018 14:44:19 -1000 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: Packet number encryption X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.18) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gmGh8xhScR3GQeG/UsE/mMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftjlCLaU+2VAPNwxKB1g+mPB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D Rdeg5FXAoSVmuTiBe7bp0P/GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIEs fgSnSGa2hcOygD/l+1E1G4dsgIjOglxo7PfKvIvqBmbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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 Feb 2018 00:44:49 -0000 On 1/31/2018 2:32 PM, Ted Hardie wrote: > I still like this design, but I think we have to be careful in how we > describe its benefits; it's not going to break all linkability and > it's not going to make connection migration or multipath that much > easier. I think that means we should take Mirja's comments on the > implementation costs seriously. Ekr has already given an estimate, > and I would appreciate estimates from other groups as well. About implementation cost, maybe we should wait for feedback from the actual implementations. Only Lars commented so far, and his feedback was "no big deal". If Lars is correct, we ought to be able to demonstrate interoperability soon after draft-10 is published. In any case, we will have some good feedback on actual implementation cost. -- Christian Huitema From nobody Wed Jan 31 17:03:12 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A30713146A for ; Wed, 31 Jan 2018 17:03:10 -0800 (PST) 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=M+ghUjl2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IguuH/Ag Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abW7y9CuAF6T for ; Wed, 31 Jan 2018 17:03:07 -0800 (PST) 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 D5C311315A3 for ; Wed, 31 Jan 2018 17:02:58 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w110wv1Q007698; Wed, 31 Jan 2018 17:02:30 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=GqJ5qCJ6PCi9yqf/KhuP47DV/75KMOMiaYR2TAawPVU=; b=M+ghUjl27WydQEEmuOSmOv3/yeCfIDe6c+Y0sPn2B76ThJRO/qCPmD6C97tBHZsIaSo/ n2AdN/EslacPQQ/Vk5/YW10H4NhNrulxaalSF6KrmZ0oHCHw7XhrRAv0CMu6rUC6u1pX S5BLnCvHj6sbs4KjNj/cp28TjvlhaTXJMzI= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fuqgc0c0t-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 31 Jan 2018 17:02:29 -0800 Received: from PRN-CHUB02.TheFacebook.com (2620:10d:c081:35::11) by PRN-CHUB01.TheFacebook.com (2620:10d:c081:35::10) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 31 Jan 2018 17:02:28 -0800 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.361.1; Wed, 31 Jan 2018 17:02:27 -0800 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=GqJ5qCJ6PCi9yqf/KhuP47DV/75KMOMiaYR2TAawPVU=; b=IguuH/AgATTzwrD0iJrZVr5r49tVRTs4f/CkZpPPr2FH+7wE0BApIYm8HvzcvDzoRkVQ8u4ObizvwDGv7G59U+NC57OZInYRthdGmPRs+OpsR6OmLGWi+0K5E5xQaA8p3LRRElOiELOUZwOVBoGCOxPR3lCTTvhvlBGoC3xNShs= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0711.namprd15.prod.outlook.com (10.164.170.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 01:02:25 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0444.016; Thu, 1 Feb 2018 01:02:25 +0000 From: Roberto Peon To: Ted Hardie CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Thomson , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAAIDjAIAAlG6A//+GjQA= Date: Thu, 1 Feb 2018 01:02:25 +0000 Message-ID: <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:b8cf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0711; 7:icsys2DTBCxAzWC2WnwitMof7ic4bNTExwbWuUKR2EjmAExDtUIEPROozipggtKmzfIXK6n5EJIm3wIn3osu9mn4LlVOsm+6UDYyTFgFE95uq2dcOz2mVCHjWr8JtMdsJ+6FunYT48H49neqNhYt/fsUrKREyaQvKWJVViu3KKdnZGKom/u4b8OKCd+JJ4TnQA51OwssVqGCxQyzWvvN3HWwX+nTGLt5B+EeRFH7ypUBZwGqiP3VIun2mzHsx66q; 20:x4ADjt5lpqUX568poT1F2BEt6cvouAD5MvEOzVxMnOqEuNwRLcnbD1pVNLTzg0EEvn6Z2maMtcMoCPAvAol4FWCoDGOsjim7EMEsjKf0wpL7FE1RKS0My0YUQTLJMQwlwuyrCl9bT5vRcuMfM4WB405g/yo0ZcGRFd+u9WeEu8Q= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8494d10c-5371-4676-8acc-08d5690f7533 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0711; x-ms-traffictypediagnostic: BY2PR15MB0711: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0711; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0711; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39380400002)(346002)(39860400002)(396003)(189003)(199004)(59450400001)(76176011)(478600001)(33656002)(316002)(6916009)(2950100002)(229853002)(68736007)(14454004)(186003)(82746002)(6506007)(236005)(25786009)(6116002)(83716003)(53546011)(6436002)(102836004)(2906002)(6486002)(3280700002)(77096007)(6306002)(39060400002)(6512007)(4326008)(7736002)(3480700004)(86362001)(8676002)(3660700001)(54906003)(8936002)(6246003)(93886005)(106356001)(99286004)(36756003)(7116003)(81166006)(105586002)(97736004)(54896002)(53936002)(5660300001)(2900100001)(81156014)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0711; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 46O0e31J4yCzLhFMw+MhhCy0QNz2lY5lZGy5MhNMBwCi97OuDkSa6TlRG6SMf18mjDXLMeIorMBRX5xgSaVaiQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_7F0C8A1D1CE844E1B3A4ACFCB19D1F12fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8494d10c-5371-4676-8acc-08d5690f7533 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 01:02:25.3125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0711 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-01-31_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Feb 2018 01:03:10 -0000 --_000_7F0C8A1D1CE844E1B3A4ACFCB19D1F12fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGxhdHRlciBhc3N1bWluZyB3ZSBhbGxvdyB0aGUgc2VydmVyIHRvIHNwZWNpZnkgaXQuDQoN Ci09Ug0KDQpGcm9tOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBXZWRu ZXNkYXksIEphbnVhcnkgMzEsIDIwMTggYXQgNDoxOCBQTQ0KVG86IFJvYmVydG8gUGVvbiA8ZmVu aXhAZmIuY29tPg0KQ2M6IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2g+LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiwgQnJp YW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b20+LCBRVUlDIFdHIDxxdWljQGlldGYub3JnPiwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA aHVpdGVtYS5uZXQ+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCk9u IFdlZCwgSmFuIDMxLCAyMDE4IGF0IDM6MjUgUE0sIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29t PG1haWx0bzpmZW5peEBmYi5jb20+PiB3cm90ZToNClRoZXJlIGFyZSB0d28gb2J2aW91cyBnb2Fs cy9iZW5lZml0czoNCjEpIFNsb3cvcHJldmVudCBvc3NpZmljYXRpb24uDQoyKSBSYWlzZSB0aGUg YmFycmllciBoaWdoZXIgZm9yIHRyYWNraW5nL2Zsb3cgY29ycmVsYXRpbmcuDQoNCklmIHdlIGhh dmUgbXVsdGlwbGUgQ0lEcyAod2hpY2ggYXJlIHZhbGlkIG9uIG1vcmUgdGhhbiBvbmUgNS10dXBs ZSkgYW5kIOKAnG11bHRpcGF0aOKAnSAob25lIGNvdWxkIGltYWdpbmUgc3dpdGNoaW5nIGJldHdl ZW4gYSBidW5jaCBvZiBJUHY2IGFkZHJlc3NlcyB3aGljaCBnbyB0byB0aGUgc2FtZSBob3N0cykg d2UgY2FuIHJlcXVpcmUgYSBoaWdoZXIgc3RvcmFnZSBiYXNlbGluZSBiZWZvcmUgdHJhZmZpYyBj YW4gYmUgY29ycmVsYXRlZC4gVGhpcyBpcyB3aGVyZSBJIGJlbGlldmUgIzIgcmVhbGx5IGNvbWVz IGludG8gcGxheS4NCg0KQ2xhcmlmeWluZyBxdWVzdGlvbjogIHdoZW4geW91IHNheXMgIm11bHRp cGxlIENJRHMgd2hpY2ggYXJlIHZhbGlkIG9uIG1vcmUgdGhhbiBvbmUgNS10dXBsZSIgZG8geW91 IG1lYW4gQ0lEIDEgaXMgdmFsaWQgZm9yIDUtdHVwbGUgQSB3aGlsZSBDSUQgMiBpcyB2YWxpZCBm b3IgNS10dXBsZSBCIGFuZCBDSUQgMyBpcyB2YWxpZCBmb3IgNS10dXBsZSBDLCBidXQgdGhlIGNv bW11bmljYXRpbmcgcGVlcnMgYXJlIHJlYWxseSBBbGljZSdzUGhvbmUgYW5kIEJvYidzQmFuaydz U2VydmVyOTMgZm9yIGFsbCBvZiB0aGUgYWJvdmU/ICAgT3IgZG8geW91IG1lYW4gQ0lEcyAxLTMg bWF5IGJlIHVzZWQgb24gYW55IG9mIHRoZSA1LXR1cGxlcyBBLUMsIGZvciB0aGUgc2FtZSBjb21t dW5pY2F0aW5nIHBlZXJzICBBbGljZSdzUGhvbmUgYW5kIEJvYidzQmFua1NlcnZlcjkzPw0KDQpU ZWQNCg== --_000_7F0C8A1D1CE844E1B3A4ACFCB19D1F12fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9AF4108DCD61FA4DAFE4761773A79098@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgbGF0dGVyIGFzc3VtaW5nIHdlIGFs bG93IHRoZSBzZXJ2ZXIgdG8gc3BlY2lmeSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+VGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6 IDwvYj5XZWRuZXNkYXksIEphbnVhcnkgMzEsIDIwMTggYXQgNDoxOCBQTTxicj4NCjxiPlRvOiA8 L2I+Um9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5NaXJq YSBLw7xobGV3aW5kICZsdDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0OywgTWFy dGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDssIEJyaWFuIFRyYW1t ZWxsICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0OywgRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0u Y29tJmd0OywgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDssIENocmlzdGlhbiBIdWl0ZW1h ICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiAzMSwgMjAxOCBhdCAzOjI1IFBN LCBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iIHRhcmdldD0i X2JsYW5rIj5mZW5peEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSB0d28g b2J2aW91cyBnb2Fscy9iZW5lZml0czo8YnI+DQoxKSBTbG93L3ByZXZlbnQgb3NzaWZpY2F0aW9u Ljxicj4NCjIpIFJhaXNlIHRoZSBiYXJyaWVyIGhpZ2hlciBmb3IgdHJhY2tpbmcvZmxvdyBjb3Jy ZWxhdGluZy48YnI+DQo8YnI+DQpJZiB3ZSBoYXZlIG11bHRpcGxlIENJRHMgKHdoaWNoIGFyZSB2 YWxpZCBvbiBtb3JlIHRoYW4gb25lIDUtdHVwbGUpIGFuZCDigJxtdWx0aXBhdGjigJ0gKG9uZSBj b3VsZCBpbWFnaW5lIHN3aXRjaGluZyBiZXR3ZWVuIGEgYnVuY2ggb2YgSVB2NiBhZGRyZXNzZXMg d2hpY2ggZ28gdG8gdGhlIHNhbWUgaG9zdHMpIHdlIGNhbiByZXF1aXJlIGEgaGlnaGVyIHN0b3Jh Z2UgYmFzZWxpbmUgYmVmb3JlIHRyYWZmaWMgY2FuIGJlIGNvcnJlbGF0ZWQuIFRoaXMgaXMNCiB3 aGVyZSBJIGJlbGlldmUgIzIgcmVhbGx5IGNvbWVzIGludG8gcGxheS48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5DbGFyaWZ5aW5nIHF1ZXN0aW9uOiZuYnNwOyB3aGVuIHlvdSBzYXlzICZxdW90O211bHRp cGxlIENJRHMgd2hpY2ggYXJlIHZhbGlkIG9uIG1vcmUgdGhhbiBvbmUgNS10dXBsZSZxdW90OyBk byB5b3UgbWVhbiBDSUQgMSBpcyB2YWxpZCBmb3IgNS10dXBsZSBBIHdoaWxlIENJRCAyIGlzIHZh bGlkIGZvciA1LXR1cGxlIEIgYW5kIENJRCAzIGlzIHZhbGlkIGZvciA1LXR1cGxlIEMsIGJ1dCB0 aGUgY29tbXVuaWNhdGluZyBwZWVycyBhcmUgcmVhbGx5DQogQWxpY2Unc1Bob25lIGFuZCBCb2In c0Jhbmsnc1NlcnZlcjkzIGZvciBhbGwgb2YgdGhlIGFib3ZlPyZuYnNwOyZuYnNwOyBPciBkbyB5 b3UgbWVhbiBDSURzIDEtMyBtYXkgYmUgdXNlZCBvbiBhbnkgb2YgdGhlIDUtdHVwbGVzIEEtQywg Zm9yIHRoZSBzYW1lIGNvbW11bmljYXRpbmcgcGVlcnMmbmJzcDsgQWxpY2Unc1Bob25lIGFuZCBC b2Inc0JhbmtTZXJ2ZXI5Mz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F0C8A1D1CE844E1B3A4ACFCB19D1F12fbcom_-- From nobody Wed Jan 31 18:00:45 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764D112D880 for ; Wed, 31 Jan 2018 18:00:43 -0800 (PST) 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 Ezh0CvUFqWJt for ; Wed, 31 Jan 2018 18:00:41 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 BA07B12EABD for ; Wed, 31 Jan 2018 18:00:41 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id l5so9274032otj.11 for ; Wed, 31 Jan 2018 18:00:41 -0800 (PST) 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=eSzVQiS2ZM2CGyGiKyHQ59nwLLlUPg0RsU+3mIVRS+E=; b=YZl+HoMSpmMfyjKVOIfube0fuOR/EDFW/oobkHjpAxffxwVfOkdFt0WUUv30k6pf3p McXs3VCmJ+5vwgJd0da+rHGL5iyRuoj2zOuvpurk2ve0JBsbgdQ9EkWj49zGxueOLBOT OaWtUagBZVyTWoYmYEA9IKoIVSVESwQMr43YuOJm+/kz9kL/zjH2hl+4LVxcWwXmLr+J 3a0qNH3rxzrqpFH/pyVQU6nLCNoavhYHSg4whq88TgoCvcuuDGG0S38c4x53QErWS2Ha YsqOfUQpt1AV/Oj41vaHFzn+cTdd+QU6LJqwYYcBf40fEXWoTUc2UcqEkWiFWVe/Zcw6 7fPg== 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=eSzVQiS2ZM2CGyGiKyHQ59nwLLlUPg0RsU+3mIVRS+E=; b=lLTjuilEq2O8Ly5mJcGvC0EkDwuBHl0uUbmdPWPZKnA7Y5jdqOVtObzBjfXCZheV+I UkmyErXfwBIak5BRCXvQcHqk8GgiZBBOAWTQpUFoYWEBxwKmPmcZYfKrwDSHXK20lDIx e9V/sDXOPqN2D3qFDKjEYTc8Rrv5NU6gZcc0Yzx7lpKgwvE2DSmZrVTp6zV70qpBES+w OWfsWCw55mo3ViK/uRgcHUbVdqG3K2CJcDyGOZDPd19/ZAKQad7uShJmBl3pBT7xP1oO T2ui0mi3PHm3GAaTnc1X5KrZsbC6x8GpUmVT/XJLIaVkHFbfHV77LjsEQBOI9iRUM+iS WM8g== X-Gm-Message-State: AKwxytd2932nJkPnTJkH3AqE0C97XNXqVyRkqDTpzYCvC0lbIBIyfDkf nIYtQTO3KUdpEQSgmVXiaVK0KGIwWZH0NanWlPk= X-Google-Smtp-Source: AH8x224q7tQ74+2rBhvVv+8ZBLHqoIzs4mZ21cyHdhdV5qwi42ogBl2BVw3Khg+Z8hgHlLSu8Stf4FGI9aZk7d/smPs= X-Received: by 10.157.54.233 with SMTP id s38mr4545510otd.103.1517450440933; Wed, 31 Jan 2018 18:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.249 with HTTP; Wed, 31 Jan 2018 18:00:40 -0800 (PST) In-Reply-To: <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> From: Martin Thomson Date: Thu, 1 Feb 2018 13:00:40 +1100 Message-ID: Subject: Re: Packet number encryption To: Roberto Peon Cc: Ted Hardie , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema 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, 01 Feb 2018 02:00:43 -0000 With some light editing for quoting purposes... On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same >> communicating peers Alice'sPhone and Bob'sBankServer93? > > The latter assuming we allow the server to specify it. I find "assuming we allow the server to specify *it*" to be strangely cryptic. To be clear, my operating assumption is while that servers can provide multiple connection IDs, those connection IDs need to be usable on any 5-tuple. Are you suggesting that a server might need to signal where a connection is usable? (I can see how that might make sense, but it isn't possible with the protocol as specified.) Or are you suggesting that there might need to be some signal that allows clients to distinguish between connection IDs that are for concurrent use? That is, as opposed to what you might assume to be sequential use based on the current specification. FWIW, it should be possible to remove the sequencing field from NEW_CONNECTION_ID after making this change. The only reason left for sequential connection ID use is to give the server the ability to know when certain connection IDs no longer need to be available. A server might then be able to clean up associated state and even reuse them. Of course, that likely only makes sense if the server is creating explicit mappings for each, which - as discussed at the interim - isn't super practical in many deployments. Right now, I think that the assumption is an assumption only, and that relying on strictly linear use of connection IDs would be unwise. From nobody Wed Jan 31 18:25:13 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D8B13175F for ; Wed, 31 Jan 2018 18:25:11 -0800 (PST) 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 gFKhCyw3RqOK for ; Wed, 31 Jan 2018 18:25:10 -0800 (PST) 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 1CA8712EC91 for ; Wed, 31 Jan 2018 18:25:10 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eh4Yl-0004X0-3P for quic@ietf.org; Thu, 01 Feb 2018 03:25:08 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eh4Yi-0007ay-1p for quic@ietf.org; Wed, 31 Jan 2018 21:25:04 -0500 Received: (qmail 6973 invoked from network); 1 Feb 2018 02:25:01 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Feb 2018 02:25:01 -0000 To: Martin Thomson , Roberto Peon References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> Cc: Ted Hardie , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Brian Trammell , QUIC WG From: Christian Huitema Message-ID: <218b5005-4fb5-1577-2699-87a8ab93a90c@huitema.net> Date: Wed, 31 Jan 2018 16:25:01 -1000 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: Packet number encryption X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.16) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5j90Qwll3RzAYIAmbX3Q8kIXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsKeGm+GYYqNLYaw38DBWInB98yDTitFWvbHwz9vKZpm+Fv CFr9jpJ2kLwf6AsfyQqZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLuoPnCd8zMEGMjWpPpP6Z uS+Gz+dPt+p2eC3ntkP+IrLh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Gd20T8xFITcF1bVYFM5+Dh5nHEeB4hpRrmo/duzUUp/Lr cNWSa56tlMgWLlKqQLVzuG+lKlmR7zmDjulXtu9Kl3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+AqMI8XB32z4L/a53NbOeOoj2lB9TLiDMfXuvSrucRXrlnGtGdG3g+ozMfeTuFOSvpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g 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 Feb 2018 02:25:11 -0000 On 1/31/2018 4:00 PM, Martin Thomson wrote: > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. Then maybe we need a way for the client to signal that it won't use a particular ID in the future. For privacy reasons, IDs should only be used on single paths. If a client tries to use a path and then gives up, the ID won't be used anymore. So maybe the client needs to have a way to tell that to the server. Something like an "OLD_CONNECTION_ID" frame. -- Christian Huitema From nobody Wed Jan 31 18:47:05 2018 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A36131499 for ; Wed, 31 Jan 2018 18:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 aQqxDgQmtG2z for ; Wed, 31 Jan 2018 18:46:59 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E080127201 for ; Wed, 31 Jan 2018 18:46:59 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v139so9294773ywg.4 for ; Wed, 31 Jan 2018 18:46:59 -0800 (PST) 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=29KJxcnraH9JZjhlgMT6yTeLnrMCj0ww42PiKdqeTqE=; b=uJhoig+rnFdft3BzJwPyChsmT+nL8jq0PgbhIrlPPrau+5MZ2nwfafCyO6p5sYOiHx +Y1SaTbMFoJogDy2SYR7VrwB81/HvE6sHNotvGvkwvMTgDPCITgPDbQyQTbarRsnJsdH vDa20hZ/XvtiEdlB1nugq5Qb/Kd/jtdEVKV1cxcJx/Wp5vbKCM/UfaEyp2ARNMwY4qcX IVyxDT0oW7s/7xK2NFbTcPuJaGffbImhUo6Q3YxO2EbJqMM39UGY1yZ7nr7foqY4+xb3 Kq4D+CdH6rI9RP3ZVrsP4MHgyDj6lTNBePD51GWWpNDig0GWEgjIFCAzliEIE5l8UD8X KKyQ== 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=29KJxcnraH9JZjhlgMT6yTeLnrMCj0ww42PiKdqeTqE=; b=j3PZnEOujmwjho1OhegikUcdrRKXKc1NVOSTYSXP73fhMtJgbZRUEOA7LhCKLkEY7S yCHx1RlA1JrcMe2Jmjd8VAC0nnEc3oiSPjUNRlKSLSyO2/6gdXPk0idV9kJlSpP50b8H mtFSf10obJOfBbs9hSD+b+ogZF3oyJdCxJivQxS2n+DbxuXOHEyG1i9r89NkmZwqqGdE VNIQgYadzvOg+31bh6HUwAUpGYsVh3gJEqm6lE+MWh7k/j0V9O6I6tzsUBySu9KjU+2V +sUlocHaU+T5oWKUq+6ymwTPNcVwGjq7Ihcl+HUHf2RF9h2zKCALeA4RWPpc1kzNnYKR Y4SA== X-Gm-Message-State: AKwxyteJ2+Vu3UM+UkHeob5nH/r6t0nEwVfIG5liiS4Z6j38gMcjW/bu dMBTJvnTDirqtWQ2xj/O2zhfcY2X5KKAn2qVOa9mYg== X-Google-Smtp-Source: AH8x227V3YDRAMVAg/1XqRAO1bvwR2h8vujmZeSZUYJ0f455+GyCEZv2NNPwpSNaTZb8naq3GrrVhUv48obCUc69KWE= X-Received: by 10.129.60.9 with SMTP id j9mr23410082ywa.315.1517453216582; Wed, 31 Jan 2018 18:46:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.12.70 with HTTP; Wed, 31 Jan 2018 18:46:56 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> From: Jana Iyengar Date: Wed, 31 Jan 2018 18:46:56 -0800 Message-ID: Subject: Re: Packet number encryption To: Martin Thomson Cc: Roberto Peon , Ted Hardie , Eric Rescorla , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Brian Trammell , QUIC WG Content-Type: multipart/alternative; boundary="001a1142e95cf0ccb805641d9bed" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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 Feb 2018 02:47:02 -0000 --001a1142e95cf0ccb805641d9bed Content-Type: text/plain; charset="UTF-8" I like this proposal for the ossification reason that Roberto described, but I also like it because it really simplifies things from an implementation perspective. We currently have packet number gaps to be used with new CIDs, but these are the same packet numbers on the wire as within the transport. So, when used with connection migration or after quiescence, the sender and receiver of ACKs has to deal with potentially large gaps... this is encodable on the wire, sure, but these gaps are unnecessary within the transport. Encrypting packet numbers reduces complexity in that you get a packet number gap on the wire without having to explicitly model it inside the transport. The transport machinery starts packet numbers at 0, increments it by 1 irrespective of migration or quiescence, and the ACK frames similarly carry the plaintext packet number. Separating what's used within the transport and what's visible on the wire allows you to do things like use multiple CIDs within the same 5-tuple. I see it as a clean separation of concerns, with consequent simplification in implementation and an additional degree of freedom. I'm not convinced of the value of packet number in measuring reordering degree, since this can be trivially done by looking at the IP ID field for packets on the same 5-tuple. On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson wrote: > With some light editing for quoting purposes... > > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the > same > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > The latter assuming we allow the server to specify it. > > I find "assuming we allow the server to specify *it*" to be strangely > cryptic. > > To be clear, my operating assumption is while that servers can provide > multiple connection IDs, those connection IDs need to be usable on any > 5-tuple. Are you suggesting that a server might need to signal where > a connection is usable? (I can see how that might make sense, but it > isn't possible with the protocol as specified.) Or are you suggesting > that there might need to be some signal that allows clients to > distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification. > > FWIW, it should be possible to remove the sequencing field from > NEW_CONNECTION_ID after making this change. The only reason left for > sequential connection ID use is to give the server the ability to know > when certain connection IDs no longer need to be available. A server > might then be able to clean up associated state and even reuse them. > > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. > > --001a1142e95cf0ccb805641d9bed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I like this proposal for the ossification reason that Robe= rto described, but I also like it because it really simplifies things from = an implementation perspective.

    We currently have packet number = gaps to be used with new CIDs, but these are the same packet numbers on the= wire as within the transport. So, when used with connection migration or a= fter quiescence, the sender and receiver of ACKs has to deal with potential= ly large gaps... this is encodable on the wire, sure, but these gaps are un= necessary within the transport.

    Encrypting packet numbers reduces co= mplexity in that you get a packet number gap on the wire without having to = explicitly model it inside the transport. The transport machinery starts pa= cket numbers at 0, increments it by 1 irrespective of migration or quiescen= ce, and the ACK frames similarly carry the plaintext packet number. Separat= ing what's used within the transport and what's visible on the wire= allows you to do things like use multiple CIDs within the same 5-tuple.=C2= =A0

    I see it as a clean separation of concerns, wi= th consequent simplification in implementation and an additional degree of = freedom.

    I'm not convinced of the value of pac= ket number in measuring reordering degree, since this can be trivially done= by looking at the IP ID field for packets on the same 5-tuple.
    =

    On Wed, Jan 31, 2= 018 at 6:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
    With some light editing for q= uoting purposes...

    On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote:
    >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, fo= r the same
    >> communicating peers=C2=A0 Alice'sPhone and Bob'sBankServer= 93?
    >
    > The latter assuming we allow the server to spe= cify it.

    I find "assuming we allow the server to specify *it*" to b= e strangely cryptic.

    To be clear, my operating assumption is while that servers can provide
    multiple connection IDs, those connection IDs need to be usable on any
    5-tuple.=C2=A0 Are you suggesting that a server might need to signal where<= br> a connection is usable?=C2=A0 (I can see how that might make sense, but it<= br> isn't possible with the protocol as specified.)=C2=A0 Or are you sugges= ting
    that there might need to be some signal that allows clients to
    distinguish between connection IDs that are for concurrent use? That
    is, as opposed to what you might assume to be sequential use based on
    the current specification.

    FWIW, it should be possible to remove the sequencing field from
    NEW_CONNECTION_ID after making this change.=C2=A0 The only reason left for<= br> sequential connection ID use is to give the server the ability to know
    when certain connection IDs no longer need to be available.=C2=A0 A server<= br> might then be able to clean up associated state and even reuse them.

    Of course, that likely only makes sense if the server is creating
    explicit mappings for each, which - as discussed at the interim -
    isn't super practical in many deployments.=C2=A0 Right now, I think tha= t
    the assumption is an assumption only, and that relying on strictly
    linear use of connection IDs would be unwise.


    --001a1142e95cf0ccb805641d9bed--

    = On Fri, Jan 26, 2018 at 11:56 AM, Roberto Peon <fenix@fb.com> wro= te:
    Counting key-values vs counting heade= r blocks perhaps?
    -=3DR<= br>

    I think you missed my rep= ly, but just in case:

    10 runs * 299 requests in th= e har =3D 2990 total requests.

    =C2=A0

    On 1/25/18, 2:11 PM, "QUIC on behalf of Dmitri Tikhonov" <quic-bounces@ietf.or= g on behalf of dtikhonov@litespeedtech.com> wrote:

    =C2=A0 =C2=A0 On Thu, Jan 25, 2018 at 01:03:28PM -0800, Charles 'Buck&#= 39; Krasic wrote:
    =C2=A0 =C2=A0 > I ran some tests to compare hpack, qcram-03 and qcram-04= .
    =C2=A0 =C2=A0 >
    =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HolBs=C2= =A0 =C2=A0 =C2=A0(%)
    =C2=A0 =C2=A0 > hpack=C2=A0 =C2=A0 =C2=A0 =C2=A0850=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0100
    =C2=A0 =C2=A0 > qcram-03=C2=A0 =C2=A027=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 3.2
    =C2=A0 =C2=A0 > qcram-04=C2=A0 =C2=A046=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 5.4
    =C2=A0 =C2=A0 >
    =C2=A0 =C2=A0 > HolBs here are requests that experienced Hol blocking.
    =C2=A0 =C2=A0 ---8<----

    =C2=A0 =C2=A0 > The har was a facebook of my own.=C2=A0 I got it from ch= rome, using developer
    =C2=A0 =C2=A0 > tools For reference it has 299 requests, and 167955 unco= mpressed header
    =C2=A0 =C2=A0 > bytes.

    =C2=A0 =C2=A0 I am sure I misunderstand something:

    =C2=A0 =C2=A0 - How can the number of requests that experienced HoL
    =C2=A0 =C2=A0 =C2=A0 blocking (850) be larger than the total number of
    =C2=A0 =C2=A0 =C2=A0 requests (299)?

    =C2=A0 =C2=A0 - What does the percentage column (100, 3.2, 5.4) represent?<= br>
    =C2=A0 =C2=A0 =C2=A0 - Dmitri.






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