From nobody Tue Aug 1 05:31:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEDB131D08 for ; Tue, 1 Aug 2017 05:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bz3iNwnA2O1Z for ; Tue, 1 Aug 2017 05:31:33 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217F8126BF3 for ; Tue, 1 Aug 2017 05:31:33 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l82so8761926ywc.2 for ; Tue, 01 Aug 2017 05:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uo+J6Ps6Mc8GMBLOavs+4cP7ZFBturmVuG+rOyFVGZs=; b=GCfdpbazz8dInJPMvoZ4bg0pDcjU4N/8eigZC0VfRJCURtIYjPPdfdH96aSjgneAOf YpXaXtyRCsginuUhO5GaMgqKF1+McJqav7MkvfxzDUE/Y+OEQtr6riR0xnOSvISw7l/D QZXDU7Cscc+7IoSk+VosRv2eAStbs/YcD/4mAbUq+DPRhXiKXD+UIVjXE9UeT1pO7KQZ 1W+G58Jrmw8Bhhw2f+khu0vRKPA7cVP21SRrrFkQRJZ2wy5QeAglReVnyfZ9D2npD6gO gwbqL0RnfROdMpZZdUXSUKCkfkb4kOssgDGtsKBwm/bxx7Ks7/s+HlzwVzeDHpDOoEeQ j/Mw== 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=uo+J6Ps6Mc8GMBLOavs+4cP7ZFBturmVuG+rOyFVGZs=; b=kbqcs3iHqAhIs9S9qaP52Ycl/96N8RmXPC0q2gS/KA/tbNZXmQq+LVaB88aRr7Xt8y rMLh28MyGM61E15ARz3KYIIThp6jBBE21tKcWIjjc7dGQUqDSy90XtAI3M3RnE8o1AU0 BA6P6bVWZTlyHnFAmDX8Gs+XxqMnLXgU00nbT8HPusqyr5QX+83udBsXHrp10oytaCzD V+cC9+lZFtW6ajufBukg98HwtX4NMuhjLSRCZtwIAYUYuyX2voNUGSYyzdN5OeezjiHD ZDeerM8DvZIjN95Lw8sZMiBx8kWYieDgA2TCrSdJDpYEusdVLfofGNuqk+IoVOCiSfxi xMJQ== X-Gm-Message-State: AIVw1110ckqKVr44l+kiLBpUxig46EZAC9iuX4RVGguaKo+e/D1mMNqC bAJo1LQI178lCXID9QAzcX25jYAh1kCE X-Received: by 10.37.65.201 with SMTP id o192mr15808809yba.264.1501590692058; Tue, 01 Aug 2017 05:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Tue, 1 Aug 2017 05:31:11 -0700 (PDT) In-Reply-To: <20170801032805.GA29894@ubuntu-dmitri> References: <20170801032502.GA28788@ubuntu-dmitri> <20170801032805.GA29894@ubuntu-dmitri> From: Ian Swett Date: Tue, 1 Aug 2017 08:31:11 -0400 Message-ID: Subject: Re: Differentiate between GQUIC and QUIC packets To: Dmitri Tikhonov Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c02d20cce11d0555b05334" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 12:31:35 -0000 --001a11c02d20cce11d0555b05334 Content-Type: text/plain; charset="UTF-8" Good question. The plan is for Google to support both during a transition period and the general approach is similar to what you outlined above. The key to resolving the ambiguity is that gQUIC always requires a connection ID from the client to the server, and the intent is to continue to require that for IETF QUIC. Google's server uses the connection ID to lookup the connection, so I believe we'd just discard an incoming packet with no connection ID. On the client side, it knows what version is being spoken, so there's no ambiguity. On Mon, Jul 31, 2017 at 11:28 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Mon, Jul 31, 2017 at 11:25:02PM -0400, Dmitri Tikhonov wrote: > > 1) GQUIC vs QUIC long-header format packet > > > > This is straightforward: the first byte in GQUIC must be zero, > ^^^^^^^^^^^^^^ > > whereas in QUIC's long-header format packet it is set to one. > > This should read "the high bit of the first byte" -- sorry about > that. > > - Dmitri. > > --001a11c02d20cce11d0555b05334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good question.=C2=A0 The plan is for Google to support bot= h during a transition period and the general approach is similar to what yo= u outlined above.=C2=A0 The key to resolving the ambiguity is that gQUIC al= ways requires a connection ID from the client to the server, and the intent= is to continue to require that for IETF QUIC.=C2=A0 Google's server us= es the connection ID to lookup the connection, so I believe we'd just d= iscard an incoming packet with no connection ID.

On the = client side, it knows what version is being spoken, so there's no ambig= uity.

On Mon= , Jul 31, 2017 at 11:28 PM, Dmitri Tikhonov <dtikhonov@litespe= edtech.com> wrote:
On= Mon, Jul 31, 2017 at 11:25:02PM -0400, Dmitri Tikhonov wrote:
> 1) GQUIC vs QUIC long-header format packet
>
>=C2=A0 =C2=A0 =C2=A0This is straightforward: the first byte in GQUIC mu= st be zero,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^^^^^^^^^^^^^
>=C2=A0 =C2=A0 =C2=A0whereas in QUIC's long-header format pack= et it is set to one.

This should read "the high bit of the first byte" -- sorry= about
that.

=C2=A0 - Dmitri.


--001a11c02d20cce11d0555b05334-- From nobody Tue Aug 1 05:55:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E03F12F280 for ; Tue, 1 Aug 2017 05:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=unavailable 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 L8h0yDVdbzMx for ; Tue, 1 Aug 2017 05:55:55 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d: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 E60F91320A4 for ; Tue, 1 Aug 2017 05:50:40 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id a77so8227895qkb.0 for ; Tue, 01 Aug 2017 05:50:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MSGg2H3onYfznO57KwXtRYuLTh2uMH1A0QSKzXiMlQw=; b=Me1SIr8BYS00BdKV/Qp/3iC5lwp5LKcgYUJP2BiEy3zcq6R280V3NB3wBWXvIJ5m7l 8fsI2M9cCY+ZTGTTw1+Li7lNNkx135c+J3q5wHnTuru7RdbQaMsFmQm5knvcYg0BqnlO WBW9NH+cG2zfb8FbwXg8uSkmZDP9r6qY8+umIoNTx3KO3z8iuUaPdVOjaf2Py0Bn6Pgz OmVWFy7xrzyJX9ZQhVoccEGnd7RvizpA78zJNeJR0qhK88g5MvfXmsbf/QELE5AIbuW6 BCX/q/vQoKeRfwjxoBmV+T4BJXDaoZQOPM66FoL+Gxdf68SWNNRA+OhMdH7tXC/N5emM SJBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MSGg2H3onYfznO57KwXtRYuLTh2uMH1A0QSKzXiMlQw=; b=ZCTcuqcw8BoSGnGZITWUZqZOr/tVLuqSlXXWdPCERcH5iLxD7T/dSHq2iWXcFqbckP AEckBQeDhsswsdtDHC/6XQ0wo45aQT7jEobGACd+37onUCOAmEz/xsaJDvcZmAeqd1lj cG3HZZOt6s1pHzE3ULiHHrk/0oiaEZUQnG6AiKbZV2lz/5izHtGnfovEdjC/zfPF69Gx NM+HCLEw1SNODlKCEybpFeSDfuZCxnZPCKnzYjzBetgPvCu4jn4sxgJp2dNDZhlQUwOp iTnLHkVF+k++dbSm8lXZZkAwiiT8IRl/gwkB/HWHlMh/8hYJFEXP+Gj8dXn50qO6D9d5 w1Zg== X-Gm-Message-State: AIVw112g9txwxVyzVUzjpIwxTl4/53fiH5MPG1ujD9d7alvfek2I47Il wpaGUWg9qjc0FgA3 X-Received: by 10.233.237.212 with SMTP id c203mr26434917qkg.328.1501591840088; Tue, 01 Aug 2017 05:50:40 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id v64sm21332640qkd.96.2017.08.01.05.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 05:50:39 -0700 (PDT) Date: Tue, 1 Aug 2017 08:50:32 -0400 From: Dmitri Tikhonov To: Ian Swett Cc: IETF QUIC WG Subject: Re: Differentiate between GQUIC and QUIC packets Message-ID: <20170801125031.GA2742@ubuntu-dmitri> References: <20170801032502.GA28788@ubuntu-dmitri> <20170801032805.GA29894@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 12:55:56 -0000 On Tue, Aug 01, 2017 at 08:31:11AM -0400, Ian Swett wrote: > Good question. The plan is for Google to support both during a transition > period and the general approach is similar to what you outlined above. We at LiteSpeed plan to support both as well, hence my query. :) > The key to resolving the ambiguity is that gQUIC always requires a > connection ID from the client to the server, and the intent is to > continue to require that for IETF QUIC. AFAICT, this requirement is not documented in the latest [draft-ietf-quic-transport]. > Google's server uses the connection ID to lookup the connection, > so I believe we'd just discard an incoming packet with no connection ID. I was hoping to avoid performing a hash lookup... But what you're saying is that this is necessary to resolve ambiguous packets. > On the client side, it knows what version is being spoken, so there's no > ambiguity. *nods* Speaking of clients: is it the plan for Chrome to support both GQUIC and IETF QUIC during the transition period? - Dmitri. From nobody Tue Aug 1 06:09:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB50132146 for ; Tue, 1 Aug 2017 06:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAZw1ri26clp for ; Tue, 1 Aug 2017 06:09:14 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B22B132143 for ; Tue, 1 Aug 2017 06:09:14 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s143so9450528ywg.1 for ; Tue, 01 Aug 2017 06:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5PBC1IdAfUcZY/rdY03jTcJ1Dd17MKJSPF3p/seYlp8=; b=rhF6ytJJtZAP0Y/gLJrjvXnn8BtqYzLzaPN/g01Qg7oGCMfmF9DW8QjAFT7et07jbx rHDSbhN4tXxuiIx6O4L562pxo4MNkmQ0zqSM8m724Pgbgm4c1gRTTFAo4QQNhbU/0xQl GHbiCoPIevA7+nbp+ZLw146/9PpfZXHKHfXWCl3LtZU0E7uF7E9orxpMCVwGZroumaAI 36EqbQXXnkBJYo66HP1Dz1aynXjcVzpkjioI144UahDrVLeVcOgT0+DOeXDV3WCTQyMA 1+4VMGYvyIu7e15Cgy8pLSCWDzh93AAw/nI2oIV1Y/5w9wTW5LHd25Y9iKD4ZKDbzrUR RVyg== 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=5PBC1IdAfUcZY/rdY03jTcJ1Dd17MKJSPF3p/seYlp8=; b=PDhdcauK8k8tlKNWGNnz56oAO60hc9okytkOzBdWaSOIaWQplmEPmrvklfZQOnzJLH mSNrh29iyEerIO0g59qoByCXdwqccyBELJXaHGOvbh/L2u4nKQt0q0padbkc33RefEqy mAkxcQuyTmtKAvpi2z5Mg1zOwYSIGC30X0bZ1w+b3BgBNKZTtnS9TfCoCTactBbPs6yY sfVv6nRAnT3U9Sx0Z0EvyHS1kNaT3hlj86zlkMlPIzzv6BzBeiWrUO8803/rXDaZR8QX XvFzN8kKFkWweQDlZDcT4xX7iKOqdI6SIxO7faRolSmqHN3lJd+duy6dtGbK0E7AH2J4 NvwA== X-Gm-Message-State: AIVw1108Nh5BuUKo8vlNJ/rn3dA+YuvZS107HDy3Vy762ix1tq7edKjR Z7r2rFVURGpoxZuVEFnG9tGsuF1Ns8Yyqxd37g== X-Received: by 10.129.51.67 with SMTP id z64mr16560823ywz.370.1501592953519; Tue, 01 Aug 2017 06:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Tue, 1 Aug 2017 06:08:52 -0700 (PDT) In-Reply-To: <20170801125031.GA2742@ubuntu-dmitri> References: <20170801032502.GA28788@ubuntu-dmitri> <20170801032805.GA29894@ubuntu-dmitri> <20170801125031.GA2742@ubuntu-dmitri> From: Ian Swett Date: Tue, 1 Aug 2017 09:08:52 -0400 Message-ID: Subject: Re: Differentiate between GQUIC and QUIC packets To: Dmitri Tikhonov Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114151969806cc0555b0da19" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:09:16 -0000 --001a114151969806cc0555b0da19 Content-Type: text/plain; charset="UTF-8" On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov wrote: > On Tue, Aug 01, 2017 at 08:31:11AM -0400, Ian Swett wrote: > > Good question. The plan is for Google to support both during a > transition > > period and the general approach is similar to what you outlined above. > > We at LiteSpeed plan to support both as well, hence my query. :) > > > The key to resolving the ambiguity is that gQUIC always requires a > > connection ID from the client to the server, and the intent is to > > continue to require that for IETF QUIC. > > AFAICT, this requirement is not documented in the latest > [draft-ietf-quic-transport]. > The decision about whether to require a connection ID is something negotiated during the handshake, so client and server get to choose whether they require it. Particularly during the transition, it's much easier to require it from the client to server. See the truncate_connection_id transport parameter in 7.3.1 . > > > Google's server uses the connection ID to lookup the connection, > > so I believe we'd just discard an incoming packet with no connection ID. > > I was hoping to avoid performing a hash lookup... But what you're > saying is that this is necessary to resolve ambiguous packets. > You can rely on 5-tuple once the connection is established, but it wouldn't handle NAT rebinding by itself. > > > On the client side, it knows what version is being spoken, so there's no > > ambiguity. > > *nods* > > Speaking of clients: is it the plan for Chrome to support both GQUIC > and IETF QUIC during the transition period? > > Chrome is in the process of migrating towards IETF QUIC, but there is a plan to support at least two versions during the transition. - Dmitri. > --001a114151969806cc0555b0da19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov <dtikhonov@litespe= edtech.com> wrote:
On Tue, Aug 01, 2017 at 08:31:11AM -0400,= Ian Swett wrote:
> Good question.=C2=A0 The plan is for Google to support both during a t= ransition
> period and the general approach is similar to what you outlined above.=

We at LiteSpeed plan to support both as well, hence my query. :)

> The key to resolving the ambiguity is that gQUIC always requires a
> connection ID from the client to the server, and the intent is to
> continue to require that for IETF QUIC.

AFAICT, this requirement is not documented in the latest
[draft-ietf-quic-transport].

The decisi= on about whether to require a connection ID is something negotiated during = the handshake, so client and server get to choose whether they require it.= =C2=A0 Particularly during the transition, it's much easier to require = it from the client to server.

See the truncate_con= nection_id transport parameter in 7.3.1.
=C2=A0
=

> Google's server uses the connection ID to lookup the connection, > so I believe we'd just discard an incoming packet with no connecti= on ID.

I was hoping to avoid performing a hash lookup...=C2=A0 But what you= 're
saying is that this is necessary to resolve ambiguous packets.

You can rely on 5-tuple once the connection is esta= blished, but it wouldn't handle NAT rebinding by itself.

> On the client side, it knows what version is being spoken, so there= 9;s no
> ambiguity.

*nods*

Speaking of clients: is it the plan for Chrome to support both GQUIC
and IETF QUIC during the transition period?


Chrome is in the process of migrating towards = IETF QUIC, but there is a plan to support at least two versions during the = transition.

=C2=A0 - Dmitri.

--001a114151969806cc0555b0da19-- From nobody Tue Aug 1 06:43:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D96132017 for ; Tue, 1 Aug 2017 06:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRPfqWUEnr7N for ; Tue, 1 Aug 2017 06:43:21 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 9D13F1243F3 for ; Tue, 1 Aug 2017 06:43:20 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m85so15269567wma.0 for ; Tue, 01 Aug 2017 06:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IQZb1iHMiYpAuvXORjzDrI4fWk15ILoMLHfsEhWAbIc=; b=oni4uYqvOQKpaWl4K4vbk5UCoWiZOo+XkZJ+mtmQsb45ipuC7cv0wpkkGx16frhw/w 0opCGHPPU6hCdWl1gKOefGiyA8q4wVZvy14i0ypG7kmq3THRaoSFB0cMCFjnNLmmz6Xf ymv/CDeoJZqOA6hz43nd55HxlQ2/VnPC/+ArXTBYIGScPHQcWAdishznL/PiHDI2Ct00 jmO6Utnjo26Hl078Ii5+08kp6ievqY+eJHYsmC5CLDASQSbVHw2GOO0hmgSs2Y45xIKj dXdSn1qqj7Z/cWz1vwz0deTQ02lPcxLCzTxTllYSsSXBZARWz0VdHtzLVRLqJ3LXZ8Ep /d1w== 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=IQZb1iHMiYpAuvXORjzDrI4fWk15ILoMLHfsEhWAbIc=; b=Gj6DlzYijvkA5jrqXEreWkGJL/AkRQgCyHmWdAZHbWryf5pkvrjBfRd+O/aW2e4PMS s3yB8lkf+qabrczxIZpEk6QOCH0AKWASngDWgh6KAQ3tOuv+Mb/kh1TWuTPl8rX/w7Ns Wtkn+8K/UT6Xujb4HgajKkmMbIm8HfZRv2dsxDDian55DUP2ZEnMRxxTFhvop21hJlNL WuYnoEipx+DUwe8rOtNhlyKBIRr6Q0+s0QTEzIk5FBe4M3k3jEQbbYfM8IXyIVWwbd3u SAF8+iEO05n2EvCYyFSQteHyBgxYZF1qv0kT+AKTwIghpchsPliwiw0cNtfc6I5StFTr 0wRg== X-Gm-Message-State: AIVw110tVITUGSywzrXr6gtue+ejAYiGRLpwiBqD1XC41/5VH1Hvx8dD 9FVEGcuRhRq0I5SiRrtYYmdtk0vyhqCrXKw= X-Received: by 10.28.71.5 with SMTP id u5mr1638065wma.138.1501594998881; Tue, 01 Aug 2017 06:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.54.234 with HTTP; Tue, 1 Aug 2017 06:43:15 -0700 (PDT) In-Reply-To: References: <20170801032502.GA28788@ubuntu-dmitri> <20170801032805.GA29894@ubuntu-dmitri> <20170801125031.GA2742@ubuntu-dmitri> From: Ryan Hamilton Date: Tue, 1 Aug 2017 06:43:15 -0700 Message-ID: Subject: Re: Differentiate between GQUIC and QUIC packets To: Ian Swett Cc: Dmitri Tikhonov , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0720fc81c5c80555b154c9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 13:43:22 -0000 --94eb2c0720fc81c5c80555b154c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 1, 2017 at 6:08 AM, Ian Swett wrote: > On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov < > dtikhonov@litespeedtech.com> wrote: > >> >> Speaking of clients: is it the plan for Chrome to support both GQUIC >> and IETF QUIC during the transition period? >> >> > Chrome is in the process of migrating towards IETF QUIC, but there is a > plan to support at least two versions during the transition. > =E2=80=8BGoogle QUIC is continuously evolving. For example, we recently ena= bled v39 which switched from little endian to big endian, and previously v38 changed the behavior of the PADDING frame, all to match the IETF. We're working on v40 at the moment which changes the layout of the ACK and STREAM frames. So over time Google QUIC will become IETF QUIC. Cheers, Ryan --94eb2c0720fc81c5c80555b154c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Aug 1, 2017 at 6:08 AM, Ian Swett <<= a href=3D"mailto:ianswett@google.com" target=3D"_blank" class=3D"cremed">ia= nswett@google.com> wrote:
<= div dir=3D"ltr">
On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:

Speaking of clients: is it the plan for Chrome to support both GQUIC
and IETF QUIC during the transition period?
=

Chrome is in the = process of migrating towards IETF QUIC, but there is a plan to support at l= east two versions during the transition.

=E2=80= =8BGoogle QUIC is continuously evolving. For example, we recently enabled v= 39 which switched from little endian to big endian, and previously v38 chan= ged the behavior of the PADDING frame, all to match the IETF. We're wor= king on v40 at the moment which changes the layout of the ACK and STREAM fr= ames. So over time Google QUIC will become IETF QUIC.

=
Cheers,

Ryan
=
--94eb2c0720fc81c5c80555b154c9-- From nobody Tue Aug 1 08:19:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C29B1321A3 for ; Tue, 1 Aug 2017 08:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com header.b=SSRhngxX; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=verizon.com header.b=Lf5j/Jat; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=verizon.com header.b=Lf5j/Jat Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhs-YTjDRPYs for ; Tue, 1 Aug 2017 08:19:37 -0700 (PDT) Received: from omzsmtpe03.verizonbusiness.com (omzsmtpe03.verizonbusiness.com [199.249.25.208]) (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 DC54512EA95 for ; Tue, 1 Aug 2017 08:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1501600776; x=1533136776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G3fiy7pDS7HFCS13Ya7zTaiPqV9wo1LFwtnEor0VOJQ=; b=SSRhngxXf34/eJbJL4XOm1UfYj6EmkW7ZJoCwB7WOqnSkscMHscZFqkT aSEh3mxW4pbwSdFXJuUmHaUhYH4P8JOeRlo87Cp6bEKGWUS/66qlPxTPZ R/U8JXdhMO4s+0wvc/IA0KKR7Q/Mx2wYtH6E/xJH7gHvGZlqa3qkw1KKY A=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by omzsmtpe03.verizonbusiness.com with ESMTP; 01 Aug 2017 15:19:35 +0000 From: "Mishra, Sanjay" Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO apollo.verizonwireless.com) ([10.255.192.101]) by fldsmtpi02.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 15:18:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1501600733; x=1533136733; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G3fiy7pDS7HFCS13Ya7zTaiPqV9wo1LFwtnEor0VOJQ=; b=Lf5j/JatRsPGu8bz5WPaP/Jw42992Q+v7zTEkFA05B6Vp8gfhWSOOyhN VDzfxkp1zKGFoh1WVHjyj6G+xAF9+OSUzfAaV0DWUd+o02quTECUqajmk Sii47a91+4dY1RB4hkXfveltHNbcaQPQhYkkwPYbltevsoRD53hEx4E4s M=; Received: from ranger.odc.vzwcorp.com (HELO mercury.verizonwireless.com) ([10.255.240.27]) by apollo.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 11:18:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1501600733; x=1533136733; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G3fiy7pDS7HFCS13Ya7zTaiPqV9wo1LFwtnEor0VOJQ=; b=Lf5j/JatRsPGu8bz5WPaP/Jw42992Q+v7zTEkFA05B6Vp8gfhWSOOyhN VDzfxkp1zKGFoh1WVHjyj6G+xAF9+OSUzfAaV0DWUd+o02quTECUqajmk Sii47a91+4dY1RB4hkXfveltHNbcaQPQhYkkwPYbltevsoRD53hEx4E4s M=; X-Host: ranger.odc.vzwcorp.com Received: from casac1exh001.uswin.ad.vzwcorp.com ([10.11.218.43]) by mercury.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 01 Aug 2017 15:18:52 +0000 Received: from scwexch21apd.uswin.ad.vzwcorp.com (153.114.130.40) by CASAC1EXH001.uswin.ad.vzwcorp.com (10.11.218.43) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 1 Aug 2017 08:18:39 -0700 Received: from OMZP1LUMXCA01.uswin.ad.vzwcorp.com (144.8.22.171) by scwexch21apd.uswin.ad.vzwcorp.com (153.114.130.40) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 08:18:39 -0700 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com (144.8.22.181) by OMZP1LUMXCA01.uswin.ad.vzwcorp.com (144.8.22.171) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 1 Aug 2017 10:18:38 -0500 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) by OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) with mapi id 15.00.1263.000; Tue, 1 Aug 2017 10:18:38 -0500 To: Mark Nottingham , IETF QUIC WG CC: Lars Eggert Subject: RE: [E] DRAFT minutes rom IETF99 (Prague) Thread-Topic: [E] DRAFT minutes rom IETF99 (Prague) Thread-Index: AQHTAiIqfzOsQOsi80GVBySItSM+R6JvraNA Date: Tue, 1 Aug 2017 15:18:38 +0000 Message-ID: References: <067CF332-5289-40CD-9901-698446A6C212@mnot.net> In-Reply-To: <067CF332-5289-40CD-9901-698446A6C212@mnot.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: [10.144.60.250] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:19:38 -0000 The link to compatibility matrix from Hackathon is missing in the link plac= e holder in the meeting minutes. >Patrick: Yep five. None had achieved interop of -05 before. Issues: settli= ng on ALPN/TLS versions. [link to compat matrix goes here] No fundamental p= roblems found. Editorial nits. A couple open to consideration. What the WG = meant to write down is what was understood..." -Sanjay -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Friday, July 21, 2017 9:06 AM To: IETF QUIC WG Cc: Lars Eggert Subject: [E] DRAFT minutes rom IETF99 (Prague) ... are at: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_quicwg_= wg-2Dmaterials_blob_master_ietf99_minutes.md&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg= 7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D9a_L6t5TdnDThojv7KBKmqsZzTGM6YylS2wfbAO9KK= 0&m=3Di_-VSjfoNUY0V_uv_GhIZE7MTtsXiKp1b1rlSCoKtAc&s=3DhH-iaYpI5J08iQXsdLJcC= cLRWjqPEs8sZ1qkg9NUTkU&e=3D=20 Corrections welcome as pull requests and in e-mail. Cheers, -- Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__ww= w.mnot.net_&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D= 9a_L6t5TdnDThojv7KBKmqsZzTGM6YylS2wfbAO9KK0&m=3Di_-VSjfoNUY0V_uv_GhIZE7MTts= XiKp1b1rlSCoKtAc&s=3DKKUy3k_M8WOBXS5Zwm37iofs0b5a2DYw_zMbe8Knb1U&e=3D=20 From nobody Tue Aug 1 09:09:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4034131C27 for ; Tue, 1 Aug 2017 09:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMuoQ1Elpbyw for ; Tue, 1 Aug 2017 09:09:08 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCC7126E64 for ; Tue, 1 Aug 2017 09:09:08 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u207so12891812ywc.3 for ; Tue, 01 Aug 2017 09:09:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mOwUHSjI5NLjs3JouhVWjLzYhShhkaldDI14enVttBo=; b=pIBdggi6rGihcNWYhSIng0SnL/7CVuSF8wggUqGq0exCLcNjy7A4qw+pCCRd7DW8eh isStbcve780HNbAh4CP7XuKLg609/Tf/PunsstPG48HSiBYjcoB0j2qg3yssquHN7b/n QtZk1K3CG4vWVHg5sHXeFcmLtIxhUYp6FDMWyeJB4WLizAGjfwm/TSpCSF0oigoNTbuR 6UfiNtVtxeQOY/Oc2SzBh/6Un8L6XhNSDEPyaac+yLGz6k9KR4zC/w301sq9z+4Q9mdj Jy6ZGcwa9YvzT2+cO/vZrWbAehhHMpKUN1oCUUNt22J9ErGm3BljzLOMVMy408KCbG3S SFaQ== 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=mOwUHSjI5NLjs3JouhVWjLzYhShhkaldDI14enVttBo=; b=brPxB75L7hP9Jmvg5+hoGmgR2zeoFIxvaY7n3ZOwDdK4dQoe/gxKrYP+Ss74f4GJkb 6ucF46j+qCLQ/qdP7nfRou8gvvJ2UbqbfraxszWKa9wrngSCd/DxQWUP2lTRO947y359 pzPe5xkVddeizex45MqxQBc1zKfJuCmzQPn5h7SR4msOM1uCrJxPaPdZ0CoReEDUTTgw Ugc2Py1aHHZwLzn3bdJIdNuxBrHwXiy+dKh4Ij/XJfK3eQBbcMoRn8eWABHd813XgJkA Cti42010KeamuMjuCB7IyH7p9ShIPtE9cp63Luy6bmRVXEBx80zqDodHtPZTkR6zQ7Dm 9t2A== X-Gm-Message-State: AIVw112l4E0A8u6rU54dOgr0E51uLWhsHAoiS3ZouPKaIb5HL7iWaYxk CCY3IsFTqFeOPZs10e2FQX63USm7EsQC X-Received: by 10.37.80.144 with SMTP id e138mr18457336ybb.34.1501603747113; Tue, 01 Aug 2017 09:09:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Tue, 1 Aug 2017 09:08:46 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Tue, 1 Aug 2017 12:08:46 -0400 Message-ID: Subject: Re: STOP_SENDING To: Martin Thomson Cc: Mike Bishop , Subodh Iyengar , QUIC WG Content-Type: multipart/alternative; boundary="001a113e887cf16f500555b35d1c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:09:11 -0000 --001a113e887cf16f500555b35d1c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for pointing this out. I think it's easier to make STOP_SENDING retransmittable and then stop sending it once a RST_STREAM is received than the alternatives. As Martin pointed out, the MUST can be enforced well enough that I think it's valuable. In regards to what is retransmittable and what should be. Most frames are easiest left as retransmittable unless there's some benefit to other behavior. Acks are clear cases of this and likely any sort of flow control update frame(including MAX_STREAM_ID) is as well, since you'd be better off sending a new update than retransmitting the old frame. On Mon, Jul 31, 2017 at 8:53 PM, Martin Thomson wrote: > Wow, nice catch Subodh, that's somewhat subtle. This is a frame that > affects stream state that isn't caught up in the state machine. > > Mike is right that you can make the retransmission logic for > STOP_SENDING independent of the stream state, but I think that could > be more cumbersome to manage in implementation than is ideal. > > I think that the simple fix here is as Subodh suggests: mandate the > sending of RST_STREAM in response to STOP_SENDING unless the stream is > already closed. We can then note the optimization that this enables: > you can stop sending STOP_SENDING when the stream is closed. > > Regarding MUST - I recognize that we fall back to the halting problem, > but I can still construct a test that will in most cases detect > misbehaviour: have someone send an infinitely long stream, send > STOP_SENDING in every packet, if they acknowledge packets for some > time without sending RST_STREAM, something is badly wrong. It's not > deterministic, but it's still worth mandating. > > Mike, > > The relationship between retransmissions and stream states is > something that remains open in my mind. What we have appears to be > largely driven by some design choices in the Google implementation. I > don't know if we have an open issue that tracks that, we've > flip-flopped on our position over time and I don't think that we have > a firm consensus on this. That said, it matters much less now that we > have MAX_STREAM_ID. > > > On 1 August 2017 at 10:29, Mike Bishop > wrote: > > Yeah, the retransmission piece of it is interesting. I can see an > argument > > for making it non-retransmittable, but having guidance to periodically > > resend it if you continue to receive data. (Kind of like ACKs =E2=80= =93 you > don=E2=80=99t > > blindly re-send the frame, you re-evaluate what needs to be sent.) > However, > > that seems heavier-weight than simply sending it reliably. Note that > only > > STREAM frames block the transition to =E2=80=9Cclosed,=E2=80=9D and eve= n there the > > transition happens when you have =E2=80=9Ccompleted sending,=E2=80=9D w= hich I don=E2=80=99t read > as > > everything having been ACK=E2=80=99d unless we added that definition so= mewhere > else. > > > > > > > > The previous RST was only somewhat bidirectional =E2=80=93 when you sen= t a > > RST_STREAM, you didn=E2=80=99t know the other side=E2=80=99s final offs= et, so you > couldn=E2=80=99t > > wind down their side of the stream until they also sent a RST_STREAM. > > That=E2=80=99s still the case, but now it=E2=80=99s more honest =E2=80= =93 the stream continues > to be > > open in the other direction until they actually send the RST_STREAM. > > > > > > > > Conceptually, I=E2=80=99d be okay with a =E2=80=9CMUST send RST_STREAM = unless the stream > is > > already closed,=E2=80=9D but this is almost impossible to verify, even = if you > start > > tracking what streams show up in packet numbers after the ACK of the > packet > > that contained the STOP_SENDING frame. My general rule is that if the > other > > party can=E2=80=99t be certain whether you violated a MUST, it needs to= be a > SHOULD. > > > > > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar > > Sent: Monday, July 31, 2017 4:58 PM > > To: Martin Thomson ; QUIC WG > > Subject: Re: STOP_SENDING > > > > > > > > I commented on the PR, but had a design comment > > > > Sending one more frame type has the added burden of needing to > retransmit it > > before we go to closed state unless we make STOP_SENDING non > > retransmittable. Since this frame type is advisory anyway, does it real= ly > > need to be retransmittable? Also it doesn't make sense to send this if = we > > have received the peers RST. A peer's RST might have raced with our > > STOP_SENDING and the peer might have got rid of state for the stream. > Thus > > any retransmitted STOP_SENDING frames might just be ignored. > > > > > > > > Previously we had a bidirectional RST. With this change, it makes me a > bit > > nervous for an endpoint to rely on a peer following advisory behavior f= or > > them to be able to close their stream, for example what would we do > about a > > client that chooses not to send a RST on STOP_SENDING, do we rely on > stream > > limits only? close the connection? It would be much more comfortable > with a > > client MUST send a RST when getting a STOP_SENDING. > > > > Subodh > > > > > > > > ________________________________ > > > > From: QUIC on behalf of Martin Thomson > > > > Sent: Sunday, July 30, 2017 5:10 PM > > To: QUIC WG > > Subject: STOP_SENDING > > > > > > > > https://github.com/quicwg/base-drafts/pull/171 > > > > As mentioned in Prague, I want to merge the PR formerly known as > > DISINTEREST. Mike has updated it and it is now ready to do. I plan > > to merge this in 48 hours, absent any substantial objections. > > --001a113e887cf16f500555b35d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for pointing this out.

I think i= t's easier to make STOP_SENDING retransmittable and then stop sending i= t once a RST_STREAM is received than the alternatives.

As Martin pointed out, the MUST can be enforced well enough that I think= it's valuable.

In regards to what is re= transmittable and what should be.=C2=A0 Most frames are easiest left as ret= ransmittable unless there's some benefit to other behavior.=C2=A0 Acks = are clear cases of this and likely any sort of flow control update frame(in= cluding MAX_STREAM_ID) is as well, since you'd be better off sending a = new update than retransmitting the old frame.

On Mon, Jul 31, 2017 at 8:53 PM, Ma= rtin Thomson <martin.thomson@gmail.com> wrote:
Wow, nice catch Subodh, that's somewhat sub= tle.=C2=A0 This is a frame that
affects stream state that isn't caught up in the state machine.

Mike is right that you can make the retransmission logic for
STOP_SENDING independent of the stream state, but I think that could
be more cumbersome to manage in implementation than is ideal.

I think that the simple fix here is as Subodh suggests: mandate the
sending of RST_STREAM in response to STOP_SENDING unless the stream is
already closed.=C2=A0 We can then note the optimization that this enables:<= br> you can stop sending STOP_SENDING when the stream is closed.

Regarding MUST - I recognize that we fall back to the halting problem,
but I can still construct a test that will in most cases detect
misbehaviour: have someone send an infinitely long stream, send
STOP_SENDING in every packet, if they acknowledge packets for some
time without sending RST_STREAM, something is badly wrong.=C2=A0 It's n= ot
deterministic, but it's still worth mandating.

Mike,

The relationship between retransmissions and stream states is
something that remains open in my mind.=C2=A0 What we have appears to be largely driven by some design choices in the Google implementation.=C2=A0 I=
don't know if we have an open issue that tracks that, we've
flip-flopped on our position over time and I don't think that we have a firm consensus on this.=C2=A0 That said, it matters much less now that we=
have MAX_STREAM_ID.


On 1 August 2017 at 10:29, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> Yeah, the retransmission piece of it is interesting.=C2=A0 I can see a= n argument
> for making it non-retransmittable, but having guidance to periodically=
> resend it if you continue to receive data.=C2=A0 (Kind of like ACKs = =E2=80=93 you don=E2=80=99t
> blindly re-send the frame, you re-evaluate what needs to be sent.)=C2= =A0 However,
> that seems heavier-weight than simply sending it reliably.=C2=A0 Note = that only
> STREAM frames block the transition to =E2=80=9Cclosed,=E2=80=9D and ev= en there the
> transition happens when you have =E2=80=9Ccompleted sending,=E2=80=9D = which I don=E2=80=99t read as
> everything having been ACK=E2=80=99d unless we added that definition s= omewhere else.
>
>
>
> The previous RST was only somewhat bidirectional =E2=80=93 when you se= nt a
> RST_STREAM, you didn=E2=80=99t know the other side=E2=80=99s final off= set, so you couldn=E2=80=99t
> wind down their side of the stream until they also sent a RST_STREAM.<= br> > That=E2=80=99s still the case, but now it=E2=80=99s more honest =E2=80= =93 the stream continues to be
> open in the other direction until they actually send the RST_STREAM. >
>
>
> Conceptually, I=E2=80=99d be okay with a =E2=80=9CMUST send RST_STREAM= unless the stream is
> already closed,=E2=80=9D but this is almost impossible to verify, even= if you start
> tracking what streams show up in packet numbers after the ACK of the p= acket
> that contained the STOP_SENDING frame.=C2=A0 My general rule is that i= f the other
> party can=E2=80=99t be certain whether you violated a MUST, it needs t= o be a SHOULD.
>
>
>
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Subodh Iyengar
> Sent: Monday, July 31, 2017 4:58 PM
> To: Martin Thomson <mar= tin.thomson@gmail.com>; QUIC WG <quic@ietf.org>
> Subject: Re: STOP_SENDING
>
>
>
> I commented on the PR, but had a design comment
>
> Sending one more frame type has the added burden of needing to retrans= mit it
> before we go to closed state unless we make STOP_SENDING non
> retransmittable. Since this frame type is advisory anyway, does it rea= lly
> need to be retransmittable? Also it doesn't make sense to send thi= s if we
> have received the peers RST. A peer's RST might have raced with ou= r
> STOP_SENDING and the peer might have got rid of state for the stream. = Thus
> any retransmitted STOP_SENDING frames might just be ignored.
>
>
>
> Previously we had a bidirectional RST. With this change, it makes me a= bit
> nervous for an endpoint to rely on a peer following advisory behavior = for
> them to be able to close their stream, for example what would we do ab= out a
> client that chooses not to send a RST on STOP_SENDING, do we rely on s= tream
> limits only? close the connection? It would be much more comfortable w= ith a
> client MUST send a RST when getting a STOP_SENDING.
>
> Subodh
>
>
>
> ________________________________
>
> From: QUIC <quic-bounces@i= etf.org> on behalf of Martin Thomson
> <martin.thomson@gmail.c= om>
> Sent: Sunday, July 30, 2017 5:10 PM
> To: QUIC WG
> Subject: STOP_SENDING
>
>
>
> https://github.com/quicwg/base-drafts/pull/1= 71
>
> As mentioned in Prague, I want to merge the PR formerly known as
> DISINTEREST.=C2=A0 Mike has updated it and it is now ready to do.=C2= =A0 I plan
> to merge this in 48 hours, absent any substantial objections.


--001a113e887cf16f500555b35d1c-- From nobody Tue Aug 1 09:49:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B74131DF7 for ; Tue, 1 Aug 2017 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqBsME06SGLo for ; Tue, 1 Aug 2017 09:49:46 -0700 (PDT) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 974B6126C7A for ; Tue, 1 Aug 2017 09:49:46 -0700 (PDT) Received: by mail-vk0-x22b.google.com with SMTP id u133so8463754vke.3 for ; Tue, 01 Aug 2017 09:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=kL8CxVlUVA0SThE4hI9Ejq6yXoFf5TvuXOWWrjzB0T0=; b=r0hTDylZMS0b2hRRns+K/qGJGJbLlmogLzb5vgrU40YESRla+f8jhV0w9Wn+BpSCRy T09oJX2NhDGzdtwq9rx8yYvKuSknb4x6YonX08SlQcjSQYz4LS0GeCQ3dfHMD2CozCp5 3GpTYWdKYgQhXpw8xl/83SIDfOMWsn74VBMwYJQFeHcFavsRcJnDKkDHPo4tCMJfKaVe sltkZiUFIFnNllQDJwFNMLDkLe/pE74GB97Icb6BjKOAUPsoBws5AJKyWT47vtTduJf6 KDHFN8q4NmDRDhOhd67vvdeG+9au93gFyBAR4c9AVmDwiXC5iGhZmvRe+QJr5yLZ3l9P OA3g== 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=kL8CxVlUVA0SThE4hI9Ejq6yXoFf5TvuXOWWrjzB0T0=; b=CZBhW8wV+PjpAyU+ZKhtFfzCJ/maOj1Ecypt6jOg9PcRTMrvZprSyTWvRAu3bjbb45 1kabEQZYHIMX1IrQqbQZgM4SNRqJQED5zW6+XKgwzQHEIZXTNhvOFJDAf2e0Xc+iA9Cz 2vOdXJrBOUM4grNh8+FjXmNOqKwR4r56zTPqqQFcdJBgss9bb5DY4Fj2YsPnqFNLcJQO cfpPObzx++hIpjWveJ1YzpIZHX/HcHDMqjUJofWw/7QdAZIDT8JoQr9sKeqI7Oe739hi LWhkC5fU+scw86wwY2ynjCdc0PbpU5GmFbHVfTLnCLDBUIzZ6zdtzB4vErsa0EcCKePS 6n0w== X-Gm-Message-State: AIVw112doQvx3FOyD6mTCodOlWQvkBlDbGbI8pb2Rp/7I5iQmTU5j0Zz EOn+nA2oIpjxl4nLO14/oIo38Cpv9p+E X-Received: by 10.31.53.3 with SMTP id c3mr11350466vka.78.1501606185790; Tue, 01 Aug 2017 09:49:45 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 1 Aug 2017 09:49:44 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 1 Aug 2017 09:49:44 -0700 Message-ID: Subject: Re: STOP_SENDING To: Martin Thomson , Ian Swett Cc: QUIC WG , Mike Bishop , Subodh Iyengar Content-Type: multipart/alternative; boundary="001a11447e9a4bf44e0555b3ef77" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 16:49:48 -0000 --001a11447e9a4bf44e0555b3ef77 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > I think it's easier to make STOP_SENDING retransmittable and then stop sending it once a RST_STREAM is received than the alternatives. I=E2=80=99m only half reading along atm., but I don=E2=80=99t think it is g= ood for the retransmission logic to reach back into stream state if it can be avoided, or vice versa. It can be done of course, and this is probably not the only place. If STOP_SENDING is not retransmittable, some timer state is needed, which is annoying, so I agree with IAN that retransmission is easier, just not that RST_STREAM necessarily must cancel - it can race regardless. If STOP_SENDING is retransmittable, it is fire and forget. Should a RST_STREAM be received meanwhile, the late STOP_SENDING should do no harm. No point in making it an error to receive late STOP_SENDING, other than the general receive stream related packets very late. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 1 August 2017 at 18.09.19, Ian Swett (ianswett@google.com) wrote: I think it's easier to make STOP_SENDING retransmittable and then stop sending it once a RST_STREAM is received than the alternatives. --001a11447e9a4bf44e0555b3ef77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
> I think it's easier to make STOP_SEND= ING retransmittable and then stop sending it once a RST_STREAM is received = than the alternatives.

I=E2=80=99m only half reading along atm., but I don=E2=80=99t thin= k it is good for the retransmission logic to=C2=A0reach back into stream st= ate if it can be avoided, or vice versa. It can be done of course, and this= is probably not the only place.

If STOP_SENDING is not retransmittable, some timer stat= e is needed, which is annoying, so I agree with IAN that retransmission is = easier, just not that RST_STREAM necessarily=C2=A0must cancel - it can race= regardless.
If STOP_SENDING is=C2=A0retransmittable, it is fire and forget. Should = a RST_STREAM be=C2=A0received meanwhile, the late STOP_SENDING should do no= harm. No point in making it an error to receive late STOP_SENDING,=C2=A0ot= her than the general receive stream related packets very late.

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


On 1= August 2017 at 18.09.19, Ian Swett (ianswett@google.com) wrote:

I think it's ea= sier to make STOP_SENDING retransmittable and then stop sending it once a R= ST_STREAM is received than the alternatives.
 --001a11447e9a4bf44e0555b3ef77-- From nobody Tue Aug 1 11:15:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFF31321E3 for ; Tue, 1 Aug 2017 11:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFTX5ypyvyPr for ; Tue, 1 Aug 2017 11:15:01 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0099.outbound.protection.outlook.com [104.47.36.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D9F1321E7 for ; Tue, 1 Aug 2017 11:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ALob+JwCgVZJXZgODACkf4rj5q9/qpIkDHwnxjy43us=; b=Sy3+fS+NjBJl9sOv3NL2LqNfTBUSk8OiO0CB+WixSJo6ToBZCH268vc/H1a6YCbL6jGz5SaTSJLTGiVwYnEd1hLw3acG1OZxLqiG8TtcIeVzw5jrQIx6y1CCn8f9tJwdTHExJdo/gpF+zdJR6lPv2THlsVkrs8+tJupPjVDEh/k= Received: from BN6PR21MB0130.namprd21.prod.outlook.com (10.173.199.144) by BN6PR21MB0129.namprd21.prod.outlook.com (10.173.199.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.0; Tue, 1 Aug 2017 18:14:59 +0000 Received: from BN6PR21MB0130.namprd21.prod.outlook.com ([10.173.199.144]) by BN6PR21MB0130.namprd21.prod.outlook.com ([10.173.199.144]) with mapi id 15.01.1341.000; Tue, 1 Aug 2017 18:14:59 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson , Ian Swett CC: QUIC WG , Subodh Iyengar Subject: RE: STOP_SENDING Thread-Topic: STOP_SENDING Thread-Index: AQHTCZGFwh/s1ctV8UmjTeq6nd+wlKJunmsAgAADa7CAAAw2AIAA/7kAgAALcgCAABdn4A== Date: Tue, 1 Aug 2017 18:14:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:7::600] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0129; 6:DTJ+qgTnV3CNBT/uRWeAxnGxrpmp2spoM2zbowWx7DzAHb7e0tnvaTDB9/ZIwfs+J+HIc0UjiOMWX48IxGtHz356zNl5BbU6x8M0OnrNUGreZugpEEWl+dNBbrA9Wb0JgDAfyXMWYV0B6IeegJyrwI9XZb/9/SbkZtKm5NUWOJAQa+AooMNXPhd1dO0s2tL1ybA8km0VETInJlndqF8hupcpch6fAF3gsnEJRu8On6W6wvr4nEUy7JvPfnhjjbVLx/9temkVwe5XE/kY1AksfAlPUDgsrGoymYXGUKkVwOnmMSrzBAT6w4WDWTqy/rHO97IzTY2XN83GChzdtE0byQ==; 5:A56D2LyehmV1SoPljwzuMhv3UCrsKoUGpZSVM3kTTWQki2sqsUunezyzRyGcBlf6rED+5IxIvhnMJSHVnVppbPsQoCrA6cU7wJG6US9M4MbWWSYwGk7f/d2Ut0FMo58tS16283j2rNw9k7n2jy9Jpg==; 24:qt6mrSBl5+c5Irqovklfrkhki0/Z5WWVbw/H1vEE3Ubq/sw5IgyQJqJ6bw0JUO8KddLNT8Kcy5tCUzF3EpMEMxITTOyzo2UNzw/DPY8ZRiY=; 7:EmfdGGgJVAaKpDF/e704X5zWQUxpcPIl97GRu/YnJA3OY0m3MoO58d3nUZQWp4sLTBTFetpPVD88Asc3+JmLntVcZ9nCNSGUWoLmwdzqwTe59O/Zr12SSPypYQuCZdIq4bRP6BRnMZkdx8Qbn9Fxmq3tGiKBHc33Qs5ksiThqAAwa6B9tAh/A+M5ORrD6I/g6dFZB7AR6yxDarsloErAgoldTYsnbu5pnGldZnXG0ac= x-ms-office365-filtering-correlation-id: 715985a5-69f3-4661-f51b-08d4d90938bd x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN6PR21MB0129; x-ms-traffictypediagnostic: BN6PR21MB0129: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(89211679590171)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN6PR21MB0129; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN6PR21MB0129; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39850400002)(39840400002)(39400400002)(39410400002)(39860400002)(47760400005)(189002)(24454002)(199003)(377454003)(3660700001)(54896002)(74316002)(77096006)(3280700002)(105586002)(6506006)(86612001)(7696004)(6246003)(33656002)(53546010)(106356001)(5005710100001)(54906002)(6436002)(2906002)(76176999)(54356999)(50986999)(101416001)(9686003)(8990500004)(55016002)(6116002)(6306002)(86362001)(99286003)(53936002)(34040400001)(790700001)(102836003)(39060400002)(10290500003)(10090500001)(189998001)(25786009)(478600001)(236005)(8936002)(2950100002)(7736002)(38730400002)(5660300001)(7116003)(2900100001)(19609705001)(72206003)(97736004)(81166006)(14454004)(8676002)(81156014)(93886004)(68736007)(4326008)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0129; H:BN6PR21MB0130.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0130745F30A3F6DDA6FA1E5187B30BN6PR21MB0130namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 18:14:59.3957 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0129 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:15:04 -0000 --_000_BN6PR21MB0130745F30A3F6DDA6FA1E5187B30BN6PR21MB0130namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2theSDigJMgSeKAmXZlIGNoYW5nZWQgdGhlIFNIT1VMRCB0byBhIE1VU1QgYW5kIGFkZGVkIHNp bWlsYXIgdGV4dCB0byB0aGF0IGFib3V0IFNUUkVBTSBmcmFtZXMg4oCTIOKAnE1VU1QgcmV0cmFu c21pdCB1bmxlc3PigKYu4oCdICBJbiB0aGUgc2VjdGlvbiBzcGVjaWZpY2FsbHkgYWJvdXQgcmVx dWVzdGluZyB0aGUgcGVlciB0byBzdG9wIHNlbmRpbmcsIGl0IHNheXMgdGhhdCB5b3UgTUFZIHN0 b3AgcmV0cmFuc21pc3Npb24gaWYgdGhlIHN0cmVhbSBoYXMgY2xvc2VkIG9uIGl0cyBvd24uDQoN CkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5j b21dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMSwgMjAxNyA5OjUwIEFNDQpUbzogTWFydGluIFRo b21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWlrZSBCaXNob3AgPE1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbT4N ClN1YmplY3Q6IFJlOiBTVE9QX1NFTkRJTkcNCg0KPiBJIHRoaW5rIGl0J3MgZWFzaWVyIHRvIG1h a2UgU1RPUF9TRU5ESU5HIHJldHJhbnNtaXR0YWJsZSBhbmQgdGhlbiBzdG9wIHNlbmRpbmcgaXQg b25jZSBhIFJTVF9TVFJFQU0gaXMgcmVjZWl2ZWQgdGhhbiB0aGUgYWx0ZXJuYXRpdmVzLg0KDQpJ 4oCZbSBvbmx5IGhhbGYgcmVhZGluZyBhbG9uZyBhdG0uLCBidXQgSSBkb27igJl0IHRoaW5rIGl0 IGlzIGdvb2QgZm9yIHRoZSByZXRyYW5zbWlzc2lvbiBsb2dpYyB0byByZWFjaCBiYWNrIGludG8g c3RyZWFtIHN0YXRlIGlmIGl0IGNhbiBiZSBhdm9pZGVkLCBvciB2aWNlIHZlcnNhLiBJdCBjYW4g YmUgZG9uZSBvZiBjb3Vyc2UsIGFuZCB0aGlzIGlzIHByb2JhYmx5IG5vdCB0aGUgb25seSBwbGFj ZS4NCg0KSWYgU1RPUF9TRU5ESU5HIGlzIG5vdCByZXRyYW5zbWl0dGFibGUsIHNvbWUgdGltZXIg c3RhdGUgaXMgbmVlZGVkLCB3aGljaCBpcyBhbm5veWluZywgc28gSSBhZ3JlZSB3aXRoIElBTiB0 aGF0IHJldHJhbnNtaXNzaW9uIGlzIGVhc2llciwganVzdCBub3QgdGhhdCBSU1RfU1RSRUFNIG5l Y2Vzc2FyaWx5IG11c3QgY2FuY2VsIC0gaXQgY2FuIHJhY2UgcmVnYXJkbGVzcy4NCklmIFNUT1Bf U0VORElORyBpcyByZXRyYW5zbWl0dGFibGUsIGl0IGlzIGZpcmUgYW5kIGZvcmdldC4gU2hvdWxk IGEgUlNUX1NUUkVBTSBiZSByZWNlaXZlZCBtZWFud2hpbGUsIHRoZSBsYXRlIFNUT1BfU0VORElO RyBzaG91bGQgZG8gbm8gaGFybS4gTm8gcG9pbnQgaW4gbWFraW5nIGl0IGFuIGVycm9yIHRvIHJl Y2VpdmUgbGF0ZSBTVE9QX1NFTkRJTkcsIG90aGVyIHRoYW4gdGhlIGdlbmVyYWwgcmVjZWl2ZSBz dHJlYW0gcmVsYXRlZCBwYWNrZXRzIHZlcnkgbGF0ZS4NCg0KS2luZCBSZWdhcmRzLA0KTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDEgQXVndXN0IDIwMTcgYXQgMTguMDkuMTksIElh biBTd2V0dCAoaWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4p IHdyb3RlOg0KSSB0aGluayBpdCdzIGVhc2llciB0byBtYWtlIFNUT1BfU0VORElORyByZXRyYW5z bWl0dGFibGUgYW5kIHRoZW4gc3RvcCBzZW5kaW5nIGl0IG9uY2UgYSBSU1RfU1RSRUFNIGlzIHJl Y2VpdmVkIHRoYW4gdGhlIGFsdGVybmF0aXZlcy4NCg== --_000_BN6PR21MB0130745F30A3F6DDA6FA1E5187B30BN6PR21MB0130namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rYXkg 4oCTIEnigJl2ZSBjaGFuZ2VkIHRoZSBTSE9VTEQgdG8gYSBNVVNUIGFuZCBhZGRlZCBzaW1pbGFy IHRleHQgdG8gdGhhdCBhYm91dCBTVFJFQU0gZnJhbWVzIOKAkyDigJxNVVNUIHJldHJhbnNtaXQg dW5sZXNz4oCmLuKAnSZuYnNwOyBJbiB0aGUgc2VjdGlvbiBzcGVjaWZpY2FsbHkgYWJvdXQgcmVx dWVzdGluZyB0aGUgcGVlciB0byBzdG9wIHNlbmRpbmcsIGl0IHNheXMgdGhhdCB5b3UgTUFZIHN0 b3AgcmV0cmFuc21pc3Npb24gaWYNCiB0aGUgc3RyZWFtIGhhcyBjbG9zZWQgb24gaXRzIG93bi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpA Z21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEF1Z3VzdCAxLCAyMDE3IDk6 NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20mZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgTWlrZSBCaXNob3AgJmx0 O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyBTdWJvZGggSXllbmdhciAmbHQ7c3Vi b2RoQGZiLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNUT1BfU0VORElORzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyBJIHRoaW5rIGl0J3MgZWFzaWVyIHRvIG1h a2UgU1RPUF9TRU5ESU5HIHJldHJhbnNtaXR0YWJsZSBhbmQgdGhlbiBzdG9wIHNlbmRpbmcgaXQg b25jZSBhIFJTVF9TVFJFQU0gaXMgcmVjZWl2ZWQgdGhhbiB0aGUgYWx0ZXJuYXRpdmVzLjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJs b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PknigJltIG9ubHkgaGFsZiByZWFkaW5nIGFsb25nIGF0bS4sIGJ1dCBJIGRvbuKAmXQgdGhpbmsg aXQgaXMgZ29vZCBmb3IgdGhlIHJldHJhbnNtaXNzaW9uIGxvZ2ljIHRvJm5ic3A7cmVhY2ggYmFj ayBpbnRvIHN0cmVhbSBzdGF0ZSBpZiBpdCBjYW4gYmUgYXZvaWRlZCwgb3IgdmljZSB2ZXJzYS4g SXQgY2FuIGJlDQogZG9uZSBvZiBjb3Vyc2UsIGFuZCB0aGlzIGlzIHByb2JhYmx5IG5vdCB0aGUg b25seSBwbGFjZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5JZiBTVE9QX1NFTkRJTkcgaXMgbm90IHJldHJhbnNtaXR0YWJsZSwg c29tZSB0aW1lciBzdGF0ZSBpcyBuZWVkZWQsIHdoaWNoIGlzIGFubm95aW5nLCBzbyBJIGFncmVl IHdpdGggSUFOIHRoYXQgcmV0cmFuc21pc3Npb24gaXMgZWFzaWVyLCBqdXN0IG5vdCB0aGF0IFJT VF9TVFJFQU0gbmVjZXNzYXJpbHkmbmJzcDttdXN0DQogY2FuY2VsIC0gaXQgY2FuIHJhY2UgcmVn YXJkbGVzcy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgU1RPUF9TRU5ESU5HIGlzJm5ic3A7cmV0cmFuc21pdHRh YmxlLCBpdCBpcyBmaXJlIGFuZCBmb3JnZXQuIFNob3VsZCBhIFJTVF9TVFJFQU0gYmUmbmJzcDty ZWNlaXZlZCBtZWFud2hpbGUsIHRoZSBsYXRlIFNUT1BfU0VORElORyBzaG91bGQgZG8gbm8gaGFy bS4gTm8gcG9pbnQgaW4gbWFraW5nIGl0IGFuIGVycm9yDQogdG8gcmVjZWl2ZSBsYXRlIFNUT1Bf U0VORElORywmbmJzcDtvdGhlciB0aGFuIHRoZSBnZW5lcmFsIHJlY2VpdmUgc3RyZWFtIHJlbGF0 ZWQgcGFja2V0cyB2ZXJ5IGxhdGUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJibG9vcF9zaWduXzE1 MDE2MDU4NjQ4ODM3NjA4OTYiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxv biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEgQXVndXN0IDIwMTcgYXQgMTguMDkuMTksIElhbiBT d2V0dCAoPGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iPmlhbnN3ZXR0QGdvb2ds ZS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlIj5JIHRoaW5rIGl0J3MgZWFzaWVyIHRvIG1ha2UgU1RPUF9TRU5ESU5HIHJldHJhbnNtaXR0 YWJsZSBhbmQgdGhlbiBzdG9wIHNlbmRpbmcgaXQgb25jZSBhIFJTVF9TVFJFQU0gaXMgcmVjZWl2 ZWQgdGhhbiB0aGUgYWx0ZXJuYXRpdmVzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_BN6PR21MB0130745F30A3F6DDA6FA1E5187B30BN6PR21MB0130namp_-- From nobody Tue Aug 1 11:33:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A47132293 for ; Tue, 1 Aug 2017 11:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RbvV5iuvjFD for ; Tue, 1 Aug 2017 11:33:24 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4843E132250 for ; Tue, 1 Aug 2017 11:33:24 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d136so14179631qkg.3 for ; Tue, 01 Aug 2017 11:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HVtxDyNuU8NS6BXA9a/gs67PyDfviSHsGY02vYjhbiA=; b=PEUuXKcvHGGXV64B9kymT+YXkFkKxIwCb0c65zjq2oPnq+a2CX3v1aMQW/QX7uMALw XCapec8Z+rHgrENBayohR0QvoyQhr2FzJM9FNMVkv5RU7EIK4YdmcXNwMHsU83LhnkP1 HMAsQI1dEYJ7QOLdUg2I9XTnILWuXNys7qmNviSvszFcADjiWwcWeUhriUYSpFHF201m qYzr2+AK9d0XTYBhMrQXGRLMWbYFTc/JG5tCpZsw3iDQH/BTxlUf9RDzSC2w4tYLr7Y2 5AHz1IlbwWg8bGfUXy49oGc/7wvui7KHZSLPlktQ92bVKzazvku+2y6r+p9hAe8INgoK Cj4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HVtxDyNuU8NS6BXA9a/gs67PyDfviSHsGY02vYjhbiA=; b=IS2/aBbcbLZnzYQQCwMPLz5J0MOa8Y2W2gMXu9TmqclubFJVkGAYSN8/nHbMYpS4XV csXgDneyA75OoIGEc6T+XReIVBEPMcx3I/A68iO0D7ZfVgVn6mt7o8KYzhznF9Iw5G/p gMaHT3awD07czFzjPi9aq0bbk23aIZvbBHxatSw7XZc/Dz/X9RjwQJiReDT9EAXFduoD HGsvqnvPxBpNyy8CogBXvB6jANuVhpot+FbwtoaT8RYVElVuuTCBP3TfMBsb2gzulZom 83AxeDT6nqCfKYVdPtaPQgXTLjsf3bB3YfOCJxzLqPNGwhOrygInAurxqRb/22OXgzcx EVcg== X-Gm-Message-State: AIVw110ZmDSQIM6EkfLOWISetebHv6L+AbwBOHrBl5Xd7dLqlKZzul0k aOF8iI4B3AtDSQNp X-Received: by 10.55.5.132 with SMTP id 126mr7362669qkf.191.1501612403445; Tue, 01 Aug 2017 11:33:23 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id c21sm21589328qke.50.2017.08.01.11.33.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Aug 2017 11:33:23 -0700 (PDT) Date: Tue, 1 Aug 2017 14:33:21 -0400 From: Dmitri Tikhonov To: Ian Swett Cc: IETF QUIC WG Subject: Re: Differentiate between GQUIC and QUIC packets Message-ID: <20170801183320.GB3099@ubuntu-dmitri> References: <20170801032502.GA28788@ubuntu-dmitri> <20170801032805.GA29894@ubuntu-dmitri> <20170801125031.GA2742@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 18:33:26 -0000 On Tue, Aug 01, 2017 at 09:08:52AM -0400, Ian Swett wrote: > On Tue, Aug 1, 2017 at 8:50 AM, Dmitri Tikhonov > Speaking of clients: is it the plan for Chrome to support both GQUIC > > and IETF QUIC during the transition period? > > Chrome is in the process of migrating towards IETF QUIC, but there is a > plan to support at least two versions during the transition. Recent Chrome releases have not supported older versions: - Chrome 60 dropped support for Q035 in favor of Q037. - Chrome dev build 61.0.3163.25 only supports Q039: it does not use QUIC to connect to web sites that advertize Q035 or Q037. Looking at the Chrome code, it does not seem that there is a reason for it not to work with multiple versions: proto-quic server supports multiple versions at the same time. - Dmitri. From nobody Tue Aug 1 17:06:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C436129AAD for ; Tue, 1 Aug 2017 17:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Z2L5_cSuDnx for ; Tue, 1 Aug 2017 17:06:23 -0700 (PDT) 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 4B1CD1270B4 for ; Tue, 1 Aug 2017 17:06:23 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id j32so14421135iod.0 for ; Tue, 01 Aug 2017 17:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SA4lgy9JrQ4NcQr+afa0rx1l6ysU+T73TV3yWGUyewg=; b=M+twoEKIH8fXh89yPpN3IL1vj2NHJnl23AnSTVDbPwkS+0JrQYhkgVGLKtyaWo/7pF iqdTeaNoqxzbzmc5bcpu7GkX+EYQYUWIeynIVby9PJAN9ar+fvIDrkA2JG/GR+BIhpcM UvK2qCUw3ma9yDcHp10X6vuh0AZKx2Ic0ZiLQ9NqLQeoLqQzhkeBFN/IfdRay57SfZbk V5mr3bAcRPfoS7ofhTuTwwWnTOR6ljvW288+tBtqn8UjBruN5vrej2zy7h6JKwbrMT1F VozySyJaobpvlJbGi6Dd9AZhdPsXTKIY4+guqX5ibcJWb7lpnHePi3EkN4TQlekh8ReV 4sXA== 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=SA4lgy9JrQ4NcQr+afa0rx1l6ysU+T73TV3yWGUyewg=; b=Y2vVwNbNUVJL/HqHJWeJ9hvFgjemmP19qaldPuhvP2VramSyji//BypxDphbAT4mBb pRhpbHq0gWWSMwHq8htZNiAc8XAcAvJnXvCUf6EiQbC6aQSb8r9mAdDoT36B9ZT/67Oh IcSH65X9KEHknnqTuyWvIgNxoKyaiVORZJNw0hauhBI27TLzjQIjPGUuG0Mt9rzH1+Ba WkcAXZyY6X3g5dyIANg2UonWbNr35eDVejVbWxvezzrMtXgDpbAIz0O/TI81Yq5PQXni SDUHHsfIqVECLCGgHWB3vVx5FNVNB4PAZWEBa5g4j0gI7NDhGD3NDiqlSzFCmtIzyWwM HqaA== X-Gm-Message-State: AIVw111JgqFmCfcKnR4e1RYgCOw9GTcPJBCNLnBnRx8QaOTg1P69Rxn/ Zp7ZlbvwrOqsVGp9X+SkwT2lU2LYGg== X-Received: by 10.107.16.196 with SMTP id 65mr27175287ioq.297.1501632382678; Tue, 01 Aug 2017 17:06:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 1 Aug 2017 17:06:21 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 2 Aug 2017 10:06:22 +1000 Message-ID: Subject: Re: STOP_SENDING To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ian Swett , QUIC WG , Mike Bishop , Subodh Iyengar 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, 02 Aug 2017 00:06:24 -0000 On 2 August 2017 at 02:49, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I=E2=80=99m only half reading along atm., but I don=E2=80=99t think it is= good for the > retransmission logic to reach back into stream state if it can be avoided= , > or vice versa. This would be an optimization only. There is no harm in retransmitting STOP_SENDING until it is acknowledged, but stream end is a way to cut that off early. From nobody Tue Aug 1 23:24:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1082F128E00 for ; Tue, 1 Aug 2017 23:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImZthG14P6ub for ; Tue, 1 Aug 2017 23:24:06 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 02105124C27 for ; Tue, 1 Aug 2017 23:24:06 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id d29so16438523uai.2 for ; Tue, 01 Aug 2017 23:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=jLAklDcF0eQ9Q5n1EMgaPifgqbKyiTv0l1DAd69xgYw=; b=SH08XCvzOw1esmvHqsn/ueZxyiBWhHjh4w9r6CMWDFPqvtgX0BxXcfzrDRuaw4qrnq E53MJQvQpJCHtuSpPmv18ycO/Gn7jXtIZhGjkHksB0cCqxVI+1+Q0FkCNn74LAQmvGUt fjqzz0ZOCCR7AmMnuxnHQ8sbxU7S3k7at/dLY4PBfio//FSkS86Y3mc4/opW4Dl7ZfHv QCJQ24zk4PfUApmPugXT8+HZmpL1YYO0aiEXYsMZ9IMko7+y6UphMzJPDzWflcQHF7Tx cKfgudrnjxsuxthdWs2oPwSkMPYBVqfL2X3/pgDTNEFdYwGLnRfadhWJ4trR3RtLeBi0 o7vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=jLAklDcF0eQ9Q5n1EMgaPifgqbKyiTv0l1DAd69xgYw=; b=l9H1NrKuiOWYxQ0lzU3X4bucbFeJHu6hDvlmMYKVwyTKr7Tm76mdbG3RXqKTpuEt5d fwcEbJBTNTvogF5cqRTbnLh66w93u5jCj/1spPRoZfp/6cEKpcq3trUNN3XW+kKdYCsE j7KXC0AoDCzYMiQpFlmt7shFyUnFmtDI7LBGkSLGxRiw+/UwFtuU8sJCWuzSwlv4Ax9B 9SU+6LCXOYP6ASLKI/+lKR/9J8uHEHQHwaYU5bpSJG2PwU9pBmaHCc4BODUZbrWAzmAF NMWDdO2LlJw+VYRv90ydyoQYLqukObxJu12eRLo39h0DrqEyXOBjcfMwbCNHT/hs00kw ncQQ== X-Gm-Message-State: AIVw111loyRa+MSJ6RnY6FkOQCD4XxhilFlQlO3u3JVgprYD5SXIT/hA PThSRRK3ToQmzdu+l5I1vsZEvH6K9K7t X-Received: by 10.176.85.70 with SMTP id u6mr16300148uaa.114.1501655045048; Tue, 01 Aug 2017 23:24:05 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 2 Aug 2017 02:24:04 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 2 Aug 2017 02:24:04 -0400 Message-ID: Subject: Load balancer reconfig signalling To: QUIC WG Content-Type: multipart/alternative; boundary="f403045e38aa890f370555bf4fcc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 02 Aug 2017 06:24:07 -0000 --f403045e38aa890f370555bf4fcc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Have there been any considerations into how load balancers might signal a reconfiguration with respect to draining connections. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --f403045e38aa890f370555bf4fcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Have there been any considerations into how load = balancers might signal a reconfiguration with respect to draining connectio= ns.


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

--f403045e38aa890f370555bf4fcc-- From nobody Wed Aug 2 21:22:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173911321E0 for ; Wed, 2 Aug 2017 21:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=dJ0+Pez6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HdEfWTtr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpM_NkDk_L0z for ; Wed, 2 Aug 2017 21:22:33 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56AF5131473 for ; Wed, 2 Aug 2017 21:22:33 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BB43420907; Thu, 3 Aug 2017 00:22:32 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Thu, 03 Aug 2017 00:22:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=zDR7kvw5PFiw2gC8t6 nv8gf6FnNsJVuU/M/4Ues+K+g=; b=dJ0+Pez6spzksuOXkG2JOcvfwQlxruIBnI NZ26wjPE+sTZlkfgYCDKaDWaPO5aGFCtzKq8FW3HQ2nmO1jT7lzjhQaJOWrf+q5G UR7IXxnkPJtHumn3bIjDNk6ijuU3VBz9g8WNywkCPIn5DMsfFnBM5ezy7ieqPUKm 27BH7zwicWZuhcz1A//SWfBwgOCoBWDs8LytkGNiszbkdDJHjX8CF3ADOFTmU584 BOLErDF40RxcCau9YjLDJJnVI85AMfRKAn7+dl4TihAhjCFyqWbxrCAMwQNvhroV fHlcpICieTDOP+WM3JT5IdxkHPEvx0GjCCknMF7nmV+15XEEVFJQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=zDR7kvw5PFiw2gC8t6nv8gf6FnNsJVuU/M/4Ues+K+g=; b=HdEfWTtr BxxCg10gQlnUP6uFiZIwiYS68mQfTCQ7aqssnxqmNNrREb3mkFmPt/ppmcAyVwau o4OQBrjegeMJgq2ygOKRkBOjxmDnEzqyZXQ8b7+wiTZc4IJoew70HfqWkUShehpR cSXWP34WXJuSljdLorBS4TN9Y36oXSTiH9+2Lgr4MNMvGzGXfX2SSC/pYAkfHas/ b35NBmeREieBDx4yJYlSQO0iUoWkx3to9s3l9MQjBt1js2cxMsUz8h82B432WJkr SOdDQIqpjkdDEldOdmu8MXbc9RuXma4vhpjR2kbpKna0aN1op6KUCcstTdD4v7YM /3cM1jL4bbcAOg== X-ME-Sender: X-Sasl-enc: eiej1HKMvhpepRSn9Hfx34VT2imUqAnk+cNjlDg2JjvE 1501734152 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 567B77FA6E; Thu, 3 Aug 2017 00:22:31 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [E] DRAFT minutes rom IETF99 (Prague) From: Mark Nottingham In-Reply-To: Date: Thu, 3 Aug 2017 14:22:30 +1000 Cc: IETF QUIC WG , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <7C87236E-18EB-4C91-9100-63636E89C782@mnot.net> References: <067CF332-5289-40CD-9901-698446A6C212@mnot.net> To: "Mishra, Sanjay" 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, 03 Aug 2017 04:22:36 -0000 Fixed in source, thanks! > On 2 Aug 2017, at 1:18 am, Mishra, Sanjay = wrote: >=20 > The link to compatibility matrix from Hackathon is missing in the link = place holder in the meeting minutes. >=20 >=20 >> Patrick: Yep five. None had achieved interop of -05 before. Issues: = settling on ALPN/TLS versions. [link to compat matrix goes here] No = fundamental problems found. Editorial nits. A couple open to = consideration. What the WG meant to write down is what was = understood..." >=20 > -Sanjay >=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Friday, July 21, 2017 9:06 AM > To: IETF QUIC WG > Cc: Lars Eggert > Subject: [E] DRAFT minutes rom IETF99 (Prague) >=20 > ... are at: > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_quicwg_w= g-2Dmaterials_blob_master_ietf99_minutes.md&d=3DDwICAg&c=3DudBTRvFvXC5Dhqg= 7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D9a_L6t5TdnDThojv7KBKmqsZzTGM6YylS2wfbAO9K= K0&m=3Di_-VSjfoNUY0V_uv_GhIZE7MTtsXiKp1b1rlSCoKtAc&s=3DhH-iaYpI5J08iQXsdLJ= cCcLRWjqPEs8sZ1qkg9NUTkU&e=3D=20 >=20 > Corrections welcome as pull requests and in e-mail. >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.mnot.net_&d=3DD= wICAg&c=3DudBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=3D9a_L6t5TdnDThojv= 7KBKmqsZzTGM6YylS2wfbAO9KK0&m=3Di_-VSjfoNUY0V_uv_GhIZE7MTtsXiKp1b1rlSCoKtA= c&s=3DKKUy3k_M8WOBXS5Zwm37iofs0b5a2DYw_zMbe8Knb1U&e=3D=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Aug 3 10:49:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB901320C9 for ; Thu, 3 Aug 2017 10:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 Lq4imURgSsCG for ; Thu, 3 Aug 2017 10:49:32 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5591320C6 for ; Thu, 3 Aug 2017 10:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BekYDbXwWX2uvnG5y7yofmLtU1uvqihUEaggqZ2DhKA=; b=i0pGSrr/zGmXN+K7rYKLE5Xig8uE4zFPiJsPbHDo9pSIOxvbCBXdsp7nK70PSYgErMql09Jydhh1vO/g06ZxR5mVvMgGsg4R4XNwWjykuSDzZMQdKEQo64hPuotYOT41Ty7PSqdYWKp0vQQIg0A97XilgvFjUBxEPsb3bAR+2vw= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0173.namprd21.prod.outlook.com (10.173.52.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.0; Thu, 3 Aug 2017 17:49:30 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1341.000; Thu, 3 Aug 2017 17:49:30 +0000 From: Mike Bishop To: QUIC WG , "ietf-http-wg@w3.org" Subject: RE: Push ID - Merge Imminent Thread-Topic: Push ID - Merge Imminent Thread-Index: AdMMflQP7j6uNR+PS2KfJ40m2cnztgAAnzZA Date: Thu, 3 Aug 2017 17:49:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:e::6c2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0173; 6:8aLyrZijK+Fdsx7xoeqXF53VwwvTaOObLdoZZOM4qeFMHQAmGKsP/IyXRk7pRWPWuj5kHuPflLHi7ShXXRO94J4OrzRGeK+41jUHWnMMAFL+GdMvdfFOzqOwlKsQcoK7VnInpWYn6yXiqwuA3Vrkq495NMR71I5KBgr6dtnfmzgrT/KAFH8bcQqs9fDXZQzlb9aO5U25hhdXv7fxJnqf+nOtXEzDO6jfDamOIag2nJyBE5lGTFS6eQBpPA1t7z+pCgUgYTVRExj7Wh4SeBWlix2jnydhEx3qag0AfTPT7/99LgqGquH0FT73/pc1a8QdDgISxHbrr7strHI4WQ372w==; 5:xWKW3reZbQiaoi3/+jDu+gSeOG8hcYQGbDjXL7oT7WlTdbOx5Y4jAezKWF2gqfPsQU3fR+aV8fU8eYYgXmcSP3Ao9z8tkH5CER96KqbWIT9mTrNtEzwJBA89Oxrb1vPmhwB9SumDNzksGaCKSuPaPg==; 24:EDmAYWFyozNWFA/o6WgUwhDgRVoI67kH02y8DEdnonrFyNJ3iMKn9Y/PtSqKUzy4wfbTnxxG9Om9RX7s3ELnwqGcFOxK88wl618FdbbmUtA=; 7:+Jj5TY2z5y1PpWLYzf5xLg0LBwejlrl0ilqQDHtmJIek8FWtwgCKbVJAlmgRKDj0hc5S5ckJrI9/POhzXRBLNt8QBYzvKQkNbB1XYhLZtpXYDml1k5v2C7U0fBx3RWHiTMflXYYNLNP0VkyHWhAC+VaX7tqiZoDyjxK9yKHNO6zPWGLprrb/P0BNvJn/jjGkCAN5kWvyj+MNAcbaFj7zj3NCbsjQxdOTAtYdfDkHlig= x-ms-office365-filtering-correlation-id: 673d61fb-3b16-4d9d-01f7-08d4da97fe2e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603115)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0173; x-ms-traffictypediagnostic: MWHPR21MB0173: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0173; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0173; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39450400003)(39400400002)(39840400002)(39860400002)(39410400002)(47760400005)(189002)(199003)(377454003)(86612001)(189998001)(101416001)(38730400002)(8676002)(74316002)(53936002)(2501003)(81156014)(81166006)(5660300001)(53546010)(2900100001)(6306002)(54896002)(7696004)(236005)(76176999)(8936002)(86362001)(50986999)(54356999)(9686003)(6246003)(68736007)(102836003)(6116002)(790700001)(55016002)(99286003)(478600001)(2950100002)(97736004)(2906002)(3280700002)(8990500004)(3660700001)(7736002)(6436002)(10090500001)(77096006)(72206003)(10290500003)(2940100002)(33656002)(5005710100001)(6506006)(966005)(14454004)(105586002)(606006)(106356001)(229853002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0173; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141A20338482D46AB7F939F87B10MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 17:49:29.2927 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0173 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 17:49:35 -0000 --_000_MWHPR21MB0141A20338482D46AB7F939F87B10MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmFoLCBRVUlDIHRvby4gIPCfmIoNCg0KRnJvbTogTWlrZSBCaXNob3AgW21haWx0bzpNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tXQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzLCAyMDE3IDEw OjM2IEFNDQpUbzogaWV0Zi1odHRwLXdnQHczLm9yZw0KU3ViamVjdDogUHVzaCBJRCAtIE1lcmdl IEltbWluZW50DQoNClRoaXMgaXMgTWFydGlu4oCZcyBQdXNoIElEIFBSIHNwbGl0IG9mZiBmcm9t IHVuaWRpcmVjdGlvbmFsLiAgR2l2ZW4gdGhhdCBpdCBoYXMgYWxyZWFkeSBiZWVuIHBpY2tlZCBv dmVyIGluIHRob3NlIGNvbnRleHRzIGFuZCB0aGUgZmVlZGJhY2sgZnJvbSB0aGF0IGFuZCBpbi1w ZXJzb24gZGlzY3Vzc2lvbiB3YXMgdG8gYnJpbmcgdGhpcyBjaGFuZ2UgaW4gc2VwYXJhdGVseSwg SeKAmW0gYWJvdXQgcmVhZHkgdG8gbWVyZ2UgdGhpcy4gIEV2ZXJ5dGhpbmcgYW55b25lIGhhcyBx dWliYmxlZCB3aXRoIGhhcyBiZWVuIGVkaXRvcmlhbC4gIEhvd2V2ZXIsIEkgZG9u4oCZdCBzZWUg cmV2aWV3cyBmcm9tIG1hbnkgZm9sa3MsIHNvIEkgd2FudCB0byBtYWtlIHN1cmUgdGhhdCBldmVy eW9uZSBpbnRlcmVzdGVkIGhhcyBoYWQgYSBjaGFuY2UgdG8gZXhwcmVzcyBhbiBvcGluaW9uLg0K DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzAxPGh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJG Z2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjcwMSZkYXRhPTA0JTdD MDElN0NNaWNoYWVsLkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0M4YzY4YTc0MzQyOGM0M2ZkOWU5 NTA4ZDRkYTk2OTJhNyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzYzNzM3ODc2NzM0MzYzMzglN0NVbmtub3duJTdDVlc1cmJtOTNibng3SWxZaU9pSXdMakF1 TURBd01DSXNJbEFpT2lKWGFXNHpNaUlzSWtGT0lqb2lUM1JvWlhJaWZRJTNEJTNEJTdDLTEmc2Rh dGE9bEY1Q3I1RmUxUnVZNUJPdlBnaXk5aWFHcUhTMjclMkI3amVNMUlPaXBTeHU0JTNEJnJlc2Vy dmVkPTA+DQoNCknigJlsbCBnaXZlIGl0IGEgZmV3IGhvdXJzICh1bnRpbCBldmVyeW9uZeKAmXMg aGFkIGF0IGxlYXN0IGEgbGl0dGxlIGJpdCBvZiBhIHdvcmsgZGF5KSwgdGhlbiBtZXJnZSB1bmxl c3MgSSBoZWFyIG90aGVyd2lzZS4NCg== --_000_MWHPR21MB0141A20338482D46AB7F939F87B10MWHPR21MB0141namp_ 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 CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYWgsIFFVSUMgdG9vLiZuYnNw OyA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fu cy1zZXJpZiI+DQomIzEyODUyMjs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlrZSBCaXNob3AgW21h aWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBBdWd1c3QgMywgMjAxNyAxMDozNiBBTTxicj4NCjxiPlRvOjwvYj4gaWV0Zi1odHRw LXdnQHczLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBQdXNoIElEIC0gTWVyZ2UgSW1taW5lbnQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgTWFydGlu4oCZ cyBQdXNoIElEIFBSIHNwbGl0IG9mZiBmcm9tIHVuaWRpcmVjdGlvbmFsLiZuYnNwOyBHaXZlbiB0 aGF0IGl0IGhhcyBhbHJlYWR5IGJlZW4gcGlja2VkIG92ZXIgaW4gdGhvc2UgY29udGV4dHMgYW5k IHRoZSBmZWVkYmFjayBmcm9tIHRoYXQgYW5kIGluLXBlcnNvbiBkaXNjdXNzaW9uIHdhcyB0byBi cmluZyB0aGlzIGNoYW5nZSBpbiBzZXBhcmF0ZWx5LCBJ4oCZbSBhYm91dCByZWFkeSB0byBtZXJn ZQ0KIHRoaXMuJm5ic3A7IEV2ZXJ5dGhpbmcgYW55b25lIGhhcyBxdWliYmxlZCB3aXRoIGhhcyBi ZWVuIGVkaXRvcmlhbC4mbmJzcDsgSG93ZXZlciwgSSBkb27igJl0IHNlZSByZXZpZXdzIGZyb20g bWFueSBmb2xrcywgc28gSSB3YW50IHRvIG1ha2Ugc3VyZSB0aGF0IGV2ZXJ5b25lIGludGVyZXN0 ZWQgaGFzIGhhZCBhIGNoYW5jZSB0byBleHByZXNzIGFuIG9waW5pb24uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJh ZnRzJTJGcHVsbCUyRjcwMSZhbXA7ZGF0YT0wNCU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNy b3NvZnQuY29tJTdDOGM2OGE3NDM0MjhjNDNmZDllOTUwOGQ0ZGE5NjkyYTclN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2MzczNzg3NjczNDM2MzM4JTdDVW5r bm93biU3Q1ZXNXJibTkzYm54N0lsWWlPaUl3TGpBdU1EQXdNQ0lzSWxBaU9pSlhhVzR6TWlJc0lr Rk9Jam9pVDNSb1pYSWlmUSUzRCUzRCU3Qy0xJmFtcDtzZGF0YT1sRjVDcjVGZTFSdVk1Qk92UGdp eTlpYUdxSFMyNyUyQjdqZU0xSU9pcFN4dTQlM0QmYW1wO3Jlc2VydmVkPTAiPmh0dHBzOi8vZ2l0 aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC83MDE8L2E+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPknigJlsbCBnaXZlIGl0IGEgZmV3IGhvdXJzICh1bnRpbCBldmVyeW9uZeKAmXMgaGFk IGF0IGxlYXN0IGEgbGl0dGxlIGJpdCBvZiBhIHdvcmsgZGF5KSwgdGhlbiBtZXJnZSB1bmxlc3Mg SSBoZWFyIG90aGVyd2lzZS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_MWHPR21MB0141A20338482D46AB7F939F87B10MWHPR21MB0141namp_-- From nobody Thu Aug 3 11:31:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58FDE12711B for ; Thu, 3 Aug 2017 11:31:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqWR1Oh_TP3Z for ; Thu, 3 Aug 2017 11:31:15 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5681120721 for ; Thu, 3 Aug 2017 11:31:15 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u207so13719345ywc.3 for ; Thu, 03 Aug 2017 11:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=YiDiqon6iEqx32a3BPOL+QiXnvSZ47UeSQVEryt/4fc=; b=ZN795rX4CNqbzioBkyq1xBmrHoMUQ2X0g/kcQhaoxiRKASNPL9hBlSNzkyF7EJlJUv ew4UHazd4i5L2c9AUcoYnN4CN0ATdQp/fQ3r584mhf7OC9bBZ8k/m/iP17en4Ui9+C1y 1XKJV1tb39rkQ4T6g+8Frww6hdodvK+Lb6UPOyecMizEqYHNFsg7e2msi9OMNqPlZA3T 4wyXjBI+46VQzYnNXdPNZDw8Z/rQPgL2WHJRRBwEBsx32EPOeYNSL3absFm16VNdUaa/ tgW/W3yPESdw6lQzD2BC9nEqf3WCboauxTRH0Dvi1HnaUy/Yo0J7QEAvHdVkw5NIF7RP Eevw== 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=YiDiqon6iEqx32a3BPOL+QiXnvSZ47UeSQVEryt/4fc=; b=h0nC3oUbRKvgxKX3XCpKDscNTbG958wEhyNAvfPQgaBlkPE0FXsQz1tlPcizb+0KYa SQyvlbEFOYE6jkX7qySdSPxdvS76hPYuVN9/eZQJ4YTgmAhzEnsYlZhu0F3HFzO5C8n/ 90TDxz2gbqqD8F73BvzEj5X1INkkRxwZRW1vcpxk6WVlUpoTx4DT+17sRwPt0bvFZlaQ CFB9i3bRJXiB7w00t3oFwfBr0HcO6W4DUx3wsQLn6eoG1a5OSDbnjcNpw3XfmK9102hQ jW9FAqCPVcJ2dk7eYbEetFUU+ZV06V77fJ5Tasw8T+jqaO+T8jQJUl8fxK+1omGxiXgi F2cw== X-Gm-Message-State: AIVw111oG8HtL0GLLN1xPS+h73pqvMef+HmS6hW4EHBxSye0Ula1gHu1 BiY4dON+1Dp1KcDcMLmf84BdyWuiu2JnIntnBA== X-Received: by 10.13.217.65 with SMTP id b62mr1915657ywe.109.1501785074087; Thu, 03 Aug 2017 11:31:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.171.9 with HTTP; Thu, 3 Aug 2017 11:30:53 -0700 (PDT) In-Reply-To: <150178483712.6999.8276857876164813379.idtracker@ietfa.amsl.com> References: <150178483712.6999.8276857876164813379.idtracker@ietfa.amsl.com> From: "Charles 'Buck' Krasic" Date: Thu, 3 Aug 2017 11:30:53 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-krasic-quic-qcram-02.txt To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114fd40adf45c10555dd9586" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Aug 2017 18:31:17 -0000 --001a114fd40adf45c10555dd9586 Content-Type: text/plain; charset="UTF-8" Hi all. I have uploaded a new revision of the QCRAM draft. Highlights of 01->02: - more concise: lines of text down ~ 30%. - simplifications: - flexibility to trade-off between compression ratio and HoL blocking resilience. - handling stream reset, dropped QPACK style split between updates and encoded headers. - new eviction scheme, avoids eviction races and icky resets. - mostly eliminated coordinated packetization (just a note in performance section now). ---------- Forwarded message ---------- From: Date: Thu, Aug 3, 2017 at 11:27 AM Subject: New Version Notification for draft-krasic-quic-qcram-02.txt To: Charles 'Buck' Krasic A new version of I-D, draft-krasic-quic-qcram-02.txt has been successfully submitted by Charles 'Buck' Krasic and posted to the IETF repository. Name: draft-krasic-quic-qcram Revision: 02 Title: Header Compression for HTTP over QUIC Document date: 2017-08-03 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-krasic-quic- qcram-02.txt Status: https://datatracker.ietf.org/doc/draft-krasic-quic-qcram/ Htmlized: https://tools.ietf.org/html/draft-krasic-quic-qcram-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-krasic-quic- qcram-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-krasic-quic-qcram-02 Abstract: The design of the core QUIC transport and the mapping of HTTP semantics over it subsume many HTTP/2 features, prominent among them stream multiplexing and HTTP header compression. A key advantage of the QUIC transport is it provides stream multiplexing free of HoL blocking between streams, while in HTTP/2 multiplexed streams can suffer HoL blocking primarily due to HTTP/2's layering above TCP. However if HPACK is used for header compression, HTTP over QUIC is still vulnerable to HoL blocking, because of how HPACK exploits header redundancies between multiplexed HTTP transactions. This draft defines QCRAM, a variation of HPACK and mechanisms in the QUIC HTTP mapping that allow QUIC implementations the flexibility to avoid header-compression induced HoL blocking. 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 -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114fd40adf45c10555dd9586 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all.=C2=A0 I have uploa= ded a new revision of the QCRAM draft.

Highlights = of 01->02:
  • more concise:=C2=A0 lines of text down ~ 30= %.
  • simplifications:
    • flexibility to trade-off be= tween compression ratio and HoL blocking resilience.
    • handling strea= m reset, dropped QPACK style split between updates and encoded headers.
    • new eviction scheme, avoids eviction races and icky resets.
    • mo= stly eliminated coordinated packetization (just a note in performance secti= on now).
---------- Forwarde= d message ----------
From: <internet-drafts@ie= tf.org>
Date: Thu, Aug 3, 2017 at 11:27 AM
Subject: New= Version Notification for draft-krasic-quic-qcram-02.txt
To: Charles = 9;Buck' Krasic <ckrasic@google= .com>



A new version of I-D, draft-krasic-quic-qcram-02.txt
has been successfully submitted by Charles 'Buck' Krasic and posted= to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-krasic-quic-qcram
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Header Compression for HTTP over Q= UIC
Document date:=C2=A0 2017-08-03
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 8
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-krasic-quic-qcram-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ht= tps://datatracker.ietf.org/doc/draft-krasic-quic-qcram/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://to= ols.ietf.org/html/draft-krasic-quic-qcram-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-krasic-quic-qcram-02<= /a>
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-krasic-quic-qcram-02

Abstract:
=C2=A0 =C2=A0The design of the core QUIC transport and the mapping of HTTP<= br> =C2=A0 =C2=A0semantics over it subsume many HTTP/2 features, prominent amon= g them
=C2=A0 =C2=A0stream multiplexing and HTTP header compression.=C2=A0 A key a= dvantage of
=C2=A0 =C2=A0the QUIC transport is it provides stream multiplexing free of = HoL
=C2=A0 =C2=A0blocking between streams, while in HTTP/2 multiplexed streams = can
=C2=A0 =C2=A0suffer HoL blocking primarily due to HTTP/2's layering abo= ve TCP.
=C2=A0 =C2=A0However if HPACK is used for header compression, HTTP over QUI= C is
=C2=A0 =C2=A0still vulnerable to HoL blocking, because of how HPACK exploit= s
=C2=A0 =C2=A0header redundancies between multiplexed HTTP transactions.=C2= =A0 This
=C2=A0 =C2=A0draft defines QCRAM, a variation of HPACK and mechanisms in th= e QUIC
=C2=A0 =C2=A0HTTP mapping that allow QUIC implementations the flexibility t= o avoid
=C2=A0 =C2=A0header-compression induced HoL blocking.




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




--
Charles &#= 39;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckras= ic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a114fd40adf45c10555dd9586-- From nobody Thu Aug 3 14:28:49 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BFA81241F5 for ; Thu, 3 Aug 2017 14:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOF9j-O2Ccxg for ; Thu, 3 Aug 2017 14:28:47 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FA4112741D for ; Thu, 3 Aug 2017 14:28:47 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id a18so15351305qta.0 for ; Thu, 03 Aug 2017 14:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=a2Kh2lNMgrABrPyYHTlFk7mM9K3jDjVI9+ht4cgjXYQ=; b=PcvnHOE1Du1HqB83XDDcV4mVGjhvrxqgYIi+Tk9j/nQVqGKyWuj3s9e+Uew7o5hADT Y8+5feBkO6WF34U9rcdDki13LErfmQwhaQiaQw+kAky6R++jiXxVuItEOiOkB/BjTieJ kMnjhh4KTJxIRcqGFJV00OYOOy8nHH4PL/mZr0JEPjQn+ZuhVyF/YwjT9pUdd7WhJOIM O6ptaPVFQLrD2Wy6yEbGn8zVD3XT74Qx+Q1Ue1DpZEW8qi4mUWuZMItVxXFgc+lPe9fy uvH35Q4ZMeMYfvVNjQvLAEwLWIKjz5TM5dM9jSzVHq4C1EO5azReemY0hn7JXcMyhbHq V/XA== 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=a2Kh2lNMgrABrPyYHTlFk7mM9K3jDjVI9+ht4cgjXYQ=; b=H6eRnO5QOsUI1DGyRBf4bLbxNgEsAutkPTVg9kKbEpiznnfHzBGov6YXuPgLwkyO5X YcgZRWW0x4KZtHCbt7Qlr2amiRWEXB/Ski/ueAH0l/1CKfol8bUGsqN3vi+wCAgbmFOw z4Rnickci5GhMtUtks47MHv/OdzMZcL6zTYT2cjo8qdBAin5JUKaIMs7Ag+xz+XShWxl OQZvce8KXPXup0U22Mg3GJVJVmtz9k1K/INksp0X9o/l258/jDN3/eM0u3nXJ9Qp87de oWH6ISvsq1RJRcYVzYUB5COesI41DKyJcGd7ktCmBzmzHvmGuCwcc42nRdPH+9zHUdpu VRhA== X-Gm-Message-State: AHYfb5i5RflJxwNGbpeTRcNoYkDDNqF3bUTBG06umHcrqX8LuGHda4zA BavdkL2b22O2uObtUHgJCyB/6FKuCA== X-Received: by 10.200.40.197 with SMTP id j5mr330853qtj.100.1501795726063; Thu, 03 Aug 2017 14:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.59.248 with HTTP; Thu, 3 Aug 2017 14:28:15 -0700 (PDT) In-Reply-To: References: From: Ted Hardie Date: Thu, 3 Aug 2017 14:28:15 -0700 Message-ID: Subject: Re: Design team membership for RTT measurement issue To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114069a4c706110555e01091" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 03 Aug 2017 21:28:48 -0000 --001a114069a4c706110555e01091 Content-Type: text/plain; charset="UTF-8" Look, bonus apologies! I missed Brian Trammell's name on the list despite him being among the first volunteer, based on a misunderstanding of some mail he'd sent to me. He has been added now. Ted On Mon, Jul 31, 2017 at 1:24 PM, Ted Hardie wrote: > My apologies for the delay in putting this out. > > Christian Huitema > Eric Rescorla > Al Morton > Christopher Wood > Marcus Ihlar > Daniel Kahn Gillmor > Andrew Mcgregor > Emile Stephan > Ted Hardie > > regards, > > Ted > > --001a114069a4c706110555e01091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Look, bonus apologies!

I missed Bri= an Trammell's name on the list despite him being among the first volunt= eer, based on a misunderstanding of some mail he'd sent to me.=C2=A0 He= has been added now.

Ted
<= br>
On Mon, Jul 31, 2017 at 1:24 PM, Ted Hardie <= span dir=3D"ltr"><ted.ietf@gmail.com> wrote:
M= y apologies for the delay in putting this out.

Christian Huite= ma
Eric Rescorla
Al Morton
Christopher Wood
<= /div>Marcus Ihlar
Daniel Kahn Gillmor
Andrew Mcgregor
=
Emile Stephan
Ted Hardie

regards,

= Ted


--001a114069a4c706110555e01091-- From nobody Thu Aug 3 17:32:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 706CD132017 for ; Thu, 3 Aug 2017 17:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnAHsBry-6zI for ; Thu, 3 Aug 2017 17:32:00 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC4A129AE7 for ; Thu, 3 Aug 2017 17:32:00 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id y129so1103675pgy.4 for ; Thu, 03 Aug 2017 17:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3XahR8kn9e/+DFfZr76rr14qdbDn5D0qW71j9nU8d3E=; b=tT0G7yiUE9YdW8ig/lYzBb6WjBLGJvsxoIbI0LlY3hmUY2CrHI7T0zVfanhAjzSJdQ r1hI5VjAx9qq9QhrDJU5NT5L9Pqa/39tCpFmWZKegq59osmzOw0bl2bfD6LCfmUqQaJ1 BJ6sWZRNMHjy4Pj8gvGfcUZet2SUiuS+D938XWPZuWSPO28lywxH9rnDp0mkHP3Ydzyu QlxywDZDlhmmnFiVlRUq69gPA8lKz7cXSyWYi9nAVGI6TUjKeF9C/OZdfETfkJemA49a 6KghsqUsjZQkrnOaEHzwsm8Zgya9L4lioNXT0CVpEbzBTuoAd5ytuQf+uYtH28NqMzHx NQGQ== 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=3XahR8kn9e/+DFfZr76rr14qdbDn5D0qW71j9nU8d3E=; b=eQoH+yWPsVbkipCRRfZLWteJ2kAT84WlkSd578Vt5p3kRb4mTQAwb7m0UH0qXgUiht LyZZIsw7kLtNaip7/DEji+yYUecixoZ9FGbTxtqgNn7QrgpjfHtcBDZZuuT2k83HcW+0 wbX1fg9y7DzGsD4yamY1yb7t5Af793jEc80X/IyuAUigWYsN2+pG1GufVokO5US8jQmK ediwZayOD4kRX+XGt+SQ9akLNRaHOfZyWRJZO+oHwoxn72Lw2pWjHEpFwUJhnPcFASRO W+Fhm77MifmND86+5Y9wPua8JsqqsaAxiz0IFfGTK2EvyDRazfWKiM69d8SHSDVLQYet SqKQ== X-Gm-Message-State: AIVw113dsht5hKGonz18Au8DtuWtgyGvAes6tDIPI4OVZXfKLwJveAA0 vF3wYIU+Dw/BfoLymVfEOkYQ1FJvyGCyze0= X-Received: by 10.98.201.202 with SMTP id l71mr544097pfk.223.1501806719334; Thu, 03 Aug 2017 17:31:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Thu, 3 Aug 2017 17:31:58 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 4 Aug 2017 00:31:58 +0000 Message-ID: Subject: Re: Push ID - Merge Imminent To: Mike Bishop Cc: QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="94eb2c18a15e0773730555e2a0b6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Aug 2017 00:32:02 -0000 --94eb2c18a15e0773730555e2a0b6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think the high-order idea is great, and I'm totally in favor. I've raised several editorial issues, but there's one substantitive one that may be worth discussing here. PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the server. The text currently says that CANCEL_PUSH on a non-existent Push ID results in error, which does not work with the possibility of reordering between PUSH_PROMISE and CANCEL_PUSH. Similarly, it's also possible for the PUSH_PROMISE to not have been received because the stream on which it was sent was reset... basically it's possible for a client to receive a CANCEL_PUSH without seeing the corresponding PUSH_PROMISE. We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE, but that doesn't help with the case where the PUSH_PROMISE may not have been received due to a stream reset. This makes me wonder if it makes sense to always send the PUSH_PROMISE on the control stream *in addition to* any stream that it is sent on. This would ensure that no matter what, the PUSH_PROMISE is always received, and additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE. - jana On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop wrote: > Bah, QUIC too. =F0=9F=98=8A > > > > *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] > *Sent:* Thursday, August 3, 2017 10:36 AM > *To:* ietf-http-wg@w3.org > *Subject:* Push ID - Merge Imminent > > > > This is Martin=E2=80=99s Push ID PR split off from unidirectional. Given= that it > has already been picked over in those contexts and the feedback from that > and in-person discussion was to bring this change in separately, I=E2=80= =99m about > ready to merge this. Everything anyone has quibbled with has been > editorial. However, I don=E2=80=99t see reviews from many folks, so I wa= nt to make > sure that everyone interested has had a chance to express an opinion. > > > > https://github.com/quicwg/base-drafts/pull/701 > > > > > I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at least a= little bit of a > work day), then merge unless I hear otherwise. > --94eb2c18a15e0773730555e2a0b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think the high-order idea is great, and I'm totally = in favor. I've raised several editorial issues, but there's one sub= stantitive one that may be worth discussing here.

PUSH_P= ROMISE is sent by the server, and CANCEL_PUSH may be sent by the server. Th= e text currently says that CANCEL_PUSH on a non-existent Push ID results in= error, which does not work with the possibility of reordering between PUSH= _PROMISE and CANCEL_PUSH. Similarly, it's also possible for the PUSH_PR= OMISE to not have been received because the stream on which it was sent was= reset... basically it's possible for a client to receive a CANCEL_PUSH= without seeing the corresponding PUSH_PROMISE.

We= could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE, bu= t that doesn't help with the case where the PUSH_PROMISE may not have b= een received due to a stream reset.

This makes me = wonder if it makes sense to always send the PUSH_PROMISE on the control str= eam *in addition to* any stream that it is sent on. This would ensure that = no matter what, the PUSH_PROMISE is always received, and additionally ensur= es that CANCEL_PUSH is received after a PUSH_PROMISE.

<= div>- jana

On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.


--94eb2c18a15e0773730555e2a0b6-- From nobody Thu Aug 3 18:36:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20A7132040 for ; Thu, 3 Aug 2017 18:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 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, HTTPS_HTTP_MISMATCH=1.989, 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 wKXhISUtcpMb for ; Thu, 3 Aug 2017 18:36:11 -0700 (PDT) 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 F264B131532 for ; Thu, 3 Aug 2017 18:36:10 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so1133617ioe.5 for ; Thu, 03 Aug 2017 18:36:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T4eQd11rugvFp5JNczhoP07QTURUwl9WnYjyr5mCQv4=; b=cdETBcc0QEjFN3ds/PgcRaPlyUsqdAG7i9u6L7rYHSt/XQ4WushbBfZky36ke6OLGW RtAQUG4Ybi8mmsaLy+MqImxCmC91HLS5EIothHCenmbVSo1hvOs0mIsPCUFtcPUAgu4I 1dexKQxV84TJqmKQ8QbAm78kKvk44wG0NMqKGtWAmQ8UxRT5w+Qbv0zkVELaOTNNNBTX 5rLizBfknoXnepdzPmuMRGt440ImtND67b3pQ66RXFKVdxsXk95d6tZbNJXZZ5aWrdlX Hx0Pl68xbJlLPdsghgdE8USN/4WMEi5eEAkvS3Sm/hXuqB9F9Q0jRhEKRSn0xp3h9Doe fnTg== 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=T4eQd11rugvFp5JNczhoP07QTURUwl9WnYjyr5mCQv4=; b=Srq0HBKe5MI6z5ws+LRHQR8VZI7t79cAFfQAIb/JY3Mv1gAQii8gCKaKwj4vovUZG/ ZbydLaL7kWkiIU/YMff/l9y32h3kgQpEYUqcWmzLpQstJH5LrXfqVosh0LP3gtZAcmh5 VpcmvYkzfjydshI27uZwhr9NcJdjfxTOIo6xvRkd1OKn/xSBZvgDmFxCh8TMkbJd0ZLb 9i5m85rlpJBGKI5T48THdjDskdRs1uXnZ3Yxmt7ipBHFYXi0/l3oE7GzYT8cwXrMsQab 6DIsv3uaKdPxP2CMHC2c4trWKj6NqI9Bp7ojRG7Op4LHi5ZgV7BMRFJMScLnxPTtLOY1 2njA== X-Gm-Message-State: AHYfb5giif0Iotd7A2QKbalPS9rrTmJbqpFIl9CCu9Ykd/Obd+ZiM83+ i2wxZiLGqzwZSXmW2eUWZaOF1g0YzA== X-Received: by 10.107.16.196 with SMTP id 65mr900891ioq.297.1501810570358; Thu, 03 Aug 2017 18:36:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 3 Aug 2017 18:36:09 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 4 Aug 2017 11:36:09 +1000 Message-ID: Subject: Re: Push ID - Merge Imminent To: Jana Iyengar Cc: Mike Bishop , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="001a113ee43a90f8050555e3853b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Aug 2017 01:36:13 -0000 --001a113ee43a90f8050555e3853b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 4 August 2017 at 10:31, Jana Iyengar wrote: > I think the high-order idea is great, and I'm totally in favor. I've > raised several editorial issues, but there's one substantitive one that m= ay > be worth discussing here. > > PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the > server. The text currently says that CANCEL_PUSH on a non-existent Push I= D > results in error, which does not work with the possibility of reordering > between PUSH_PROMISE and CANCEL_PUSH. > That's just a bug. > Similarly, it's also possible for the PUSH_PROMISE to not have been > received because the stream on which it was sent was reset... basically > it's possible for a client to receive a CANCEL_PUSH without seeing the > corresponding PUSH_PROMISE. > This is more interesting. It creates state on the client: it says that clients are required to ignore pushes that it *might* receive in the future. That suggests a different fix, akin to what we use for other similar pieces of state: 1. make Push ID sequential (right now the only requirement is for connection-wide uniqueness) 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new frame type; the setting might {ab|re}use ENABLE_PUSH) This would bound state for clients. A client couldn't receive an arbitrary number of CANCEL_PUSH messages that are distributed over the 32-bit Push ID space, so tracking cancellations is easy. Clients could use a simple bitvector to track which pushes are potentially interesting, clearing bits as pushes or cancellations arrive. MAX_PUSH_ID would give clients a finer-grained lever to control push. We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE, > but that doesn't help with the case where the PUSH_PROMISE may not have > been received due to a stream reset. > > This makes me wonder if it makes sense to always send the PUSH_PROMISE on > the control stream *in addition to* any stream that it is sent on. This > would ensure that no matter what, the PUSH_PROMISE is always received, an= d > additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE. > I don't think that is a good idea. PUSH_PROMISE includes a headers block, which is pretty big, even with effective compression. HoLB won't affect this stream, so size shouldn't be an issue, but still. I did consider moving the header block to the control stream completely as part of addressing the issue with duplication that I mentioned earlier. The basic problem there is that you don't guarantee that the client see the PUSH_PROMISE before it processes the response content. > > - jana > > On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop > wrote: > >> Bah, QUIC too. =F0=9F=98=8A >> >> >> >> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] >> *Sent:* Thursday, August 3, 2017 10:36 AM >> *To:* ietf-http-wg@w3.org >> *Subject:* Push ID - Merge Imminent >> >> >> >> This is Martin=E2=80=99s Push ID PR split off from unidirectional. Give= n that it >> has already been picked over in those contexts and the feedback from tha= t >> and in-person discussion was to bring this change in separately, I=E2=80= =99m about >> ready to merge this. Everything anyone has quibbled with has been >> editorial. However, I don=E2=80=99t see reviews from many folks, so I w= ant to make >> sure that everyone interested has had a chance to express an opinion. >> >> >> >> https://github.com/quicwg/base-drafts/pull/701 >> >> >> >> >> I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at least = a little bit of a >> work day), then merge unless I hear otherwise. >> > > --001a113ee43a90f8050555e3853b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 4 August 2017 at 10:31, Jana Iyengar <jri@google.com> = wrote:
I think the high-= order idea is great, and I'm totally in favor. I've raised several = editorial issues, but there's one substantitive one that may be worth d= iscussing here.

PUSH_PROMISE is sent by the server, and = CANCEL_PUSH may be sent by the server. The text currently says that CANCEL_= PUSH on a non-existent Push ID results in error, which does not work with t= he possibility of reordering between PUSH_PROMISE and CANCEL_PUSH.

That's just a bug.
= =C2=A0
Similarly,= it's also possible for the PUSH_PROMISE to not have been received beca= use the stream on which it was sent was reset... basically it's possibl= e for a client to receive a CANCEL_PUSH without seeing the corresponding PU= SH_PROMISE.

This is more intere= sting.=C2=A0 It creates state on the client:=C2=A0 it says that clients are= required to ignore pushes that it *might* receive in the future.=C2=A0 Tha= t suggests a different fix, akin to what we use for other similar pieces of= state:

1. make Push ID sequential (right now the = only requirement is for connection-wide uniqueness)

2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new f= rame type; the setting might {ab|re}use ENABLE_PUSH)

Th= is would bound state for clients.=C2=A0 A client couldn't receive an ar= bitrary number of CANCEL_PUSH messages that are distributed over the 32-bit= Push ID space, so tracking cancellations is easy.=C2=A0 Clients could use = a simple bitvector to track which pushes are potentially interesting, clear= ing bits as pushes or cancellations arrive.

MAX_PUSH_ID would give clients a fine= r-grained lever to control push.

<= /div>
We could have CANCEL_PUSH be sent on the same streams as the PUSH= _PROMISE, but that doesn't help with the case where the PUSH_PROMISE ma= y not have been received due to a stream reset.

Th= is makes me wonder if it makes sense to always send the PUSH_PROMISE on the= control stream *in addition to* any stream that it is sent on. This would = ensure that no matter what, the PUSH_PROMISE is always received, and additi= onally ensures that CANCEL_PUSH is received after a PUSH_PROMISE.

I don't think that is a good idea.= =C2=A0 PUSH_PROMISE includes a headers block, which is pretty big, even wit= h effective compression.=C2=A0 HoLB won't affect this stream, so size s= houldn't be an issue, but still.

I did con= sider moving the header block to the control stream completely as part of a= ddressing the issue with duplication that I mentioned earlier.=C2=A0 The ba= sic problem there is that you don't guarantee that the client see the P= USH_PROMISE before it processes the response content.
=C2=A0<= /div>

- jana

On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.



--001a113ee43a90f8050555e3853b-- From nobody Fri Aug 4 00:01:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09A112EA7C for ; Fri, 4 Aug 2017 00:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DNyFJJfdO2KP for ; Fri, 4 Aug 2017 00:01:07 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AA31294A2 for ; Fri, 4 Aug 2017 00:01:07 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id y129so4479262pgy.4 for ; Fri, 04 Aug 2017 00:01:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tzIUH7s3G5CVavXlBKQ8+XfU1LMo20zVAV0rrqzS9Jg=; b=hhieQ0xyzlGinVZUmgygqlR/binVVdq7TjTVmVbRTkugOokzqFSwvG3/3RNnL5IJh2 2mBUjeOnltx8DR+6DFcSab/0B6u9oSoO4O1d0A+1eSx8hBL2+jFjPQWmkZdhDPTVXGGX Ee5Mzi/VLuqxTOLwOEsBsR/0H9c53GxVMmhCjeEDVPwfNFw/WDx0F5++eVf9Qn1Ynlu8 n3qyaLhbLtcgQlw/WpG54BdDfubJKv7ZuiEaHS09SfABQNaDb5W4RbZ+Fj3/0dKv36xO oWSt3Aifb/9NgrsPxbPpvyCqa2aW3/yZ/szoBVwwdSQTrg+NS90XU7T2+O7BHiSqLLdk iAYg== 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=tzIUH7s3G5CVavXlBKQ8+XfU1LMo20zVAV0rrqzS9Jg=; b=TjGB6L+kAOv8FrZZWEGXFKuoeORjnEuVMLXlVNYBnSN2LxX8D0QohgFn1smJAaId1x Q/MBiOwSkOd+W5Cgk2NwfzRAwN4ZxeOk6nwLDiUW/Va4gKO5khUeePvFq21eA6EFY9Ij SiKMEEaHLChlUbtbLTwLufzl3FPngrhB3FJkdYQsIbgCPglO10ghTDcHlpm8uDVsDkTK Xtff110ymxY3tBD1GUheXSow22r1gi6+QEo+x/+25D8C9dfsAXGqdbGygdfMdvlQq8+z bDGng3YXKe1AeYjqhOcUMfxf7Eerx9b+2ElcsuNfjL3lsF6uViuZ7yDFOVIpXttMseOX 7Zpw== X-Gm-Message-State: AIVw110kD5JESRMiC5F8jCI6a0WDgTSUrP6Ejrt4OulfArS3z/jtVR/T kf723EszPQ02vrd9KplBdwtC/iMmmw== X-Received: by 10.84.231.140 with SMTP id g12mr1637243plk.256.1501830066954; Fri, 04 Aug 2017 00:01:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.178.235 with HTTP; Fri, 4 Aug 2017 00:01:06 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Fri, 4 Aug 2017 16:01:06 +0900 Message-ID: Subject: Re: Push ID - Merge Imminent To: Martin Thomson Cc: Jana Iyengar , Mike Bishop , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="f403045ff686a769dd0555e80fae" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Aug 2017 07:01:10 -0000 --f403045ff686a769dd0555e80fae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2017-08-04 10:36 GMT+09:00 Martin Thomson : > > > On 4 August 2017 at 10:31, Jana Iyengar wrote: > >> I think the high-order idea is great, and I'm totally in favor. I've >> raised several editorial issues, but there's one substantitive one that = may >> be worth discussing here. >> >> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >> server. The text currently says that CANCEL_PUSH on a non-existent Push = ID >> results in error, which does not work with the possibility of reordering >> between PUSH_PROMISE and CANCEL_PUSH. >> > > That's just a bug. > > >> Similarly, it's also possible for the PUSH_PROMISE to not have been >> received because the stream on which it was sent was reset... basically >> it's possible for a client to receive a CANCEL_PUSH without seeing the >> corresponding PUSH_PROMISE. >> > > This is more interesting. It creates state on the client: it says that > clients are required to ignore pushes that it *might* receive in the > future. That suggests a different fix, akin to what we use for other > similar pieces of state: > > 1. make Push ID sequential (right now the only requirement is for > connection-wide uniqueness) > I think that using a sequential ID will be a good idea not only for fixing this issue but that it might be possible to use the sequentiality to fix the first issue raised in the PR (i.e. client knowing "when the server will stop referencing a push ID in PUSH_PROMISE"). If there is a sequential ordering guarantee for Push ID, a client can, by looking at the Push ID, determine whether if it has already consumed the pushed request. If it has, it will immediately lookup its cache, and in case it fails to find a cached object, then issue a pull. If it has not consumed the pushed request, it should wait for the pushed response to arrive. > > 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new > frame type; the setting might {ab|re}use ENABLE_PUSH) > > This would bound state for clients. A client couldn't receive an > arbitrary number of CANCEL_PUSH messages that are distributed over the > 32-bit Push ID space, so tracking cancellations is easy. Clients could u= se > a simple bitvector to track which pushes are potentially interesting, > clearing bits as pushes or cancellations arrive. > > MAX_PUSH_ID would give clients a finer-grained lever to control push. > > We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE= , >> but that doesn't help with the case where the PUSH_PROMISE may not have >> been received due to a stream reset. >> >> This makes me wonder if it makes sense to always send the PUSH_PROMISE o= n >> the control stream *in addition to* any stream that it is sent on. This >> would ensure that no matter what, the PUSH_PROMISE is always received, a= nd >> additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE. >> > > I don't think that is a good idea. PUSH_PROMISE includes a headers block= , > which is pretty big, even with effective compression. HoLB won't affect > this stream, so size shouldn't be an issue, but still. > > I did consider moving the header block to the control stream completely a= s > part of addressing the issue with duplication that I mentioned earlier. > The basic problem there is that you don't guarantee that the client see t= he > PUSH_PROMISE before it processes the response content. > > >> >> - jana >> >> On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop > > wrote: >> >>> Bah, QUIC too. =F0=9F=98=8A >>> >>> >>> >>> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] >>> *Sent:* Thursday, August 3, 2017 10:36 AM >>> *To:* ietf-http-wg@w3.org >>> *Subject:* Push ID - Merge Imminent >>> >>> >>> >>> This is Martin=E2=80=99s Push ID PR split off from unidirectional. Giv= en that >>> it has already been picked over in those contexts and the feedback from >>> that and in-person discussion was to bring this change in separately, I= =E2=80=99m >>> about ready to merge this. Everything anyone has quibbled with has bee= n >>> editorial. However, I don=E2=80=99t see reviews from many folks, so I = want to make >>> sure that everyone interested has had a chance to express an opinion. >>> >>> >>> >>> https://github.com/quicwg/base-drafts/pull/701 >>> >>> >>> >>> >>> I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at least= a little bit of >>> a work day), then merge unless I hear otherwise. >>> >> >> > --=20 Kazuho Oku --f403045ff686a769dd0555e80fae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017-08-04 10:36 GMT+09:00 Martin Thomson <martin.thomson@gmail= .com>:
<= div dir=3D"ltr">

On 4 August 2017 at 10:31, Jana Iyengar <jri@google= .com> wrote:
I think the high-order idea is great, and I'm tot= ally in favor. I've raised several editorial issues, but there's on= e substantitive one that may be worth discussing here.

P= USH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the serve= r. The text currently says that CANCEL_PUSH on a non-existent Push ID resul= ts in error, which does not work with the possibility of reordering between= PUSH_PROMISE and CANCEL_PUSH.

That's just a bug.
=C2=A0<= /div>
Similarly, it's also possible for the PUSH_PROMISE to not have been r= eceived because the stream on which it was sent was reset... basically it&#= 39;s possible for a client to receive a CANCEL_PUSH without seeing the corr= esponding PUSH_PROMISE.

= This is more interesting.=C2=A0 It creates state on the client:=C2=A0 it sa= ys that clients are required to ignore pushes that it *might* receive in th= e future.=C2=A0 That suggests a different fix, akin to what we use for othe= r similar pieces of state:

1. make Push ID sequent= ial (right now the only requirement is for connection-wide uniqueness)

I think that using a se= quential ID will be a good idea not only for fixing this issue but that it = might be possible to use the sequentiality to fix the first issue raised in= the PR (i.e. client knowing "when the server will stop referencing a = push ID in PUSH_PROMISE").

If there is a sequ= ential ordering guarantee for Push ID, a client can, by looking at the Push= ID, determine whether if it has already consumed the pushed request. If it= has, it will immediately lookup its cache, and in case it fails to find a = cached object, then issue a pull. If it has not consumed the pushed request= , it should wait for the pushed response to arrive.

=C2=A0

2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with = a new frame type; the setting might {ab|re}use ENABLE_PUSH)

<= /div>This would bound state for clients.=C2=A0 A client couldn't receiv= e an arbitrary number of CANCEL_PUSH messages that are distributed over the= 32-bit Push ID space, so tracking cancellations is easy.=C2=A0 Clients cou= ld use a simple bitvector to track which pushes are potentially interesting= , clearing bits as pushes or cancellations arrive.

MAX_PUSH_ID would give clients= a finer-grained lever to control push.

We could have CA= NCEL_PUSH be sent on the same streams as the PUSH_PROMISE, but that doesn&#= 39;t help with the case where the PUSH_PROMISE may not have been received d= ue to a stream reset.

This makes me wonder if it m= akes sense to always send the PUSH_PROMISE on the control stream *in additi= on to* any stream that it is sent on. This would ensure that no matter what= , the PUSH_PROMISE is always received, and additionally ensures that CANCEL= _PUSH is received after a PUSH_PROMISE.

I don't think that is a good idea.=C2=A0 PUSH_PROMISE i= ncludes a headers block, which is pretty big, even with effective compressi= on.=C2=A0 HoLB won't affect this stream, so size shouldn't be an is= sue, but still.

I did consider moving the head= er block to the control stream completely as part of addressing the issue w= ith duplication that I mentioned earlier.=C2=A0 The basic problem there is = that you don't guarantee that the client see the PUSH_PROMISE before it= processes the response content.
=C2= =A0

- jana
<= div class=3D"gmail_extra">
On Thu, Aug 3, 201= 7 at 5:49 PM, Mike Bishop <Michael.Bishop@microsoft.com>= wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.






--
Kazuho Oku
--f403045ff686a769dd0555e80fae-- From nobody Fri Aug 4 06:41:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3333F131C8D for ; Fri, 4 Aug 2017 06:41:35 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHW7qK7iUYsy for ; Fri, 4 Aug 2017 06:41:32 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A941201F8 for ; Fri, 4 Aug 2017 06:41:31 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s143so10056623ywg.1 for ; Fri, 04 Aug 2017 06:41:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xRn+wupFQAgqVovg9glSqOUKa02RuGoWTQv7avNHvlQ=; b=dKE2nzxhUdG+MEnk5mehbnNJbIyBlxytYwU5tOqW4zrmON+qyuQYLADTRv1LfF8qc2 V0aFUZClrTUQwSFLyA1VMV0pNo01eq+Lex3t+17xXVkdGHLoreWpC7JeMn4zK1FubFVi XCpqM3mNdPyFcaIsfz3Cbn8Ezz8o9ykM4E9/Z/jiFRmpOu9btRTXAqwg2rQEA2yt5nWE fjHCqC302dcs9zvVRAF/noAsEXA4+pXDtkxd3ihTM7908CtHWUqHA/2hCDq1287tHZX3 VQ06qenGCVMHOwwpPHN7w9cCleECHTGPOie63g+YUsdqkQqvd6bWA6QACBsHVFwA8Stk Jmwg== 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=xRn+wupFQAgqVovg9glSqOUKa02RuGoWTQv7avNHvlQ=; b=JS6lD5VEQZrsnjtRdyOM/Fjzp6AFYm6Plff8nrJzyLfpx+a874MbiDH5eMjOJo8tZL 2cLrBNSV/bZpJdefZzE1AjNoTqakDoP92uIRtsD+BOxH7uR1/s2GJkAibXg+ia4xX78N +X1FHnxNJeB1vU7OOt6XwtAmcijqTzIRh+AJmrhKiXsMoJqMU6qNsH+zlVO1LTDbH7YJ mnRLpvsmYMT3vcodvOm4lGAU2ePLq6DeWOELYzO1ISNN8u8WZ4rmUX2Vrgo8NZhpHw4O NDmnOOPUgaj1ZTmPYDteyk/wF9PvTkUYWznasEu1mq0bSey4zqKIoT+roNQFnFZzjkE/ fQJQ== X-Gm-Message-State: AIVw112564pdaz0BQ9A1ncNKUy7C2rS3NhnasaqyflPq2T9uOD13dMSJ hZN7MJVL/J4oInO5d7hfRA1eGHu47OxK X-Received: by 10.129.121.86 with SMTP id u83mr1851944ywc.397.1501854090649; Fri, 04 Aug 2017 06:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Fri, 4 Aug 2017 06:41:10 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Fri, 4 Aug 2017 09:41:10 -0400 Message-ID: Subject: Re: Push ID - Merge Imminent To: Kazuho Oku Cc: Martin Thomson , Jana Iyengar , QUIC WG , "ietf-http-wg@w3.org" , Mike Bishop Content-Type: multipart/alternative; boundary="94eb2c0a8b3294683f0555eda710" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 04 Aug 2017 13:41:35 -0000 --94eb2c0a8b3294683f0555eda710 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Making Push ID sequential is also nice from a debugging perspective, so I think we should make Push ID sequential. I can imagine MAX_PUSH_ID being useful, but I'm not sure it's necessary at this point, so I'd prefer to not add that now. On Fri, Aug 4, 2017 at 3:01 AM, Kazuho Oku wrote: > > > 2017-08-04 10:36 GMT+09:00 Martin Thomson : > >> >> >> On 4 August 2017 at 10:31, Jana Iyengar wrote: >> >>> I think the high-order idea is great, and I'm totally in favor. I've >>> raised several editorial issues, but there's one substantitive one that= may >>> be worth discussing here. >>> >>> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >>> server. The text currently says that CANCEL_PUSH on a non-existent Push= ID >>> results in error, which does not work with the possibility of reorderin= g >>> between PUSH_PROMISE and CANCEL_PUSH. >>> >> >> That's just a bug. >> >> >>> Similarly, it's also possible for the PUSH_PROMISE to not have been >>> received because the stream on which it was sent was reset... basically >>> it's possible for a client to receive a CANCEL_PUSH without seeing the >>> corresponding PUSH_PROMISE. >>> >> >> This is more interesting. It creates state on the client: it says that >> clients are required to ignore pushes that it *might* receive in the >> future. That suggests a different fix, akin to what we use for other >> similar pieces of state: >> >> 1. make Push ID sequential (right now the only requirement is for >> connection-wide uniqueness) >> > > I think that using a sequential ID will be a good idea not only for fixin= g > this issue but that it might be possible to use the sequentiality to fix > the first issue raised in the PR (i.e. client knowing "when the server wi= ll > stop referencing a push ID in PUSH_PROMISE"). > > If there is a sequential ordering guarantee for Push ID, a client can, by > looking at the Push ID, determine whether if it has already consumed the > pushed request. If it has, it will immediately lookup its cache, and in > case it fails to find a cached object, then issue a pull. If it has not > consumed the pushed request, it should wait for the pushed response to > arrive. > > > >> >> 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new >> frame type; the setting might {ab|re}use ENABLE_PUSH) >> >> This would bound state for clients. A client couldn't receive an >> arbitrary number of CANCEL_PUSH messages that are distributed over the >> 32-bit Push ID space, so tracking cancellations is easy. Clients could = use >> a simple bitvector to track which pushes are potentially interesting, >> clearing bits as pushes or cancellations arrive. >> >> MAX_PUSH_ID would give clients a finer-grained lever to control push. >> >> We could have CANCEL_PUSH be sent on the same streams as the >>> PUSH_PROMISE, but that doesn't help with the case where the PUSH_PROMIS= E >>> may not have been received due to a stream reset. >>> >>> This makes me wonder if it makes sense to always send the PUSH_PROMISE >>> on the control stream *in addition to* any stream that it is sent on. T= his >>> would ensure that no matter what, the PUSH_PROMISE is always received, = and >>> additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE. >>> >> >> I don't think that is a good idea. PUSH_PROMISE includes a headers >> block, which is pretty big, even with effective compression. HoLB won't >> affect this stream, so size shouldn't be an issue, but still. >> >> I did consider moving the header block to the control stream completely >> as part of addressing the issue with duplication that I mentioned earlie= r. >> The basic problem there is that you don't guarantee that the client see = the >> PUSH_PROMISE before it processes the response content. >> >> >>> >>> - jana >>> >>> On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop < >>> Michael.Bishop@microsoft.com> wrote: >>> >>>> Bah, QUIC too. =F0=9F=98=8A >>>> >>>> >>>> >>>> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] >>>> *Sent:* Thursday, August 3, 2017 10:36 AM >>>> *To:* ietf-http-wg@w3.org >>>> *Subject:* Push ID - Merge Imminent >>>> >>>> >>>> >>>> This is Martin=E2=80=99s Push ID PR split off from unidirectional. Gi= ven that >>>> it has already been picked over in those contexts and the feedback fro= m >>>> that and in-person discussion was to bring this change in separately, = I=E2=80=99m >>>> about ready to merge this. Everything anyone has quibbled with has be= en >>>> editorial. However, I don=E2=80=99t see reviews from many folks, so I= want to make >>>> sure that everyone interested has had a chance to express an opinion. >>>> >>>> >>>> >>>> https://github.com/quicwg/base-drafts/pull/701 >>>> >>>> >>>> >>>> >>>> I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at leas= t a little bit of >>>> a work day), then merge unless I hear otherwise. >>>> >>> >>> >> > > > -- > Kazuho Oku > --94eb2c0a8b3294683f0555eda710 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Making Push ID sequential is also nice from a debugging pe= rspective, so I think we should make Push ID sequential.

I can imagine MAX_PUSH_ID being useful, but I'm not sure it's nece= ssary at this point, so I'd prefer to not add that now.

On Fri, Aug 4, 2017 a= t 3:01 AM, Kazuho Oku <kazuhooku@gmail.com> wrote:

=
2017-08-04 10:36 GMT+09:00 = Martin Thomson <martin.thomson@gmail.com>:


On 4 August 2017 at 10:31, Jana Iyengar = <jri@google.com&= gt; wrote:
I think the high-order idea is great, and I'm totally in f= avor. I've raised several editorial issues, but there's one substan= titive one that may be worth discussing here.

PUSH_PROMI= SE is sent by the server, and CANCEL_PUSH may be sent by the server. The te= xt currently says that CANCEL_PUSH on a non-existent Push ID results in err= or, which does not work with the possibility of reordering between PUSH_PRO= MISE and CANCEL_PUSH.

T= hat's just a bug.
=
=C2=A0
Similarly, it's also possible for the PUSH_PROMISE to not= have been received because the stream on which it was sent was reset... ba= sically it's possible for a client to receive a CANCEL_PUSH without see= ing the corresponding PUSH_PROMISE.

=
This is more interesting.=C2=A0 It creates state on the client:= =C2=A0 it says that clients are required to ignore pushes that it *might* r= eceive in the future.=C2=A0 That suggests a different fix, akin to what we = use for other similar pieces of state:

1. make Pus= h ID sequential (right now the only requirement is for connection-wide uniq= ueness)

I th= ink that using a sequential ID will be a good idea not only for fixing this= issue but that it might be possible to use the sequentiality to fix the fi= rst issue raised in the PR (i.e. client knowing "when the server will = stop referencing a push ID in PUSH_PROMISE").

If there is a sequential ordering guarantee for Push ID, a client can, by = looking at the Push ID, determine whether if it has already consumed the pu= shed request. If it has, it will immediately lookup its cache, and in case = it fails to find a cached object, then issue a pull. If it has not consumed= the pushed request, it should wait for the pushed response to arrive.
<= /div>

=C2=A0

2. have the client advertise a= MAX_PUSH_ID (in SETTINGS, and with a new frame type; the setting might {ab= |re}use ENABLE_PUSH)

This would bound state for clients= .=C2=A0 A client couldn't receive an arbitrary number of CANCEL_PUSH me= ssages that are distributed over the 32-bit Push ID space, so tracking canc= ellations is easy.=C2=A0 Clients could use a simple bitvector to track whic= h pushes are potentially interesting, clearing bits as pushes or cancellati= ons arrive.

MAX_PUSH_ID would give clients a finer-grained lever to control push.=

=
We could have CANCEL_PUSH be sent = on the same streams as the PUSH_PROMISE, but that doesn't help with the= case where the PUSH_PROMISE may not have been received due to a stream res= et.

This makes me wonder if it makes sense to alwa= ys send the PUSH_PROMISE on the control stream *in addition to* any stream = that it is sent on. This would ensure that no matter what, the PUSH_PROMISE= is always received, and additionally ensures that CANCEL_PUSH is received = after a PUSH_PROMISE.

I = don't think that is a good idea.=C2=A0 PUSH_PROMISE includes a headers = block, which is pretty big, even with effective compression.=C2=A0 HoLB won= 't affect this stream, so size shouldn't be an issue, but still.

I did consider moving the header block to the co= ntrol stream completely as part of addressing the issue with duplication th= at I mentioned earlier.=C2=A0 The basic problem there is that you don't= guarantee that the client see the PUSH_PROMISE before it processes the res= ponse content.
= =C2=A0

- jana

On Thu, Aug 3, 2017 at 5:49= PM, Mike Bishop <Michael.Bishop@microsoft.com> w= rote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.





--
Kazuho Oku

--94eb2c0a8b3294683f0555eda710-- From nobody Fri Aug 4 17:55:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C03129B5E for ; Fri, 4 Aug 2017 17:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUH4Nyb-JS6r for ; Fri, 4 Aug 2017 17:55:28 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::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 508AC129B61 for ; Fri, 4 Aug 2017 17:55:28 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c28so12867112pfe.3 for ; Fri, 04 Aug 2017 17:55:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9DfQbMaerHshmikj3rtPqT+gmvfp2A8Xo4EAOY5B1qU=; b=t2iuQRyemS4D2koSMC0WDmC849QVwBaNeBhcL+6H9G/YWNMIjY/wOAMDxBzTteNM3K YAthTNtJLtUvZCLteYHwefx1rzPqPz1JrQUBD1QVHbzZbrUGv8AoQQ1VFW60wBnBVjkI GDr3O0RsyEfNcA7s89bo6jp2jKZcto3xkgt5InBOVJFTj5i7lLjnaIjCAP4KtpEjyiPD dYzetWpT+DXRjjk1Un+xN9XKogWnn/wJl1D/mjQ+dBiIqG7L4DJj8HX+LDKkyKfXX+vZ kYayADta50Ssju5dEhtCB1HXVxH47FYd9VOTFhYQAsLQR4kGumQQ0cBDd4MlVCECV6bT bY0w== 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=9DfQbMaerHshmikj3rtPqT+gmvfp2A8Xo4EAOY5B1qU=; b=emkgahCiODvFBpGC6EGWqQj/wSegjf1sYaDmYOnJrSJgdiA9TbbS2qEd2KiKE7UMeb xSyBfAz97lTvaMQCoYNehPZu/0sDDPTU96qlYzvpXup1LskAf6LBwL0HyvVL6DNBXauf TKZpOSbrkgkm+XTHfnaVeKX/wSciW1KjjYizCoT18NEymEpxVDh0IMBBh73Z8a9UB2dl AKokYooJwrs7SZn2Vk5YuBNOpBwEQoV8wsxc32LlzZ7JEXwG9F3YBsLITPkOFg0t3zav 6nmYeFL8RL6YZB1uzWhuvKD3JXMQFsrk0AYPkHqVBUKBdX3jbAUYZzgnAKZ5FFtpWHZ3 wjMQ== X-Gm-Message-State: AIVw112OlIdKlenuvylCvodUjQugvG4dpyqAIOmVX3YfG3qf8B7Xpmhk JKNefQAzmATsnJMhSKgmVB1Y619X7Lb3 X-Received: by 10.84.232.204 with SMTP id x12mr4928581plm.362.1501894527495; Fri, 04 Aug 2017 17:55:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Fri, 4 Aug 2017 17:55:26 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Fri, 4 Aug 2017 17:55:26 -0700 Message-ID: Subject: Re: Push ID - Merge Imminent To: Ian Swett Cc: Kazuho Oku , Martin Thomson , QUIC WG , "ietf-http-wg@w3.org" , Mike Bishop Content-Type: multipart/alternative; boundary="f40304361942cd97650555f711cf" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Aug 2017 00:55:31 -0000 --f40304361942cd97650555f711cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Martin, I think the idea of sequential Push ID is a good one. You have to specify a MAX_PUSH_ID, without which the client won't know how far out to expect CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE message which can be used to move the MAX up. One note: > PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >>>> server. The text currently says that CANCEL_PUSH on a non-existent Pus= h ID >>>> results in error, which does not work with the possibility of reorderi= ng >>>> between PUSH_PROMISE and CANCEL_PUSH. >>>> >>> >>> That's just a bug. >>> >> I don't think so. The spec allows it, and I can easily see it happen in practice. - jana > >>> >>>> Similarly, it's also possible for the PUSH_PROMISE to not have been >>>> received because the stream on which it was sent was reset... basicall= y >>>> it's possible for a client to receive a CANCEL_PUSH without seeing the >>>> corresponding PUSH_PROMISE. >>>> >>> >>> This is more interesting. It creates state on the client: it says tha= t >>> clients are required to ignore pushes that it *might* receive in the >>> future. That suggests a different fix, akin to what we use for other >>> similar pieces of state: >>> >>> 1. make Push ID sequential (right now the only requirement is for >>> connection-wide uniqueness) >>> >> >> I think that using a sequential ID will be a good idea not only for >> fixing this issue but that it might be possible to use the sequentiality= to >> fix the first issue raised in the PR (i.e. client knowing "when the serv= er >> will stop referencing a push ID in PUSH_PROMISE"). >> >> If there is a sequential ordering guarantee for Push ID, a client can, b= y >> looking at the Push ID, determine whether if it has already consumed the >> pushed request. If it has, it will immediately lookup its cache, and in >> case it fails to find a cached object, then issue a pull. If it has not >> consumed the pushed request, it should wait for the pushed response to >> arrive. >> >> >> >>> >>> 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new >>> frame type; the setting might {ab|re}use ENABLE_PUSH) >>> >>> This would bound state for clients. A client couldn't receive an >>> arbitrary number of CANCEL_PUSH messages that are distributed over the >>> 32-bit Push ID space, so tracking cancellations is easy. Clients could= use >>> a simple bitvector to track which pushes are potentially interesting, >>> clearing bits as pushes or cancellations arrive. >>> >>> MAX_PUSH_ID would give clients a finer-grained lever to control push. >>> >>> We could have CANCEL_PUSH be sent on the same streams as the >>>> PUSH_PROMISE, but that doesn't help with the case where the PUSH_PROMI= SE >>>> may not have been received due to a stream reset. >>>> >>>> This makes me wonder if it makes sense to always send the PUSH_PROMISE >>>> on the control stream *in addition to* any stream that it is sent on. = This >>>> would ensure that no matter what, the PUSH_PROMISE is always received,= and >>>> additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE= . >>>> >>> >>> I don't think that is a good idea. PUSH_PROMISE includes a headers >>> block, which is pretty big, even with effective compression. HoLB won'= t >>> affect this stream, so size shouldn't be an issue, but still. >>> >>> I did consider moving the header block to the control stream completely >>> as part of addressing the issue with duplication that I mentioned earli= er. >>> The basic problem there is that you don't guarantee that the client see= the >>> PUSH_PROMISE before it processes the response content. >>> >>> >>>> >>>> - jana >>>> >>>> On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop < >>>> Michael.Bishop@microsoft.com> wrote: >>>> >>>>> Bah, QUIC too. =F0=9F=98=8A >>>>> >>>>> >>>>> >>>>> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] >>>>> *Sent:* Thursday, August 3, 2017 10:36 AM >>>>> *To:* ietf-http-wg@w3.org >>>>> *Subject:* Push ID - Merge Imminent >>>>> >>>>> >>>>> >>>>> This is Martin=E2=80=99s Push ID PR split off from unidirectional. G= iven that >>>>> it has already been picked over in those contexts and the feedback fr= om >>>>> that and in-person discussion was to bring this change in separately,= I=E2=80=99m >>>>> about ready to merge this. Everything anyone has quibbled with has b= een >>>>> editorial. However, I don=E2=80=99t see reviews from many folks, so = I want to make >>>>> sure that everyone interested has had a chance to express an opinion. >>>>> >>>>> >>>>> >>>>> https://github.com/quicwg/base-drafts/pull/701 >>>>> >>>>> >>>>> >>>>> >>>>> I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at lea= st a little bit >>>>> of a work day), then merge unless I hear otherwise. >>>>> >>>> >>>> >>> >> >> >> -- >> Kazuho Oku >> > > --f40304361942cd97650555f711cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Mart= in,

I = think the idea of sequential Push ID is a good one. You have to specify a M= AX_PUSH_ID, without which the client won't know how far out to expect C= ANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE message= which can be used to move the MAX up.

=
One note:
=C2=A0
<= div class=3D"h5">
=
PUSH_PROMISE= is sent by the server, and CANCEL_PUSH may be sent by the server. The text= currently says that CANCEL_PUSH on a non-existent Push ID results in error= , which does not work with the possibility of reordering between PUSH_PROMI= SE and CANCEL_PUSH.

Tha= t's just a bug.
=

I don't think so. The spec allows it, and I can easily see it happen i= n practice.

- jana
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0
Similarly, it's als= o possible for the PUSH_PROMISE to not have been received because the strea= m on which it was sent was reset... basically it's possible for a clien= t to receive a CANCEL_PUSH without seeing the corresponding PUSH_PROMISE.

This is more interesting.= =C2=A0 It creates state on the client:=C2=A0 it says that clients are requi= red to ignore pushes that it *might* receive in the future.=C2=A0 That sugg= ests a different fix, akin to what we use for other similar pieces of state= :

1. make Push ID sequential (right now the only r= equirement is for connection-wide uniqueness)

I think that using a sequential ID will b= e a good idea not only for fixing this issue but that it might be possible = to use the sequentiality to fix the first issue raised in the PR (i.e. clie= nt knowing "when the server will stop referencing a push ID in PUSH_PR= OMISE").

If there is a sequential ordering gu= arantee for Push ID, a client can, by looking at the Push ID, determine whe= ther if it has already consumed the pushed request. If it has, it will imme= diately lookup its cache, and in case it fails to find a cached object, the= n issue a pull. If it has not consumed the pushed request, it should wait f= or the pushed response to arrive.

=C2=A0=

2. = have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new frame = type; the setting might {ab|re}use ENABLE_PUSH)

This wo= uld bound state for clients.=C2=A0 A client couldn't receive an arbitra= ry number of CANCEL_PUSH messages that are distributed over the 32-bit Push= ID space, so tracking cancellations is easy.=C2=A0 Clients could use a sim= ple bitvector to track which pushes are potentially interesting, clearing b= its as pushes or cancellations arrive.

=
MAX_PUSH_ID would give clients a finer-gra= ined lever to control push.

=
We could have CANCEL_PUSH be sent on the same streams as the= PUSH_PROMISE, but that doesn't help with the case where the PUSH_PROMI= SE may not have been received due to a stream reset.

This makes me wonder if it makes sense to always send the PUSH_PROMISE o= n the control stream *in addition to* any stream that it is sent on. This w= ould ensure that no matter what, the PUSH_PROMISE is always received, and a= dditionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE.

I don't think that is a = good idea.=C2=A0 PUSH_PROMISE includes a headers block, which is pretty big= , even with effective compression.=C2=A0 HoLB won't affect this stream,= so size shouldn't be an issue, but still.

I did consider moving the header block to the control stream completely as= part of addressing the issue with duplication that I mentioned earlier.=C2= =A0 The basic problem there is that you don't guarantee that the client= see the PUSH_PROMISE before it processes the response content.
=C2=A0=

- jana

On Thu, Aug 3, 2017 at 5:49 PM, Mike Bisho= p <Michael.Bishop@microsoft.com> wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.






--
Kazuho Oku

--f40304361942cd97650555f711cf-- From nobody Sat Aug 5 03:24:01 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAA6129B25 for ; Sat, 5 Aug 2017 03:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1orLrxTWc3dV for ; Sat, 5 Aug 2017 03:23:57 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F8912EC13 for ; Sat, 5 Aug 2017 03:23:56 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 77so17387856itj.1 for ; Sat, 05 Aug 2017 03:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ElXlBSCNW6Bjk5jdYw0Xmf0wsYY815F31GdxhPuhxWI=; b=EbT8fLTi6py02pc1Fd/UvF6tl0laoSJbdykxvffiDIABkv6gbiwNJKMG+ZyuPSa5a/ 9awzqyEZqDEKICcgODZdAH80wMqePHNlmeLl21eV+CyNLBXonV3F4pY6kTnZ8ifFKCRT BBotow+qjJsz51y7dqETFNiv79PjIuX0FT12DPIBTnBfOF5VvCucBHO18w2kSiRzgKEQ mkwOaJ1yrlLtx8yFGIV+HZIpjoy2NSy9TqzjJimgzomxoRfToGyNoVUIVbHXcJaxN26t jRLmsN2JuNHI+uKt40HaJVq/noKI5x0jxzfM9PZawroVQjVL7oc4P8Hugdc7QthULNL4 dIkQ== 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=ElXlBSCNW6Bjk5jdYw0Xmf0wsYY815F31GdxhPuhxWI=; b=fdUkS++3XTx/7zqSmpt1/XS1YD+G/HMuPgGCwIAHY4N5D0CTEksVOsNG2TSVwJBWTZ KzzJj6pvonJDhW8bORc2IPjZrxalXsbVXwRx4TyrtmBdcp9+MC0A3JgROKUjewi7Bv9L 9s2n1DtNeR9qnlgF7NeTRq1j7a3ROWC03eiwSoQC6Hf1LNKV0pk7rScbacYY2ujHFTNU uWSuu+aVvAd0xjbdIiY3BcIER65IR91Wvx0KoylnqPTsmxzj9GblVPL+fB0BXcS5tOwZ B6QsNgAXqFoKuRm+4UY/X2+zPx/YHIOQu7UHI48tisBHpk+zqb86vYBZzaonwWe8mB5u KUgg== X-Gm-Message-State: AIVw11285At/zsz3Z9GKFwsh4zdpWhm5iR3MA8jeTyuMiZp+tnI8Qy1R ZmIXGdL4E/ILlcd/8GbaPnkEUrdREg== X-Received: by 10.36.87.5 with SMTP id u5mr4814607ita.151.1501928636298; Sat, 05 Aug 2017 03:23:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sat, 5 Aug 2017 03:23:55 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 5 Aug 2017 20:23:55 +1000 Message-ID: Subject: Re: Push ID - Merge Imminent To: Jana Iyengar Cc: Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" , Mike Bishop Content-Type: multipart/alternative; boundary="001a1143ed2cd83b850555ff02ee" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Aug 2017 10:23:59 -0000 --001a1143ed2cd83b850555ff02ee Content-Type: text/plain; charset="UTF-8" On 5 August 2017 at 10:55, Jana Iyengar wrote: > Martin, > > I think the idea of sequential Push ID is a good one. You have to specify > a MAX_PUSH_ID, without which the client won't know how far out to expect > CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE > message which can be used to move the MAX up. > > One note: > > >> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >>>>> server. The text currently says that CANCEL_PUSH on a non-existent Push ID >>>>> results in error, which does not work with the possibility of reordering >>>>> between PUSH_PROMISE and CANCEL_PUSH. >>>>> >>>> >>>> That's just a bug. >>>> >>> > I don't think so. The spec allows it, and I can easily see it happen in > practice. > By bug, I meant that I made a mistake in the PR and forgot about the possibility of reordering, that's all. --001a1143ed2cd83b850555ff02ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 5= August 2017 at 10:55, Jana Iyengar <jri@google.com> wrote:
=
=
Martin,

I think the idea of sequential Push ID is a go= od one. You have to specify a MAX_PUSH_ID, without which the client won'= ;t know how far out to expect CANCEL_PUSHes can be... this also requires th= en a MAX_PUSH_ID_UPDATE message which can be used to move the MAX up.
=

One note:
=C2=A0
PUSH_PROMISE is sent by the server, and CANCEL_PU= SH may be sent by the server. The text currently says that CANCEL_PUSH on a= non-existent Push ID results in error, which does not work with the possib= ility of reordering between PUSH_PROMISE and CANCEL_PUSH.

That's just a bug.
=
=

I don't think so. The spe= c allows it, and I can easily see it happen in practice.
<= /div>

By bug, I meant that I made a mistake= in the PR and forgot about the possibility of reordering, that's all.<= br>
--001a1143ed2cd83b850555ff02ee-- From nobody Sat Aug 5 03:24:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53EF4128C81 for ; Sat, 5 Aug 2017 03:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8-JeUAA7HaJ for ; Sat, 5 Aug 2017 03:24:41 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDC3131CA7 for ; Sat, 5 Aug 2017 03:24:40 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v77so16980156pgb.3 for ; Sat, 05 Aug 2017 03:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BhqvPysPb2uSQeVkSMzo89O4/l+QUF6EoF24ZPMiZmE=; b=DtCluNFyyRllCvpUgCuI+s+QZ6IhJ2kYOAxVmJ6JewIKpnZp7X6+MB8lgU/s30EHSW 2F1fcP9pMn6TxbEWwuVoNJZabMn+jpoV1BuqxKuCcZf2B4f4izMdUEAcdED1+DdkEFvx AbR/1sKmQlY7XtauT9//i/gk4PnOBs1Er2jUGi/kqHRQpTpSLxEv5Fd6UEnkSHZeNOxR hRxAtRa2cxZhIepO1+GOonWBsfZB1xfDs7mk8AKTVc2CexhACRMxdRPjxuQ2f56sXVDy 4MDmgWbXy4BIDBJKeHyzvB1aJpwnXd88xtJk9U/WvQIRrpPKnYVlg0YcZRnjiA1qjj2/ /1wA== 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=BhqvPysPb2uSQeVkSMzo89O4/l+QUF6EoF24ZPMiZmE=; b=JbPyfcnFR6KtnEh0l+oI5dtKbvuL/k+65iOevpI0ehX88emvz4j3Raj/TiEA5CKGU8 9xTQlwxgNUWKNHvhVz56SvMPktYkXHi7WDPZl3zDouMjdGieBrQoCH4dB0pRJVhb6e1z oVEX8Bz4g9f3cPQfarTgwOOymUg46iNEd8l5Sfwk7ZHk1qIktYWGDoxFV99GZJAiMolE lc/jWj+BIOEuQ4n8qjhPZTaYDk+GSuG60FmI7Tu6dGfFff6DSrRmCdXaYouvNLUn1jw+ fGtQxjVTh25XdzAbmzpvlYJeV5X7041DNZ4ed6pyjVxWSTtCE1AYEo0uIiKPpntu6Byo BqAw== X-Gm-Message-State: AIVw111f3+f3PclVVVoMmPOM1h78TMITx2PFLXBnIPnheMMJX0y1grCa QGb/hZNc/pklV4U5SNNiuIFJh/0pG6z3 X-Received: by 10.99.109.77 with SMTP id i74mr5436451pgc.438.1501928680145; Sat, 05 Aug 2017 03:24:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.153.19 with HTTP; Sat, 5 Aug 2017 03:24:39 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Sat, 5 Aug 2017 03:24:39 -0700 Message-ID: Subject: Re: Push ID - Merge Imminent To: Martin Thomson Cc: Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" , Mike Bishop Content-Type: multipart/alternative; boundary="f403045c0660762acb0555ff0597" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 05 Aug 2017 10:24:43 -0000 --f403045c0660762acb0555ff0597 Content-Type: text/plain; charset="UTF-8" Ah, got it. On Sat, Aug 5, 2017 at 3:23 AM, Martin Thomson wrote: > On 5 August 2017 at 10:55, Jana Iyengar wrote: > >> Martin, >> >> I think the idea of sequential Push ID is a good one. You have to specify >> a MAX_PUSH_ID, without which the client won't know how far out to expect >> CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE >> message which can be used to move the MAX up. >> >> One note: >> >> >>> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >>>>>> server. The text currently says that CANCEL_PUSH on a non-existent Push ID >>>>>> results in error, which does not work with the possibility of reordering >>>>>> between PUSH_PROMISE and CANCEL_PUSH. >>>>>> >>>>> >>>>> That's just a bug. >>>>> >>>> >> I don't think so. The spec allows it, and I can easily see it happen in >> practice. >> > > By bug, I meant that I made a mistake in the PR and forgot about the > possibility of reordering, that's all. > --f403045c0660762acb0555ff0597 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, got it.=C2=A0

On Sat, Aug 5, 2017 at 3:23 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 5 August 2017 at 10:55, Jana Iyengar <jri@google.co= m> wrote:
=
Martin,

I think the idea of= sequential Push ID is a good one. You have to specify a MAX_PUSH_ID, witho= ut which the client won't know how far out to expect CANCEL_PUSHes can = be... this also requires then a MAX_PUSH_ID_UPDATE message which can be use= d to move the MAX up.

One note:
= =C2=A0
PUSH_PROMISE is sent by the server, and CA= NCEL_PUSH may be sent by the server. The text currently says that CANCEL_PU= SH on a non-existent Push ID results in error, which does not work with the= possibility of reordering between PUSH_PROMISE and CANCEL_PUSH.

That's just a bug.

I don't think so. = The spec allows it, and I can easily see it happen in practice.
=

By bug, I meant that I = made a mistake in the PR and forgot about the possibility of reordering, th= at's all.

--f403045c0660762acb0555ff0597-- From nobody Sun Aug 6 03:18:25 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE2B7129ABE for ; Sun, 6 Aug 2017 03:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ga36dwSlJtn5 for ; Sun, 6 Aug 2017 03:18:23 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 E04B9131D69 for ; Sun, 6 Aug 2017 03:18:22 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id f9so21231136uaf.4 for ; Sun, 06 Aug 2017 03:18:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=EnziIOAWkLsS1go2RZriF1+s+HXXsKHaO+tl8avT9Vk=; b=PuTynDU7BxrNtJnZ4C3xXRIk/XMDBLAmd+htoHmEESklL4i9lvA8txc3Btag0LdN+g +qN1mHMtr/lY6f4Ou6Zq2lnOaUZyg8qnAohtl2XgNUPy2crzVms33TuxQeBiqY3dMvCv zvhYOm8L3LE3NpOjQy0CCb3L+s5wmp8EYYPqjYDFI7frX/OmUOnJ5vB1fZvOnFfCqkpa u/lO5H1+jzm5np8HPAFwnVPKSQp7fsu2rJOvI4pWIbYfPdk4Fno0aGDaohEPLds7BqGi rkHBrubTkGdPAvH83rYPnzsodC++Gz2tbo2kuEwrED8LYDGyHcW1qNAs4R7bg2TS37Wh I1IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=EnziIOAWkLsS1go2RZriF1+s+HXXsKHaO+tl8avT9Vk=; b=K4rDW8CwW73yuU15w04u3NGNrkycHsLZNEZUXqSYwtgsJ4mRK0UrrMMQ7qnM9trEv9 urQUrhTRHF5U2ga6keKXL5tyxWlAbQCp2oK/iLOKEkgB2YhNWSH5Vv9k2dJfY9Dysjm+ t4HNrctuyUxBC8pWK0RhMZFMwX2jiaAER03qxyGrpnXnBngLU5aWSsvyJDPiXH+RrPxH GB1MbVUQPzX/zQEOYiem0Cpgn+zf8JS/T3JVyg1/7mTk64fJtvYZ7iwIxU00s3suxSuH 2nu5zIhiXGQ5LRAqkeq5kxEVF5IVvVvBEtmDYccrh6oQJwJV6VBEtUnybLljSAMp29aa Lkrw== X-Gm-Message-State: AHYfb5ibIusiD9WipYl4t3EOTJT4Zdqw9WYy7aBA3chRVS5BLRD/zfy9 s3iA3z39Tz6cC2pXxnAhT6jjfnOHWvsQ X-Received: by 10.159.52.79 with SMTP id s15mr5993210uab.157.1502014701800; Sun, 06 Aug 2017 03:18:21 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 6 Aug 2017 06:18:21 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 6 Aug 2017 06:18:21 -0400 Message-ID: Subject: 5-tuple uniquess To: quic@ietf.org Content-Type: multipart/alternative; boundary="f403043ed1d4bf90ee0556130cc7" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Aug 2017 10:18:25 -0000 --f403043ed1d4bf90ee0556130cc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Have argued before as comments to various issues, but I=E2=80=99ll try once= more on the list: Please consider making QUIC independent of the underlying transport, including assumptions on the uniqueness of the UDP protocol. 1. If a http server is able to receive 100K connections, it will not be able to forward them to the same backend service because there are not enough ephemeral port numbers to create a reverse proxy connection per incoming connection. 2. It would be fragile to port to QUIC to alternative transports because of implied assumptions on the connectivity. For example on an I2C bus. 3. If a client receives its own initial connection id as a response from a server, even if the server has decided on a new connection id, the client can trivially identify the connection with a simple lookup, and trivially reject other connections. This requires that the connection id is visible (recent discussions on encryption of cleartext might challenge this, but the initial connection id could be part of authenticated data). 4. On connection migration there would need to be special considerations, but again, handling this up front would simplify 2. The obvious drawback of this is the connection id must remain in clear text which takes space and might cause some privacy concerns. Regarding privacy, I don=E2=80=99t think it is more or less secret than a unique 5-tuple for a= n on-path interceptor. As to size, this is unfortunate. If designed carefully, it may be possible to omit the connection id as it is today for scenarios where the 5-tuple is sufficient. For example, public network might use 5-tuple without explicit connection id, reverse proxy might not. But overall, I would prefer the simplicity of always having the connection id. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --f403043ed1d4bf90ee0556130cc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Have argued before as comments to various issues,= but I=E2=80=99ll try once more on the list:

Please consider making QUIC independent of the unde= rlying transport, including assumptions on the uniqueness of the UDP protoc= ol.

1. If a http serv= er is able to receive 100K connections, it will not be able to forward them= to the same backend service because there are not enough ephemeral port nu= mbers to create a reverse proxy connection per incoming connection.

2. It would be fragile to po= rt to QUIC to alternative transports because of implied assumptions on the = connectivity. For example on an I2C bus.

3. If a client receives its own initial connection id a= s a response from a server, even if the server has decided on a new connect= ion id, the client can trivially identify the connection with a simple look= up, and trivially reject other connections. This requires that the connecti= on id is visible (recent discussions on encryption of cleartext might chall= enge this, but the initial connection id could be part of authenticated dat= a).

4. On connection = migration there would need to be special considerations, but again, handlin= g this up front would simplify 2.

The obvious drawback of this is the connection id must remai= n in clear text which takes space and might cause some privacy concerns. Re= garding privacy, I don=E2=80=99t think it is more or less secret than a uni= que 5-tuple for an on-path interceptor. As to size, this is unfortunate. If= designed carefully, it may be possible to omit the connection id as it is = today for scenarios where the 5-tuple is sufficient. For example, public ne= twork might use 5-tuple without explicit connection id, reverse proxy might= not. But overall, I would prefer the simplicity of always having the conne= ction id.


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

--f403043ed1d4bf90ee0556130cc7-- From nobody Sun Aug 6 07:17:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFB2131D21 for ; Sun, 6 Aug 2017 07:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rZzCMCDxiMm for ; Sun, 6 Aug 2017 07:17:02 -0700 (PDT) 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 EF156131D19 for ; Sun, 6 Aug 2017 07:17:01 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so50885487wma.0 for ; Sun, 06 Aug 2017 07:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zvMh8VGQOtfJXt08r2X0FO5GLoKy617D9Pr32Mgi8bY=; b=XRX7q7ARb4UWg4quJrFvMxNGH6LnArfQXF6OfMGX5+U53/+uROc2VwtQpMHqGyaYT/ e2tKDGx/2cK2tLq3O4sPfnN+q6l5z+ow9SLvZx796zj72QWY/WzemURouke8Gecz7/nN 6YhY5BwoZEltUTSTvqnS0UrCBdwqE5St7tv5BBnM0ZioNN+nAsrRzVPxzFlwWb3w1/9Q HuH0zZrNL9CMHYLtLYy+7W/CWixUentRWPxX8lp41Fmo9wLvqL34FGmBkQgvWPjzgNLs 85lnSlAfBiHBc3ZOCtcdSAvnIHInDHg7tQjiLCzCmSZmvXyWYqtxkygtPmgycPXB0lgR jdeQ== 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=zvMh8VGQOtfJXt08r2X0FO5GLoKy617D9Pr32Mgi8bY=; b=ceSqhWstXZq+EutGpSH9JNynpc1Cn1V8LdNsK28+929mM0eISckDwD85kcSZoe5dHj Zf59/pIyfpeTfrHL1F5ILO9k5SXKHkpC54Z4kmLwaJiVOeIGV91sZNm/B4PlocTjMlUI eNUgrX/RgyNHFMLioX3cmrrtyRLiTKaR2U8aUP93EyaC1IfP4GNGDVwHAKyerswjIJXT 9IzJDjpNqQTNNTtpGl8EFaLNO14fvbqWQUnqrATRRBvei9dC0xAnwIzctbbGtDP/X95/ 9hW3xYxhsO4Q6IZUMKTMBsol8oGq9te0D2GZZpyMILB0Wnj/fQ/A1tp1mABoZumYgbR0 kQLw== X-Gm-Message-State: AHYfb5gqDUdV/RsRO9dbpxIBTKok0UtF8By9pNArYFTtfW8FrVbcrMp1 B4nF5GlykVFPCfhDs2ZUKZ2qGDPPI25+ X-Received: by 10.28.139.130 with SMTP id n124mr5724278wmd.168.1502029020029; Sun, 06 Aug 2017 07:17:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.193 with HTTP; Sun, 6 Aug 2017 07:16:59 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Sun, 6 Aug 2017 07:16:59 -0700 Message-ID: Subject: Re: 5-tuple uniquess To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1144215c2f1409055616626c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Aug 2017 14:17:04 -0000 --001a1144215c2f1409055616626c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is there particular language in the transport doc which you would like to change? For example, I believe the current document specifies that the connection id is required unless omit_connection_id is sent by the receiver during the handshake. Does this satisfy your requirement about the connection id being visible? The docs also talk about the underlying 5 tuple changing during the connection, which sounds like what you're asking for. So it would be good to have a bit more detail on what you would like to see change in the spec. Cheers, Ryan On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Have argued before as comments to various issues, but I=E2=80=99ll try on= ce more > on the list: > > Please consider making QUIC independent of the underlying transport, > including assumptions on the uniqueness of the UDP protocol. > > 1. If a http server is able to receive 100K connections, it will not be > able to forward them to the same backend service because there are not > enough ephemeral port numbers to create a reverse proxy connection per > incoming connection. > > 2. It would be fragile to port to QUIC to alternative transports because > of implied assumptions on the connectivity. For example on an I2C bus. > > 3. If a client receives its own initial connection id as a response from = a > server, even if the server has decided on a new connection id, the client > can trivially identify the connection with a simple lookup, and trivially > reject other connections. This requires that the connection id is visible > (recent discussions on encryption of cleartext might challenge this, but > the initial connection id could be part of authenticated data). > > 4. On connection migration there would need to be special considerations, > but again, handling this up front would simplify 2. > > The obvious drawback of this is the connection id must remain in clear > text which takes space and might cause some privacy concerns. Regarding > privacy, I don=E2=80=99t think it is more or less secret than a unique 5-= tuple for > an on-path interceptor. As to size, this is unfortunate. If designed > carefully, it may be possible to omit the connection id as it is today fo= r > scenarios where the 5-tuple is sufficient. For example, public network > might use 5-tuple without explicit connection id, reverse proxy might not= . > But overall, I would prefer the simplicity of always having the connectio= n > id. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --001a1144215c2f1409055616626c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there particular language in the transport doc which you woul= d like to change? For example, I believe the current document specifies tha= t the connection id is required unless=C2=A0omit_connection_id is sent by t= he receiver during the handshake. Does this satisfy your requirement about = the connection id being visible? The docs also talk about the underlying 5 = tuple changing during the connection, which sounds like what you're ask= ing for. So it would be good to have a bit more detail on what you would li= ke to see change in the spec.

Cheers,

Rya= n

On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mik= kelfj@gmail.com> wrote:
Have argued before as comments to vari= ous issues, but I=E2=80=99ll try once more on the list:

=
Please consider making QUIC independent of the underlying transport, in= cluding assumptions on the uniqueness of the UDP protocol.

1. If a http server is able to receive 100K connections, it will not= be able to forward them to the same backend service because there are not = enough ephemeral port numbers to create a reverse proxy connection per inco= ming connection.

2. It would be fragile to port to Q= UIC to alternative transports because of implied assumptions on the connect= ivity. For example on an I2C bus.

3. If a client rec= eives its own initial connection id as a response from a server, even if th= e server has decided on a new connection id, the client can trivially ident= ify the connection with a simple lookup, and trivially reject other connect= ions. This requires that the connection id is visible (recent discussions o= n encryption of cleartext might challenge this, but the initial connection = id could be part of authenticated data).

4. On conne= ction migration there would need to be special considerations, but again, h= andling this up front would simplify 2.

The obvious = drawback of this is the connection id must remain in clear text which takes= space and might cause some privacy concerns. Regarding privacy, I don=E2= =80=99t think it is more or less secret than a unique 5-tuple for an on-pat= h interceptor. As to size, this is unfortunate. If designed carefully, it m= ay be possible to omit the connection id as it is today for scenarios where= the 5-tuple is sufficient. For example, public network might use 5-tuple w= ithout explicit connection id, reverse proxy might not. But overall, I woul= d prefer the simplicity of always having the connection id.

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

<= /div>

--001a1144215c2f1409055616626c-- From nobody Sun Aug 6 07:22:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4ED132043 for ; Sun, 6 Aug 2017 07:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EBQfQvsHU2D for ; Sun, 6 Aug 2017 07:22:15 -0700 (PDT) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c: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 A9322132041 for ; Sun, 6 Aug 2017 07:22:14 -0700 (PDT) Received: by mail-vk0-x233.google.com with SMTP id u133so18717436vke.3 for ; Sun, 06 Aug 2017 07:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=mgEu5DUVlAAdUARRiY6dx82Y82qmcpHmU0WBDiSETyw=; b=lEKytNGNihyYji6gY/iKGFkeOUsa0HgGV4WQEUcOEj6kILAV17GTP/fx0aehNsAaEN YX63I+VcL4i26xYgPxKrdTkuXMmBLybL+83klEtFtGWQfx7VDxlA/w5TMa2esoZ/XGiK UVNCtP3egueRQmi1HVZInx+qq9VeS/kRR3Z5OnzMErTJduDbl2d0k5ys3PWKFCJNtRGb uylJ76hYfVjkQ3A6QqA4eKSm7njEfQQ2VFcVa5VEgwEIFsAI884igSKv1ezOJwiBlPN6 zRINXtgSvekDuLhGHRi31oawfpClfHhK4bcpowv09QEzhRXbq3JatU8fKGhQ1wXcK2er ouOA== 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=mgEu5DUVlAAdUARRiY6dx82Y82qmcpHmU0WBDiSETyw=; b=l5zDYzdKvs4vqamUJXX9VyG5gkFdKPL1O/tHlbxFMN/vTVkHk4NQT0FEbqMy1LTxbR kdEWgvAXjkcOhykAulsj/7mQlSJ0e58BpdKLYdw8ow/K16w5VA3QInEcaDVQtp9nTJkr nyXuQpISxxNBUCmdRM+E08NaWcKpv+27HsFsmR/a5yyJy9TpWUbFDWSoAkjdfIWE4fis Dsl8oJtYe8dVVjWWEYFhDFkujr7G0HaPX/ziR3I2FjWfNtkmcuz60MwKgYjXAA7YH2/7 JIBw/aKjATLsJ0Fhp2RvKAJ58cHSVbn8VMs8J6IxZtrt5k2ygZeFzuy9fQciGGlYAWYz cxZQ== X-Gm-Message-State: AHYfb5hm1tDYPfS2U7OIpRxpC7YzmGW4/6Jw2aRXUR4vEhzjA3s+Ujf3 lM2Vmb1cepiGj8lsgCk7w0H8VCU21w== X-Received: by 10.31.16.21 with SMTP id g21mr5654622vki.46.1502029333733; Sun, 06 Aug 2017 07:22:13 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 6 Aug 2017 07:22:13 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 6 Aug 2017 07:22:13 -0700 Message-ID: Subject: Re: 5-tuple uniquess To: Ryan Hamilton Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114360f8e125db055616742b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Aug 2017 14:22:17 -0000 --001a114360f8e125db055616742b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ryan, I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is: https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= version Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 August 2017 at 16.17.01, Ryan Hamilton (rch@google.com) wrote: Is there particular language in the transport doc which you would like to change? For example, I believe the current document specifies that the connection id is required unless omit_connection_id is sent by the receiver during the handshake. Does this satisfy your requirement about the connection id being visible? The docs also talk about the underlying 5 tuple changing during the connection, which sounds like what you're asking for. So it would be good to have a bit more detail on what you would like to see change in the spec. Cheers, Ryan On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Have argued before as comments to various issues, but I=E2=80=99ll try on= ce more > on the list: > > Please consider making QUIC independent of the underlying transport, > including assumptions on the uniqueness of the UDP protocol. > > 1. If a http server is able to receive 100K connections, it will not be > able to forward them to the same backend service because there are not > enough ephemeral port numbers to create a reverse proxy connection per > incoming connection. > > 2. It would be fragile to port to QUIC to alternative transports because > of implied assumptions on the connectivity. For example on an I2C bus. > > 3. If a client receives its own initial connection id as a response from = a > server, even if the server has decided on a new connection id, the client > can trivially identify the connection with a simple lookup, and trivially > reject other connections. This requires that the connection id is visible > (recent discussions on encryption of cleartext might challenge this, but > the initial connection id could be part of authenticated data). > > 4. On connection migration there would need to be special considerations, > but again, handling this up front would simplify 2. > > The obvious drawback of this is the connection id must remain in clear > text which takes space and might cause some privacy concerns. Regarding > privacy, I don=E2=80=99t think it is more or less secret than a unique 5-= tuple for > an on-path interceptor. As to size, this is unfortunate. If designed > carefully, it may be possible to omit the connection id as it is today fo= r > scenarios where the 5-tuple is sufficient. For example, public network > might use 5-tuple without explicit connection id, reverse proxy might not= . > But overall, I would prefer the simplicity of always having the connectio= n > id. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --001a114360f8e125db055616742b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Hi Ryan,

I can dig down in more detail if there is interest. Meanwhil= e, some examples where the transport document is not compatible with my req= uest is:

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


On 6 August 2017 at 16.17.01, Ryan Hamilton (rch@google.com) wrote:

Is there particular language in the transport doc which you would like to change? For example, I believe the current document specifies that the connection id is required unless=C2=A0omit_connection_id is sent by the receiver during the handshake. Does this satisfy your requirement about the connection id being visible? The docs also talk about the underlying 5 tuple changing during the connection, which sounds like what you're asking for. So it would be good to have a bit more detail on what you would like to see change in the spec.

Cheers= ,

Ryan

On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Have argued before as comments to various issues, but I=E2=80=99ll try once more on the list:

Please consider making QUIC independent of the underlying transport, including assumptions on the uniqueness of the UDP protocol.

1. If a http server is able to receive 100K connections, it will not be able to forward them to the same backend service because there are not enough ephemeral port numbers to create a reverse proxy connection per incoming connection.

2. It would be fragile to port to QUIC to alternative transports because of implied assumptions on the connectivity. For example on an I2C bus.

3. If a client receives its own initial connection id as a response from a server, even if the server has decided on a new connection id, the client can trivially identify the connection with a simple lookup, and trivially reject other connections. This requires that the connection id is visible (recent discussions on encryption of cleartext might challenge this, but the initial connection id could be part of authenticated data).

4. On connection migration there would need to be special considerations, but again, handling this up front would simplify 2.

The obvious drawback of this is the connection id must remain in clear text which takes space and might cause some privacy concerns. Regarding privacy, I don=E2=80=99t think it is more or less secret than a unique 5-tuple for an on-path interceptor. As to size, this is unfortunate. If designed carefully, it may be possible to omit the connection id as it is today for scenarios where the 5-tuple is sufficient. For example, public network might use 5-tuple without explicit connection id, reverse proxy might not. But overall, I would prefer the simplicity of always having the connection id.


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


--001a114360f8e125db055616742b-- From nobody Sun Aug 6 07:22:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14622132040 for ; Sun, 6 Aug 2017 07:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iHQJwGdNN7s for ; Sun, 6 Aug 2017 07:22:55 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 E0964131D21 for ; Sun, 6 Aug 2017 07:22:54 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id d29so22216470uai.2 for ; Sun, 06 Aug 2017 07:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=T+7nTrQTYxGhBJCPvHWBv4uTCx6SkSs++Iqrl30yejo=; b=k0jIU24sSoSij1MwVCg5X2Qv5vMZqazOckzZVNqCKRpg68zoA3VSHwrSDWZgnmHC6j FmXwYipEYDigVnedoTFky4/U3ELLmmvEm23ZQtae6LDCt7SBy5fjM788PXnBv9v/g5PW rT6egNCmpUn7Qhys5v3pI9EgZsnRlO9J5a0iyQ9cfiJE8es4lhNoPzxrLlUsALZ5UjF6 Aq06dW8I07o7jB/Er8ICFu+rwlTL3G+1rjbNUyWvjYAMkX7uwkMtQ4go0R4Wf9SenD4b e4CPfdEhK5I3+D/5J4eCx5c4LtlW6cE/0JjYvavxjI39Bx5vzP7/pEjpSp8SC+7G2wRh vF8A== 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=T+7nTrQTYxGhBJCPvHWBv4uTCx6SkSs++Iqrl30yejo=; b=CFc9fYh4pRaqnsLEcCetBfsKe5hSSEqjuFeaFVg1ME/PYG0dAoudzT4wLGmxX61Cb1 vXCBKRvgrOkIGbciI8qbe94Uo9J96fsABdm45uK02R8rgBT/3Kz8wngxCbwcN01D9BAr PcmXqQJ5JmpJLA8lju/npZN4+N6ypGD0eEIoFkFO6DnqaP3gyDpcABKGYjNtE/5ZOso8 S09aac/VIe2xWVii7YLFdmNqn30kZkNZp27+2fWteaNsnHPU8HEVkz42SqAP1tOzx2tr 2Iy3IkCOqizIueAPc6AmgmjCsS9N+ubHC0HNl1nqBviyjgeXrCx4sWRSw+3NOeAbOHE2 BycQ== X-Gm-Message-State: AIVw1130fAF0kWCvbciEULqKrM5tdkITXAGOUBCSflzjLTJckxN+Lu50 ed1CRhZBkO9DM2ijOIb+2HEPjMXoQw== X-Received: by 10.176.18.231 with SMTP id o39mr6062168uac.58.1502029374066; Sun, 06 Aug 2017 07:22:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 6 Aug 2017 07:22:53 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 6 Aug 2017 07:22:53 -0700 Message-ID: Subject: Re: 5-tuple uniquess To: Ryan Hamilton Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f4030436146c4893af0556167793" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Aug 2017 14:22:57 -0000 --f4030436146c4893af0556167793 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Mail sent prematurely, will follow up Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 August 2017 at 16.22.13, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote: Hi Ryan, I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is: https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= version Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 6 August 2017 at 16.17.01, Ryan Hamilton (rch@google.com) wrote: Is there particular language in the transport doc which you would like to change? For example, I believe the current document specifies that the connection id is required unless omit_connection_id is sent by the receiver during the handshake. Does this satisfy your requirement about the connection id being visible? The docs also talk about the underlying 5 tuple changing during the connection, which sounds like what you're asking for. So it would be good to have a bit more detail on what you would like to see change in the spec. Cheers, Ryan On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Have argued before as comments to various issues, but I=E2=80=99ll try on= ce more > on the list: > > Please consider making QUIC independent of the underlying transport, > including assumptions on the uniqueness of the UDP protocol. > > 1. If a http server is able to receive 100K connections, it will not be > able to forward them to the same backend service because there are not > enough ephemeral port numbers to create a reverse proxy connection per > incoming connection. > > 2. It would be fragile to port to QUIC to alternative transports because > of implied assumptions on the connectivity. For example on an I2C bus. > > 3. If a client receives its own initial connection id as a response from = a > server, even if the server has decided on a new connection id, the client > can trivially identify the connection with a simple lookup, and trivially > reject other connections. This requires that the connection id is visible > (recent discussions on encryption of cleartext might challenge this, but > the initial connection id could be part of authenticated data). > > 4. On connection migration there would need to be special considerations, > but again, handling this up front would simplify 2. > > The obvious drawback of this is the connection id must remain in clear > text which takes space and might cause some privacy concerns. Regarding > privacy, I don=E2=80=99t think it is more or less secret than a unique 5-= tuple for > an on-path interceptor. As to size, this is unfortunate. If designed > carefully, it may be possible to omit the connection id as it is today fo= r > scenarios where the 5-tuple is sufficient. For example, public network > might use 5-tuple without explicit connection id, reverse proxy might not= . > But overall, I would prefer the simplicity of always having the connectio= n > id. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --f4030436146c4893af0556167793 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Mail sent prematurely, will follow up

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


On 6 August 2017= at 16.22.13, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

Hi Ryan,

I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is:

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


On 6 August 2017 at 16.17.01, Ryan Hamilton (rch@google.com) wrote:

= Is there particular language in the transport doc which you would like to change? For example, I believe the current document specifies that the connection id is required unless=C2=A0omit_connection_id is sent by the receiver during the handshake. Does this satisfy your requirement about the connection id being visible? The docs also talk about the underlying 5 tuple changing during the connection, which sounds like what you're asking for. So it would be good to have a bit more detail on what you would like to see change in the spec.
=
= Cheers,
=
= Ryan
On Sun, Aug 6, 2017 at 3:18 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrot= e:
Have argued before as comments to various issues, but I=E2=80=99ll try once more on the list:

Please consider making QUIC independent of the underlying transport, including assumptions on the uniqueness of the UDP protocol.

1. If a http server is able to receive 100K connections, it will not be able to forward them to the same backend service because there are not enough ephemeral port numbers to create a reverse proxy connection per incoming connection.

2. It would be fragile to port to QUIC to alternative transports because of implied assumptions on the connectivity. For example on an I2C bus.

3. If a client receives its own initial connection id as a response from a server, even if the server has decided on a new connection id, the client can trivially identify the connection with a simple lookup, and trivially reject other connections. This requires that the connection id is visible (recent discussions on encryption of cleartext might challenge this, but the initial connection id could be part of authenticated data).

4. On connection migration there would need to be special considerations, but again, handling this up front would simplify 2.

The obvious drawback of this is the connection id must remain in clear text which takes space and might cause some privacy concerns. Regarding privacy, I don=E2=80=99t think it is more or less secret than a unique 5-tuple for an on-path interceptor. As to size, this is unfortunate. If designed carefully, it may be possible to omit the connection id as it is today for scenarios where the 5-tuple is sufficient. For example, public network might use 5-tuple without explicit connection id, reverse proxy might not. But overall, I would prefer the simplicity of always having the connection id.


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


--f4030436146c4893af0556167793-- From nobody Sun Aug 6 07:43:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28684132046 for ; Sun, 6 Aug 2017 07:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJFU1N2LgTXY for ; Sun, 6 Aug 2017 07:43:36 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 BCC2B131D33 for ; Sun, 6 Aug 2017 07:43:35 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id w45so22273201uac.5 for ; Sun, 06 Aug 2017 07:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=dj/cPtLjjjVBa6j+aR+fcoMTdJWhQa2oreYgjgblnJo=; b=Qam98xofYqjtA88rKnwb8IVw2ZIqsxqicccCAlrAdTGBkvGnbaWMCzwszrCOjSNsk0 OPEd95nJuVbI+jLPSWHhEnxfmo24BIud9GyUKZnL3Z9EZhdDJxs408ZYHCTq/VQNSy28 3uO7mVkoMMkWU0GODrKjLaE5/Ha3d32Tp/kbG/vRHLsVLflkQzSqZ4vljcWVXtCycOMv aMaQkXtGUwDpF4uYf2v+Jt1Q24oiUTis9AQeu9MYd5oWj6yefhe4MJbRcsj9e+OjL3Bj iJ4rNpUmw/lDCKkppuxqLp25wsGgNDKNTC9vBLQyDpx2macU/Sl+D9uJ10Z6GQzBM85x octA== 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=dj/cPtLjjjVBa6j+aR+fcoMTdJWhQa2oreYgjgblnJo=; b=o8nJ7iRCcC3OqSi8I+ldH0CXK9xMmruRq5Xbiszu2tSEKLWUfJx1393ova7pmXfVkB lGs2ZtF1pZDnaUnvtzTabeCQiR/9WGxyp3M8iibvf0rsmwa8w9tdnF3KhSrVtua6Tsyi Be5XnSHAk4y+lHsM7dWQHMHE6AdF4/hmiFUXw7f3L5JNRzSp2U0Vcvy/O12dgnivyxw+ Dcckm6txQTJP+aw4SKgNx8lpmVcRtqnx3axwFLQQctDrXNeEzMOkghFUrvKAqWl0OnLv 8Z8wmKK5BU0r7cytzgt28w+Bkzh7roWqHS89Xs+HB89JN48qEOH2eYuFcSgO9mQadxFi NYBQ== X-Gm-Message-State: AIVw1105q1M/joVvJu6M5pCeerq8FzC4EPlKUuZVfOPZNQXh9db6t85q n28ZF782ICTcMJlO9LoQ0Uea4lOfHP9e X-Received: by 10.176.74.71 with SMTP id r7mr5113527uae.180.1502030614730; Sun, 06 Aug 2017 07:43:34 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 6 Aug 2017 07:43:34 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 6 Aug 2017 07:43:34 -0700 Message-ID: Subject: Re: 5-tuple uniquess To: Ryan Hamilton Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045f8f0e3b9e00055616c1af" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 06 Aug 2017 14:43:38 -0000 --f403045f8f0e3b9e00055616c1af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ryan, I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is: The version negotiation packet is ok - it reflects the client version https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= version But https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= server-cleartext "The connection ID field in a Server Cleartext packet contains a connection ID that is chosen by the server (see Section 5.6 )." This breaks linkage to the original client connection id so the client cannot tell which connection the response belongs to unless looking into 5-tuple, or testing all recent connections against AEAD signature (depending on where this lands). I have not covered all other possible server responses, but similar concerns apply. It is not a major change, but currently it is not possible. Another issue is hostile response to initial connection setup, and plain errors - how to you reply with an error. Having the connection id from the client makes it reasonably easy to deal with - similar to version negotiation. Alternatively you have to rely on 5-tuples. This requires careful analysis of both the transport doc and possibly TLS and thins are not fully settled. Stateless reset is related to this. I will not argue strongly on this because since I last looked at it, new AEAD encryption is being discussed, and I have not analysed this in detail. Then there is connection migration. This also requires careful analysis. I=E2=80=99m not sure if it currently covers my request. I=E2=80=99m sure there are several other places with implicit assumptions t= hat I am not able to list off memory. The (my) basic rule is the any change in connection ID should refer to the previous ID without relying on external state such as 5-tuples or TLS extension state (which requires crypto state to access and complicates things). Also, due concerns of privacy concerns this linkage between connection ID=E2=80=99s should only be possible by peers, excepts for the i= nitial client to server connection transition that is also visible to any party on-path. In addition to the above encoding concerns, it may also be helpful to explicitly state that the same UDP port may be used to initiate multiple independent QUIC connection to the same server UDP port when connection ID has been negotiated to be present - or further detail this possibility as something that can be negotiated. Some other points I forget to mention regarding benefits of non-unique tuples: 5) no interference with OS is necessary in order to establish a new connection to an existing endpoint because no new ephemeral port is needed. This may also simplify clean up and state management, especially server to server. 6) Netmap and similar high speed interfaces would be simpler without having to deal with ephemeral port allocation, especially server to server where both end points can reference each other, and where it might be random which endpoint actually initiates to the connection (as in Cord / Kademlia style overlay networks) Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --f403045f8f0e3b9e00055616c1af Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Hi Ryan,

I can dig down= in more detail if there is interest. Meanwhile, some examples where the tr= ansport document is not compatible with my request is:

The version negotiation packet is ok - it reflects the = client version

But=C2= =A0
"The connectio= n ID field in a Server Cleartext packet contains a connection ID that is ch= osen by the server (see=C2=A0Section 5.6)."
This breaks linkage to the original client connection id so th= e client cannot tell which connection the response belongs to unless lookin= g into 5-tuple, or testing all recent connections against AEAD signature (d= epending on where this lands).

I ha= ve not covered all other possible server responses, but similar concerns ap= ply.
It is not a maj= or change, but currently it is not possible.

Another issue is hostile response to initial connection setup, an= d plain errors - how to you reply with an error. Having the connection id f= rom the client makes it reasonably easy to deal with - similar to version n= egotiation. Alternatively you have to rely on 5-tuples. This requires caref= ul analysis of both the transport doc and possibly TLS and thins are not fu= lly settled. Stateless reset is related to this. I will not argue strongly = on this because since I last looked at it, new AEAD encryption is being dis= cussed, and I have not analysed this in detail.

Then there is connection migration. This also requires careful= analysis. I=E2=80=99m not sure if it currently covers my request.

I=E2=80=99m sure there are several other pl= aces with implicit assumptions that I am not able to list off memory.
=

The (my) basic rule is the any change in= connection ID should refer to the previous ID without relying on external = state such as 5-tuples or TLS extension state (which requires crypto state = to access and complicates things). Also, due concerns of privacy concerns t= his linkage between connection ID=E2=80=99s should only be possible by peer= s, excepts for the initial client to server connection transition that is a= lso visible to any party on-path.

In addition to the above encoding concerns, it may also be helpful to expl= icitly state that the same UDP port may be used to initiate multiple indepe= ndent QUIC connection to the same server UDP port when connection ID has be= en negotiated to be present - or further detail this possibility as somethi= ng that can be negotiated.


Some other points I for= get to mention regarding benefits of non-unique tuples:

5) no interference with OS is necessary in order to es= tablish a new connection to an existing endpoint because no new ephemeral p= ort is needed. This may also simplify clean up and state management, especi= ally server to server.

6) Netmap an= d similar high speed interfaces would be simpler without having to deal wit= h ephemeral port allocation, especially server to server where both end poi= nts can reference each other, and where it might be random which endpoint a= ctually initiates to the connection (as in Cord / Kademlia style overlay ne= tworks)

<= div id=3D"bloop_sign_1502029387058855936" class=3D"bloop_sign">
Kind Regards,
Mikkel Fahn=C3=B8e J=C3= =B8rgensen


=
--f403045f8f0e3b9e00055616c1af-- From nobody Tue Aug 8 16:01:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B242A131CC2 for ; Tue, 8 Aug 2017 16:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5TLfpX2Uo5Qq for ; Tue, 8 Aug 2017 16:01:09 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07614129AD3 for ; Tue, 8 Aug 2017 16:01:08 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s143so30381282ywg.1 for ; Tue, 08 Aug 2017 16:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DDYSNitAyzlYL4dsGnHCtxFcpq8T4v8PDeTOWFyYUCI=; b=IQJKmxZH67TbELEwObDWeMLFe7xuFzQ78NMcEfx8zhan2JKSdFvuq4W7Lk2xghxbwY t+yMkBChFTeEy4YPYBqDzXZGF7fvEymD3zJ9GMh2uJ3P/XapPM89Vcu2lDusfNHzylhA BeWugcTjMx3/sLScLEomVOwozxe1FktmlhiQ7ADQpeXXCkYcbN4dfOb3V/gDTNVlO2wG bzc4bcoIvGhsFRRRogHQjgTy52aESWeutmo6dx3+x4h8B5NyD9VEUoAbHEUbHJrPJ9iK toQSkDObsosO11kQ31TpDS9k/0XMd15jJ+dG8jd77CsxthRlA0MKLNSd4TWwmU+1AOLb w4gg== 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=DDYSNitAyzlYL4dsGnHCtxFcpq8T4v8PDeTOWFyYUCI=; b=FOqMKCsBccqoJob4tfxPgAzyQmyvLEoOlUWV9/Amw9elZtk2uZRMZnyvbaTnM79KGg LEdKSiQ9oRNXhYAZM5hbjCTaEE6xrycMYxwphBFjOW8d2nZjmsU/x7nVYbCMIwccqiVx 96v/VbpnOu1qOUzzdYxH7nK06u8NAxuq4OnIJa2geF2W0FgNMJwTRcgtm28WQvRKVgWZ 4k2Foo4iFDmQ2OJdDy3S0zBbV6ri5NDvV+Ap82w+lM9HrV//WPgM906mFVmYtsh4HTrc EyOd45TATMGR+5B/iZngA7R6TFGHB7SQNe+bF7QLxeqssgaK6CHdMFEvK+UbRyS3DTF/ HR6Q== X-Gm-Message-State: AHYfb5iCBZfDx6yUPwCx/Buw6gk4DOiKa3eS5rFZ25nSEctj+0BHFhE0 KNxgTUIHapJep/NqCAAeXO+mHVfxKja4 X-Received: by 10.37.65.201 with SMTP id o192mr4647470yba.264.1502233268013; Tue, 08 Aug 2017 16:01:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Tue, 8 Aug 2017 16:00:47 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Tue, 8 Aug 2017 19:00:47 -0400 Message-ID: Subject: Re: 5-tuple uniquess To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Ryan Hamilton , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c02d204fb496055645f091" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 08 Aug 2017 23:01:12 -0000 --001a11c02d204fb496055645f091 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You're right, ephemeral port exhaustion is a very real potential issue, and I think we should ensure multiple QUIC connections can run over the same 5-tuple and we don't specify QUIC in a way that precludes that. I believe you're correct that the current Server Cleartext makes this impossible if the server changes the connection ID. Possibly it should specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters? https://github.com/quicwg/base-drafts/issues/714 The text is also missing some details on how changing the connection ID should work for Stateless Retry, see https://github.com/quicwg/ base-drafts/issues/713, so I'd expect some improvements in the near future. On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > Hi Ryan, > > I can dig down in more detail if there is interest. Meanwhile, some > examples where the transport document is not compatible with my request i= s: > > The version negotiation packet is ok - it reflects the client version > https://quicwg.github.io/base-drafts/draft-ietf-quic-transpo > rt.html#packet-version > > But > https://quicwg.github.io/base-drafts/draft-ietf-quic-transpo > rt.html#packet-server-cleartext > "The connection ID field in a Server Cleartext packet contains a > connection ID that is chosen by the server (see Section 5.6 > > )." > This breaks linkage to the original client connection id so the client > cannot tell which connection the response belongs to unless looking into > 5-tuple, or testing all recent connections against AEAD signature > (depending on where this lands). > > I have not covered all other possible server responses, but similar > concerns apply. > It is not a major change, but currently it is not possible. > > Another issue is hostile response to initial connection setup, and plain > errors - how to you reply with an error. Having the connection id from th= e > client makes it reasonably easy to deal with - similar to version > negotiation. Alternatively you have to rely on 5-tuples. This requires > careful analysis of both the transport doc and possibly TLS and thins are > not fully settled. Stateless reset is related to this. I will not argue > strongly on this because since I last looked at it, new AEAD encryption i= s > being discussed, and I have not analysed this in detail. > > Then there is connection migration. This also requires careful analysis. > I=E2=80=99m not sure if it currently covers my request. > > I=E2=80=99m sure there are several other places with implicit assumptions= that I > am not able to list off memory. > > The (my) basic rule is the any change in connection ID should refer to th= e > previous ID without relying on external state such as 5-tuples or TLS > extension state (which requires crypto state to access and complicates > things). Also, due concerns of privacy concerns this linkage between > connection ID=E2=80=99s should only be possible by peers, excepts for the= initial > client to server connection transition that is also visible to any party > on-path. > > In addition to the above encoding concerns, it may also be helpful to > explicitly state that the same UDP port may be used to initiate multiple > independent QUIC connection to the same server UDP port when connection I= D > has been negotiated to be present - or further detail this possibility as > something that can be negotiated. > > > Some other points I forget to mention regarding benefits of non-unique > tuples: > > 5) no interference with OS is necessary in order to establish a new > connection to an existing endpoint because no new ephemeral port is neede= d. > This may also simplify clean up and state management, especially server t= o > server. > > 6) Netmap and similar high speed interfaces would be simpler without > having to deal with ephemeral port allocation, especially server to serve= r > where both end points can reference each other, and where it might be > random which endpoint actually initiates to the connection (as in Cord / > Kademlia style overlay networks) > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > --001a11c02d204fb496055645f091 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You&= #39;re right, ephemeral port exhaustion is a very real potential issue, and= I think we should ensure multiple QUIC connections can run over the same 5= -tuple and we don't specify QUIC in a way that precludes that.

I believe you&= #39;re correct that the current Server Cleartext makes this impossible if t= he server changes the connection ID.=C2=A0 Possibly it should specify the c= lient's connection ID in the packet header and then the new server conn= ection ID in the transport parameters?=C2=A0 https://github.com/quicwg/base-drafts/issues= /714

The text is also missing some details on how changing the connection ID = should work for Stateless Retry, see=C2=A0https://github.com/quicwg/base-drafts/issues/713, so I'd expect some improvements in the ne= ar future.

On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

Hi Ryan,
<= br>
I can dig down = in more detail if there is interest. Meanwhile, some examples where the tra= nsport document is not compatible with my request is:

The version negotiation packet is ok - it refle= cts the client version
https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-version

But=C2=A0
"The connection I= D field in a Server Cleartext packet contains a connection ID that is chose= n by the server (see=C2=A0Section 5.6)."
This breaks linkage to the original client= connection id so the client cannot tell which connection the response belo= ngs to unless looking into 5-tuple, or testing all recent connections again= st AEAD signature (depending on where this lands).

I have not covered all other possible server responses, b= ut similar concerns apply.
It is not a major change, but currently it is not possible.

Another issue is hostile response to ini= tial connection setup, and plain errors - how to you reply with an error. H= aving the connection id from the client makes it reasonably easy to deal wi= th - similar to version negotiation. Alternatively you have to rely on 5-tu= ples. This requires careful analysis of both the transport doc and possibly= TLS and thins are not fully settled. Stateless reset is related to this. I= will not argue strongly on this because since I last looked at it, new AEA= D encryption is being discussed, and I have not analysed this in detail.

Then there is connection migration.= This also requires careful analysis. I=E2=80=99m not sure if it currently = covers my request.
=
I=E2=80=99m su= re there are several other places with implicit assumptions that I am not a= ble to list off memory.

The (my) = basic rule is the any change in connection ID should refer to the previous = ID without relying on external state such as 5-tuples or TLS extension stat= e (which requires crypto state to access and complicates things). Also, due= concerns of privacy concerns this linkage between connection ID=E2=80=99s = should only be possible by peers, excepts for the initial client to server = connection transition that is also visible to any party on-path.

In addition to the above encoding concerns,= it may also be helpful to explicitly state that the same UDP port may be u= sed to initiate multiple independent QUIC connection to the same server UDP= port when connection ID has been negotiated to be present - or further det= ail this possibility as something that can be negotiated.


Some other points I forget to mention regarding benefits of non-= unique tuples:

=
5) no interference= with OS is necessary in order to establish a new connection to an existing= endpoint because no new ephemeral port is needed. This may also simplify c= lean up and state management, especially server to server.

6) Netmap and similar high speed interfaces would= be simpler without having to deal with ephemeral port allocation, especial= ly server to server where both end points can reference each other, and whe= re it might be random which endpoint actually initiates to the connection (= as in Cord / Kademlia style overlay networks)

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

<= blockquote type=3D"cite" class=3D"gmail-m_6800695222863924869gmail-m_-86555= 34309817292564m_3714927623720422036clean_bq">


--001a11c02d204fb496055645f091-- From nobody Tue Aug 8 17:45:34 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448A1131CE7 for ; Tue, 8 Aug 2017 17:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, 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=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 pjph47I-bMZH for ; Tue, 8 Aug 2017 17:45:23 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DCDC120720 for ; Tue, 8 Aug 2017 17:45:18 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m34so12066238iti.1 for ; Tue, 08 Aug 2017 17:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0920dwr9hDKMSCYDPzCd2gt4HYR+dZwYds5574yGNyo=; b=cMuolHsyvTEcPQRCLO9mpDmUkq5qQpYi9N63+9t6Lcz4sPglanOPb94+AjnjYexuer qHEwtv689goyL4jf6EBA+eltOnfhKjMVUxKwulfsB1zN8mHafPxBkAaQuuc+BbETD4zd AqduFmFcEx3jKS2+KeTyLHXr+SbrJscjNfSruRA2oTxOIYV12jt1q58VcIZ9cFXEmmjx hBIUAGoDh4jqqpJ2sEASUp0AwSRiNWnSH8UvzG2Wtcr+f9Mf0LQW1LjL+Vq1FA7+mDl+ RXx4v3tfg1BuYQsuEPo1UXzAv1Z00uEpOqX0BoD5aqDSaUTPpEO2SkzHDpuzDkkAQ5Dw SIcw== 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=0920dwr9hDKMSCYDPzCd2gt4HYR+dZwYds5574yGNyo=; b=rwZDXxNP9dFwDdKjyPUPU0fe6ft2CBMKUomtYYF/BwZ3M+FLnlsN9UDColdXF7AdZ+ 7d6es4gNMpyxdDEKJsSkQ81AM40gq1EBtN4wLUEBLbi/vnq1dcCSW0ykMnkv5G7ICt8a a4wD5uhtydUJrzdYvjAJC02N9i9tXy3ClrbJ9r7fD/mgh2aBWBuFtwnWMY4YmEmuxmm0 UT3afIaWWvN1VkOaOyTL3Bo7iHMiZgmexJIvidDp+hcjoKbqkcwYkSKnJrwUv0ze8Qvh rUywLfKER8aka9jApdkQJUIv+qoRUoSk6IZHMHUUaTy3l5IuoxxS1PCjuc/W1uHmtOT6 nokA== X-Gm-Message-State: AHYfb5jq85vE8YzHTWRpgwqQepH9ucbEKGjAXOdsmpDxA4MPLSL/TSTv noLnVV5mFeKim9wV76BbzIjcS6MPSQ== X-Received: by 10.36.156.6 with SMTP id b6mr6120015ite.51.1502239517984; Tue, 08 Aug 2017 17:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 8 Aug 2017 17:45:17 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 9 Aug 2017 10:45:17 +1000 Message-ID: Subject: Re: Push ID - Merge Imminent To: Jana Iyengar Cc: Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" , Mike Bishop Content-Type: multipart/alternative; boundary="94eb2c08da52d64caa0556476495" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Aug 2017 00:45:26 -0000 --94eb2c08da52d64caa0556476495 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to follow up on this, I've opened https://github.com/quicwg/ base-drafts/pull/711 It defines a new frame type that sets the limit to Push ID. In a fit of inspiration, I called it MAX_PUSH_ID. I have repurposed SETTINGS_ENABLE_PUSH for setting the initial limit. The newly renamed SETTINGS_MAX_PUSH_ID sets the initial MAX_PUSH_ID. I want to discuss whether we might remove the setting. Sending MAX_PUSH_ID immediately after SETTINGS doesn't add any more bytes and I'm not sure that there is any particular need to optimize for HoLB here. I'm ambivalent, so I kept it, but it is easy to remove. On 5 August 2017 at 10:55, Jana Iyengar wrote: > Martin, > > I think the idea of sequential Push ID is a good one. You have to specify > a MAX_PUSH_ID, without which the client won't know how far out to expect > CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE > message which can be used to move the MAX up. > > One note: > > >> PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the >>>>> server. The text currently says that CANCEL_PUSH on a non-existent Pu= sh ID >>>>> results in error, which does not work with the possibility of reorder= ing >>>>> between PUSH_PROMISE and CANCEL_PUSH. >>>>> >>>> >>>> That's just a bug. >>>> >>> > I don't think so. The spec allows it, and I can easily see it happen in > practice. > > - jana > > >> >>>> >>>>> Similarly, it's also possible for the PUSH_PROMISE to not have been >>>>> received because the stream on which it was sent was reset... basical= ly >>>>> it's possible for a client to receive a CANCEL_PUSH without seeing th= e >>>>> corresponding PUSH_PROMISE. >>>>> >>>> >>>> This is more interesting. It creates state on the client: it says >>>> that clients are required to ignore pushes that it *might* receive in = the >>>> future. That suggests a different fix, akin to what we use for other >>>> similar pieces of state: >>>> >>>> 1. make Push ID sequential (right now the only requirement is for >>>> connection-wide uniqueness) >>>> >>> >>> I think that using a sequential ID will be a good idea not only for >>> fixing this issue but that it might be possible to use the sequentialit= y to >>> fix the first issue raised in the PR (i.e. client knowing "when the ser= ver >>> will stop referencing a push ID in PUSH_PROMISE"). >>> >>> If there is a sequential ordering guarantee for Push ID, a client can, >>> by looking at the Push ID, determine whether if it has already consumed= the >>> pushed request. If it has, it will immediately lookup its cache, and in >>> case it fails to find a cached object, then issue a pull. If it has not >>> consumed the pushed request, it should wait for the pushed response to >>> arrive. >>> >>> >>> >>>> >>>> 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a ne= w >>>> frame type; the setting might {ab|re}use ENABLE_PUSH) >>>> >>>> This would bound state for clients. A client couldn't receive an >>>> arbitrary number of CANCEL_PUSH messages that are distributed over the >>>> 32-bit Push ID space, so tracking cancellations is easy. Clients coul= d use >>>> a simple bitvector to track which pushes are potentially interesting, >>>> clearing bits as pushes or cancellations arrive. >>>> >>>> MAX_PUSH_ID would give clients a finer-grained lever to control push. >>>> >>>> We could have CANCEL_PUSH be sent on the same streams as the >>>>> PUSH_PROMISE, but that doesn't help with the case where the PUSH_PROM= ISE >>>>> may not have been received due to a stream reset. >>>>> >>>>> This makes me wonder if it makes sense to always send the PUSH_PROMIS= E >>>>> on the control stream *in addition to* any stream that it is sent on.= This >>>>> would ensure that no matter what, the PUSH_PROMISE is always received= , and >>>>> additionally ensures that CANCEL_PUSH is received after a PUSH_PROMIS= E. >>>>> >>>> >>>> I don't think that is a good idea. PUSH_PROMISE includes a headers >>>> block, which is pretty big, even with effective compression. HoLB won= 't >>>> affect this stream, so size shouldn't be an issue, but still. >>>> >>>> I did consider moving the header block to the control stream completel= y >>>> as part of addressing the issue with duplication that I mentioned earl= ier. >>>> The basic problem there is that you don't guarantee that the client se= e the >>>> PUSH_PROMISE before it processes the response content. >>>> >>>> >>>>> >>>>> - jana >>>>> >>>>> On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop < >>>>> Michael.Bishop@microsoft.com> wrote: >>>>> >>>>>> Bah, QUIC too. =F0=9F=98=8A >>>>>> >>>>>> >>>>>> >>>>>> *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] >>>>>> *Sent:* Thursday, August 3, 2017 10:36 AM >>>>>> *To:* ietf-http-wg@w3.org >>>>>> *Subject:* Push ID - Merge Imminent >>>>>> >>>>>> >>>>>> >>>>>> This is Martin=E2=80=99s Push ID PR split off from unidirectional. = Given >>>>>> that it has already been picked over in those contexts and the feedb= ack >>>>>> from that and in-person discussion was to bring this change in separ= ately, >>>>>> I=E2=80=99m about ready to merge this. Everything anyone has quibbl= ed with has >>>>>> been editorial. However, I don=E2=80=99t see reviews from many folk= s, so I want to >>>>>> make sure that everyone interested has had a chance to express an op= inion. >>>>>> >>>>>> >>>>>> >>>>>> https://github.com/quicwg/base-drafts/pull/701 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at le= ast a little bit >>>>>> of a work day), then merge unless I hear otherwise. >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Kazuho Oku >>> >> >> > --94eb2c08da52d64caa0556476495 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to follow up on this, I've opened https://= github.com/quicwg/base-drafts/pull/711

It= defines a new frame type that sets the limit to Push ID.=C2=A0 In a fit of= inspiration, I called it MAX_PUSH_ID.

I have repu= rposed SETTINGS_ENABLE_PUSH for setting the initial limit.=C2=A0 The newly = renamed SETTINGS_MAX_PUSH_ID sets the initial MAX_PUSH_ID.

I want to discuss whether we might remove the setting.=C2=A0 Sendi= ng MAX_PUSH_ID immediately after SETTINGS doesn't add any more bytes an= d I'm not sure that there is any particular need to optimize for HoLB h= ere.=C2=A0 I'm ambivalent, so I kept it, but it is easy to remove.
<= /div>


On 5 August 2017 at 10:55, Jana Iyengar <jri@google.com> wrote:
Martin,

I think the idea of sequential Pu= sh ID is a good one. You have to specify a MAX_PUSH_ID, without which the c= lient won't know how far out to expect CANCEL_PUSHes can be... this als= o requires then a MAX_PUSH_ID_UPDATE message which can be used to move the = MAX up.

One note:
=C2= =A0
PUSH_PROMISE is sent by the server, an= d CANCEL_PUSH may be sent by the server. The text currently says that CANCE= L_PUSH on a non-existent Push ID results in error, which does not work with= the possibility of reordering between PUSH_PROMISE and CANCEL_PUSH.
=

That's just a bug.
<= /div>
<= /div>

I don't think = so. The spec allows it, and I can easily see it happen in practice.

- jana
=C2=A0
= =C2=A0
Similarly, it's also possible for the PUSH_PROMISE = to not have been received because the stream on which it was sent was reset= ... basically it's possible for a client to receive a CANCEL_PUSH witho= ut seeing the corresponding PUSH_PROMISE.

=
This is more interesting.=C2=A0 It creates state on the c= lient:=C2=A0 it says that clients are required to ignore pushes that it *mi= ght* receive in the future.=C2=A0 That suggests a different fix, akin to wh= at we use for other similar pieces of state:

1. ma= ke Push ID sequential (right now the only requirement is for connection-wid= e uniqueness)

I think that using a sequential ID will be a good idea not only for fixin= g this issue but that it might be possible to use the sequentiality to fix = the first issue raised in the PR (i.e. client knowing "when the server= will stop referencing a push ID in PUSH_PROMISE").

If there is a sequential ordering guarantee for Push ID, a client ca= n, by looking at the Push ID, determine whether if it has already consumed = the pushed request. If it has, it will immediately lookup its cache, and in= case it fails to find a cached object, then issue a pull. If it has not co= nsumed the pushed request, it should wait for the pushed response to arrive= .

=C2=A0

2. have the client advertise a MAX_= PUSH_ID (in SETTINGS, and with a new frame type; the setting might {ab|re}u= se ENABLE_PUSH)

This would bound state for clients.=C2= =A0 A client couldn't receive an arbitrary number of CANCEL_PUSH messag= es that are distributed over the 32-bit Push ID space, so tracking cancella= tions is easy.=C2=A0 Clients could use a simple bitvector to track which pu= shes are potentially interesting, clearing bits as pushes or cancellations = arrive.

MAX_PUSH_ID would give clients a finer-grained lever to control push.
=

<= div>We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMI= SE, but that doesn't help with the case where the PUSH_PROMISE may not = have been received due to a stream reset.

This mak= es me wonder if it makes sense to always send the PUSH_PROMISE on the contr= ol stream *in addition to* any stream that it is sent on. This would ensure= that no matter what, the PUSH_PROMISE is always received, and additionally= ensures that CANCEL_PUSH is received after a PUSH_PROMISE.

I don't think that is a good idea.= =C2=A0 PUSH_PROMISE includes a headers block, which is pretty big, even wit= h effective compression.=C2=A0 HoLB won't affect this stream, so size s= houldn't be an issue, but still.

I did con= sider moving the header block to the control stream completely as part of a= ddressing the issue with duplication that I mentioned earlier.=C2=A0 The ba= sic problem there is that you don't guarantee that the client see the P= USH_PROMISE before it processes the response content.
=
=C2=A0

- jana
On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98=8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring thi= s change in separately, I=E2=80=99m about ready to merge this.=C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 = However, I don=E2=80=99t see reviews from many folks, so I want to make sur= e that everyone interested has had a chance to express an opinion.

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.






--
Kazuho Oku


--94eb2c08da52d64caa0556476495-- From nobody Wed Aug 9 09:15:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D9D132411 for ; Wed, 9 Aug 2017 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LETCD-E-niJ for ; Wed, 9 Aug 2017 09:15:27 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0104.outbound.protection.outlook.com [104.47.36.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42839131CEA for ; Wed, 9 Aug 2017 09:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kwpml1H7q5LxSb5yvQ+DlBVQbwnpR4So9Z4nAxn2X7w=; b=KvPolslcAek6R8bXuD8TJU6fjerRhgIqvcSyg3OtCxcId88pELrGqA6EuEHxPB0CaeiyUOsgHRiSnJtpZfTpMr5PVM9HZca5kCzRikMtDzzq526Wje1ahognpdGYSvw7hbExkrhKJWAV/Mr0x4V6ZhvUFqskab6nA0XOr+/+pbg= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0128.namprd21.prod.outlook.com (10.173.52.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.6; Wed, 9 Aug 2017 16:15:25 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1362.003; Wed, 9 Aug 2017 16:15:25 +0000 From: Mike Bishop To: Martin Thomson , Jana Iyengar CC: Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Subject: RE: Push ID - Merge Imminent Thread-Topic: Push ID - Merge Imminent Thread-Index: AdMMflQP7j6uNR+PS2KfJ40m2cnztgAAnzZAAA4Q9AAAAj3YgAALWUcAAA344AAAF4xqAADIz6uAACBaDlA= Date: Wed, 9 Aug 2017 16:15:24 +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: [73.140.154.179] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0128; 6:984TnZut7Y0X8ObBHtMVm4lxN9ASkfdQsNlE/IlCjl3CVcVlA8wODW0VXvOV0NLQO9a5OO9ZBlNKCRX2AS+ERrzRK/EJyhj2AN2KfZthiTapxjKWmgiMGzjQmz10LuAuHQUVNxyl7oyA4Gr/fwdl/aTrscmTN8kUEUo8TkAc89NDE9ANiHXG4hG0EJ2Vq9ksU2PeCycE1F2ftL18TxRv5nTWXnoUMenAHp0W8g460Wci9uRsSiDWedROV2AhSOJ/VqpjFUbSRogHOfzKGwdra/IAKoM+w2DlK7BeybMsFivCLPt3zhaHgcK0zL09IhRE2t/7W1HVuBK2/JuqitEglw==; 5:ep5OiPh4McO9s/GXCrk5Huz832VwW/qYOJwAb0I85PhfRrdzqmhtRZ/TRVe2QXlvgmKYk+OPf1ynW1Y1de2/QGSzKuGiPoAYiPQtxdz84ks18I0qeduwe7CVJCoYYRTxUV44odLiN2YNkf5jXiNRHA==; 24:SkKwnC5FKueLkAohXFEXvRdonpUv5kMcXOIKWNR0bbZtiSOSqBSsBhc40pxyElSdXS45Vg6PAGApZHGx8Ib2hipjOCcUC+k0P3/chG1ZQCQ=; 7:AXJj3Y8w//3TdeNx+O5wuRiPoiyiiKAaW0C84AgCaOJDQFDmKlnybzcXTZ8MtK17z0YTnWsKEJAu8+9nHqdavrTvcz3+szufvSRjqfRX8w0O30r3pZj41qwZIUXtveSZFGbwAkVjSsyVPwVcFCM6EdrEb7AYA3e5Kk4jpDrlvC796iaT6MHtjKvToOkPBBCNJuTGTUw2WdHYazfAgvce0HtBmQcLYZYt2/7NyjN8p1E= x-ms-office365-filtering-correlation-id: b0156f37-3640-410a-7128-08d4df41d802 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603124)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0128; x-ms-traffictypediagnostic: MWHPR21MB0128: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(166708455590820)(189930954265078)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0128; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0128; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400002)(39860400002)(39400400002)(39410400002)(39840400002)(39450400003)(47760400005)(24454002)(51444003)(189002)(31014005)(377454003)(199003)(236005)(6246003)(14454004)(2906002)(72206003)(33656002)(8936002)(53936002)(77096006)(68736007)(39060400002)(7696004)(74316002)(53546010)(25786009)(4326008)(606006)(86362001)(105586002)(34040400001)(19609705001)(3660700001)(86612001)(38730400002)(3280700002)(93886004)(966005)(106356001)(8676002)(9686003)(81156014)(81166006)(50986999)(10290500003)(189998001)(790700001)(6116002)(102836003)(3846002)(54906002)(76176999)(54896002)(54356999)(5005710100001)(6306002)(55016002)(2950100002)(99286003)(5660300001)(101416001)(97736004)(2900100001)(478600001)(6436002)(6506006)(66066001)(10090500001)(8990500004)(229853002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0128; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141633E01A781007F3A53FC878B0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 16:15:25.4895 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0128 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Aug 2017 16:15:30 -0000 --_000_MWHPR21MB0141633E01A781007F3A53FC878B0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkIHRoYXQgdGhlIFNFVFRJTkdTIGVudHJ5IGFuZCB0aGUgZnJhbWUgYXJlIHRoZSBzYW1l IDUtOCBieXRlcyBjb25zdW1lZCwgYW5kIGl0IHdvdWxkIGJlIHNpbXBsZXIgdG8gaGF2ZSBhIHNp bmdsZSBjb2RlIHBhdGguICBTaW5jZSB0aGlzIHdob2xlIHRoaW5nIGlzIGEgZGVwYXJ0dXJlIGZy b20gSFRUUC8yLCBJ4oCZbSBub3QgcGVyc29uYWxseSB1cHNldCBhYm91dCBkaXZlcmdpbmcgYSBs aXR0bGUgZnVydGhlciBpbiB0aGUgbmFtZSBvZiBzaW1wbGVyIGNvZGUuICBUaGlzIGlzbuKAmXQg YSB2YWx1ZSB0aGF0IGVpdGhlciBwYXJ0eSBuZWVkcyB0byBrbm93IGJlZm9yZSBzZW5kaW5nIHRy YWZmaWMgdG8gYmVoYXZlIHByb3Blcmx5LCB3aGljaCBpcyB0aGUgY2FzZSB3aXRoIFFVSUPigJlz IGxpbWl0cyBvZiB0aGlzIHR5cGUgdGhhdCBoYXZlIHRoZSBkdWFsIHBhcmFtZXRlci9mcmFtZSBz dHJ1Y3R1cmUuDQoNCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25A Z21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgQXVndXN0IDgsIDIwMTcgNTo0NSBQTQ0KVG86IEph bmEgSXllbmdhciA8anJpQGdvb2dsZS5jb20+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29n bGUuY29tPjsgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdtYWlsLmNvbT47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+OyBpZXRmLWh0dHAtd2dAdzMub3JnOyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFJlOiBQdXNoIElEIC0gTWVyZ2UgSW1taW5lbnQN Cg0KSnVzdCB0byBmb2xsb3cgdXAgb24gdGhpcywgSSd2ZSBvcGVuZWQgaHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzcxMTxodHRwczovL25hMDEuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWlj d2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY3MTEmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNo b3AlNDBtaWNyb3NvZnQuY29tJTdDZTc5ZmY4OTRlNTMxNDdlNzIwYjIwOGQ0ZGViZmU4ODAlN0M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2Mzc4MzYzMjA5NDI3 MzM1JnNkYXRhPTRMbiUyRnU4QUlXTFRwbktkRUR5c01DNkQ2TFdobGVjMGowSVNGQ2pPV0h1byUz RCZyZXNlcnZlZD0wPg0KDQpJdCBkZWZpbmVzIGEgbmV3IGZyYW1lIHR5cGUgdGhhdCBzZXRzIHRo ZSBsaW1pdCB0byBQdXNoIElELiAgSW4gYSBmaXQgb2YgaW5zcGlyYXRpb24sIEkgY2FsbGVkIGl0 IE1BWF9QVVNIX0lELg0KDQpJIGhhdmUgcmVwdXJwb3NlZCBTRVRUSU5HU19FTkFCTEVfUFVTSCBm b3Igc2V0dGluZyB0aGUgaW5pdGlhbCBsaW1pdC4gIFRoZSBuZXdseSByZW5hbWVkIFNFVFRJTkdT X01BWF9QVVNIX0lEIHNldHMgdGhlIGluaXRpYWwgTUFYX1BVU0hfSUQuDQoNCkkgd2FudCB0byBk aXNjdXNzIHdoZXRoZXIgd2UgbWlnaHQgcmVtb3ZlIHRoZSBzZXR0aW5nLiAgU2VuZGluZyBNQVhf UFVTSF9JRCBpbW1lZGlhdGVseSBhZnRlciBTRVRUSU5HUyBkb2Vzbid0IGFkZCBhbnkgbW9yZSBi eXRlcyBhbmQgSSdtIG5vdCBzdXJlIHRoYXQgdGhlcmUgaXMgYW55IHBhcnRpY3VsYXIgbmVlZCB0 byBvcHRpbWl6ZSBmb3IgSG9MQiBoZXJlLiAgSSdtIGFtYml2YWxlbnQsIHNvIEkga2VwdCBpdCwg YnV0IGl0IGlzIGVhc3kgdG8gcmVtb3ZlLg0KDQoNCk9uIDUgQXVndXN0IDIwMTcgYXQgMTA6NTUs IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4gd3Jv dGU6DQpNYXJ0aW4sDQoNCkkgdGhpbmsgdGhlIGlkZWEgb2Ygc2VxdWVudGlhbCBQdXNoIElEIGlz IGEgZ29vZCBvbmUuIFlvdSBoYXZlIHRvIHNwZWNpZnkgYSBNQVhfUFVTSF9JRCwgd2l0aG91dCB3 aGljaCB0aGUgY2xpZW50IHdvbid0IGtub3cgaG93IGZhciBvdXQgdG8gZXhwZWN0IENBTkNFTF9Q VVNIZXMgY2FuIGJlLi4uIHRoaXMgYWxzbyByZXF1aXJlcyB0aGVuIGEgTUFYX1BVU0hfSURfVVBE QVRFIG1lc3NhZ2Ugd2hpY2ggY2FuIGJlIHVzZWQgdG8gbW92ZSB0aGUgTUFYIHVwLg0KDQpPbmUg bm90ZToNCg0KUFVTSF9QUk9NSVNFIGlzIHNlbnQgYnkgdGhlIHNlcnZlciwgYW5kIENBTkNFTF9Q VVNIIG1heSBiZSBzZW50IGJ5IHRoZSBzZXJ2ZXIuIFRoZSB0ZXh0IGN1cnJlbnRseSBzYXlzIHRo YXQgQ0FOQ0VMX1BVU0ggb24gYSBub24tZXhpc3RlbnQgUHVzaCBJRCByZXN1bHRzIGluIGVycm9y LCB3aGljaCBkb2VzIG5vdCB3b3JrIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIHJlb3JkZXJpbmcg YmV0d2VlbiBQVVNIX1BST01JU0UgYW5kIENBTkNFTF9QVVNILg0KDQpUaGF0J3MganVzdCBhIGJ1 Zy4NCg0KSSBkb24ndCB0aGluayBzby4gVGhlIHNwZWMgYWxsb3dzIGl0LCBhbmQgSSBjYW4gZWFz aWx5IHNlZSBpdCBoYXBwZW4gaW4gcHJhY3RpY2UuDQoNCi0gamFuYQ0KDQoNClNpbWlsYXJseSwg aXQncyBhbHNvIHBvc3NpYmxlIGZvciB0aGUgUFVTSF9QUk9NSVNFIHRvIG5vdCBoYXZlIGJlZW4g cmVjZWl2ZWQgYmVjYXVzZSB0aGUgc3RyZWFtIG9uIHdoaWNoIGl0IHdhcyBzZW50IHdhcyByZXNl dC4uLiBiYXNpY2FsbHkgaXQncyBwb3NzaWJsZSBmb3IgYSBjbGllbnQgdG8gcmVjZWl2ZSBhIENB TkNFTF9QVVNIIHdpdGhvdXQgc2VlaW5nIHRoZSBjb3JyZXNwb25kaW5nIFBVU0hfUFJPTUlTRS4N Cg0KVGhpcyBpcyBtb3JlIGludGVyZXN0aW5nLiAgSXQgY3JlYXRlcyBzdGF0ZSBvbiB0aGUgY2xp ZW50OiAgaXQgc2F5cyB0aGF0IGNsaWVudHMgYXJlIHJlcXVpcmVkIHRvIGlnbm9yZSBwdXNoZXMg dGhhdCBpdCAqbWlnaHQqIHJlY2VpdmUgaW4gdGhlIGZ1dHVyZS4gIFRoYXQgc3VnZ2VzdHMgYSBk aWZmZXJlbnQgZml4LCBha2luIHRvIHdoYXQgd2UgdXNlIGZvciBvdGhlciBzaW1pbGFyIHBpZWNl cyBvZiBzdGF0ZToNCg0KMS4gbWFrZSBQdXNoIElEIHNlcXVlbnRpYWwgKHJpZ2h0IG5vdyB0aGUg b25seSByZXF1aXJlbWVudCBpcyBmb3IgY29ubmVjdGlvbi13aWRlIHVuaXF1ZW5lc3MpDQoNCkkg dGhpbmsgdGhhdCB1c2luZyBhIHNlcXVlbnRpYWwgSUQgd2lsbCBiZSBhIGdvb2QgaWRlYSBub3Qg b25seSBmb3IgZml4aW5nIHRoaXMgaXNzdWUgYnV0IHRoYXQgaXQgbWlnaHQgYmUgcG9zc2libGUg dG8gdXNlIHRoZSBzZXF1ZW50aWFsaXR5IHRvIGZpeCB0aGUgZmlyc3QgaXNzdWUgcmFpc2VkIGlu IHRoZSBQUiAoaS5lLiBjbGllbnQga25vd2luZyAid2hlbiB0aGUgc2VydmVyIHdpbGwgc3RvcCBy ZWZlcmVuY2luZyBhIHB1c2ggSUQgaW4gUFVTSF9QUk9NSVNFIikuDQoNCklmIHRoZXJlIGlzIGEg c2VxdWVudGlhbCBvcmRlcmluZyBndWFyYW50ZWUgZm9yIFB1c2ggSUQsIGEgY2xpZW50IGNhbiwg YnkgbG9va2luZyBhdCB0aGUgUHVzaCBJRCwgZGV0ZXJtaW5lIHdoZXRoZXIgaWYgaXQgaGFzIGFs cmVhZHkgY29uc3VtZWQgdGhlIHB1c2hlZCByZXF1ZXN0LiBJZiBpdCBoYXMsIGl0IHdpbGwgaW1t ZWRpYXRlbHkgbG9va3VwIGl0cyBjYWNoZSwgYW5kIGluIGNhc2UgaXQgZmFpbHMgdG8gZmluZCBh IGNhY2hlZCBvYmplY3QsIHRoZW4gaXNzdWUgYSBwdWxsLiBJZiBpdCBoYXMgbm90IGNvbnN1bWVk IHRoZSBwdXNoZWQgcmVxdWVzdCwgaXQgc2hvdWxkIHdhaXQgZm9yIHRoZSBwdXNoZWQgcmVzcG9u c2UgdG8gYXJyaXZlLg0KDQoNCg0KMi4gaGF2ZSB0aGUgY2xpZW50IGFkdmVydGlzZSBhIE1BWF9Q VVNIX0lEIChpbiBTRVRUSU5HUywgYW5kIHdpdGggYSBuZXcgZnJhbWUgdHlwZTsgdGhlIHNldHRp bmcgbWlnaHQge2FifHJlfXVzZSBFTkFCTEVfUFVTSCkNCg0KVGhpcyB3b3VsZCBib3VuZCBzdGF0 ZSBmb3IgY2xpZW50cy4gIEEgY2xpZW50IGNvdWxkbid0IHJlY2VpdmUgYW4gYXJiaXRyYXJ5IG51 bWJlciBvZiBDQU5DRUxfUFVTSCBtZXNzYWdlcyB0aGF0IGFyZSBkaXN0cmlidXRlZCBvdmVyIHRo ZSAzMi1iaXQgUHVzaCBJRCBzcGFjZSwgc28gdHJhY2tpbmcgY2FuY2VsbGF0aW9ucyBpcyBlYXN5 LiAgQ2xpZW50cyBjb3VsZCB1c2UgYSBzaW1wbGUgYml0dmVjdG9yIHRvIHRyYWNrIHdoaWNoIHB1 c2hlcyBhcmUgcG90ZW50aWFsbHkgaW50ZXJlc3RpbmcsIGNsZWFyaW5nIGJpdHMgYXMgcHVzaGVz IG9yIGNhbmNlbGxhdGlvbnMgYXJyaXZlLg0KDQpNQVhfUFVTSF9JRCB3b3VsZCBnaXZlIGNsaWVu dHMgYSBmaW5lci1ncmFpbmVkIGxldmVyIHRvIGNvbnRyb2wgcHVzaC4NCg0KV2UgY291bGQgaGF2 ZSBDQU5DRUxfUFVTSCBiZSBzZW50IG9uIHRoZSBzYW1lIHN0cmVhbXMgYXMgdGhlIFBVU0hfUFJP TUlTRSwgYnV0IHRoYXQgZG9lc24ndCBoZWxwIHdpdGggdGhlIGNhc2Ugd2hlcmUgdGhlIFBVU0hf UFJPTUlTRSBtYXkgbm90IGhhdmUgYmVlbiByZWNlaXZlZCBkdWUgdG8gYSBzdHJlYW0gcmVzZXQu DQoNClRoaXMgbWFrZXMgbWUgd29uZGVyIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGFsd2F5cyBzZW5k IHRoZSBQVVNIX1BST01JU0Ugb24gdGhlIGNvbnRyb2wgc3RyZWFtICppbiBhZGRpdGlvbiB0byog YW55IHN0cmVhbSB0aGF0IGl0IGlzIHNlbnQgb24uIFRoaXMgd291bGQgZW5zdXJlIHRoYXQgbm8g bWF0dGVyIHdoYXQsIHRoZSBQVVNIX1BST01JU0UgaXMgYWx3YXlzIHJlY2VpdmVkLCBhbmQgYWRk aXRpb25hbGx5IGVuc3VyZXMgdGhhdCBDQU5DRUxfUFVTSCBpcyByZWNlaXZlZCBhZnRlciBhIFBV U0hfUFJPTUlTRS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGlzIGEgZ29vZCBpZGVhLiAgUFVTSF9Q Uk9NSVNFIGluY2x1ZGVzIGEgaGVhZGVycyBibG9jaywgd2hpY2ggaXMgcHJldHR5IGJpZywgZXZl biB3aXRoIGVmZmVjdGl2ZSBjb21wcmVzc2lvbi4gIEhvTEIgd29uJ3QgYWZmZWN0IHRoaXMgc3Ry ZWFtLCBzbyBzaXplIHNob3VsZG4ndCBiZSBhbiBpc3N1ZSwgYnV0IHN0aWxsLg0KDQpJIGRpZCBj b25zaWRlciBtb3ZpbmcgdGhlIGhlYWRlciBibG9jayB0byB0aGUgY29udHJvbCBzdHJlYW0gY29t cGxldGVseSBhcyBwYXJ0IG9mIGFkZHJlc3NpbmcgdGhlIGlzc3VlIHdpdGggZHVwbGljYXRpb24g dGhhdCBJIG1lbnRpb25lZCBlYXJsaWVyLiAgVGhlIGJhc2ljIHByb2JsZW0gdGhlcmUgaXMgdGhh dCB5b3UgZG9uJ3QgZ3VhcmFudGVlIHRoYXQgdGhlIGNsaWVudCBzZWUgdGhlIFBVU0hfUFJPTUlT RSBiZWZvcmUgaXQgcHJvY2Vzc2VzIHRoZSByZXNwb25zZSBjb250ZW50Lg0KDQoNCi0gamFuYQ0K DQpPbiBUaHUsIEF1ZyAzLCAyMDE3IGF0IDU6NDkgUE0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJp c2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpCYWgsIFFVSUMgdG9vLiAg8J+Yig0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRv Ok1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20+XQ0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAzLCAyMDE3IDEwOjM2IEFNDQpUbzog aWV0Zi1odHRwLXdnQHczLm9yZzxtYWlsdG86aWV0Zi1odHRwLXdnQHczLm9yZz4NClN1YmplY3Q6 IFB1c2ggSUQgLSBNZXJnZSBJbW1pbmVudA0KDQpUaGlzIGlzIE1hcnRpbuKAmXMgUHVzaCBJRCBQ UiBzcGxpdCBvZmYgZnJvbSB1bmlkaXJlY3Rpb25hbC4gIEdpdmVuIHRoYXQgaXQgaGFzIGFscmVh ZHkgYmVlbiBwaWNrZWQgb3ZlciBpbiB0aG9zZSBjb250ZXh0cyBhbmQgdGhlIGZlZWRiYWNrIGZy b20gdGhhdCBhbmQgaW4tcGVyc29uIGRpc2N1c3Npb24gd2FzIHRvIGJyaW5nIHRoaXMgY2hhbmdl IGluIHNlcGFyYXRlbHksIEnigJltIGFib3V0IHJlYWR5IHRvIG1lcmdlIHRoaXMuICBFdmVyeXRo aW5nIGFueW9uZSBoYXMgcXVpYmJsZWQgd2l0aCBoYXMgYmVlbiBlZGl0b3JpYWwuICBIb3dldmVy LCBJIGRvbuKAmXQgc2VlIHJldmlld3MgZnJvbSBtYW55IGZvbGtzLCBzbyBJIHdhbnQgdG8gbWFr ZSBzdXJlIHRoYXQgZXZlcnlvbmUgaW50ZXJlc3RlZCBoYXMgaGFkIGEgY2hhbmNlIHRvIGV4cHJl c3MgYW4gb3Bpbmlvbi4NCg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9w dWxsLzcwMTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwl MkY3MDEmZGF0YT0wNCU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDOGM2 OGE3NDM0MjhjNDNmZDllOTUwOGQ0ZGE5NjkyYTclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3QzElN0MwJTdDNjM2MzczNzg3NjczNDM2MzM4JTdDVW5rbm93biU3Q1ZXNXJibTkz Ym54N0lsWWlPaUl3TGpBdU1EQXdNQ0lzSWxBaU9pSlhhVzR6TWlJc0lrRk9Jam9pVDNSb1pYSWlm USUzRCUzRCU3Qy0xJnNkYXRhPWxGNUNyNUZlMVJ1WTVCT3ZQZ2l5OWlhR3FIUzI3JTJCN2plTTFJ T2lwU3h1NCUzRCZyZXNlcnZlZD0wPg0KDQpJ4oCZbGwgZ2l2ZSBpdCBhIGZldyBob3VycyAodW50 aWwgZXZlcnlvbmXigJlzIGhhZCBhdCBsZWFzdCBhIGxpdHRsZSBiaXQgb2YgYSB3b3JrIGRheSks IHRoZW4gbWVyZ2UgdW5sZXNzIEkgaGVhciBvdGhlcndpc2UuDQoNCg0KDQoNCg0KLS0NCkthenVo byBPa3UNCg0KDQoNCg== --_000_MWHPR21MB0141633E01A781007F3A53FC878B0MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLm01ODc0ODcwNjE1MzI4NDM5NzFtLTc3ODY1Nzg2MjM3MjA3OTYyMDNtMTU3OTU5Njk2Nzk5 MTc2NTEwNmdtYWlsLQ0KCXttc28tc3R5bGUtbmFtZTptXzU4NzQ4NzA2MTUzMjg0Mzk3MW1fLTc3 ODY1Nzg2MjM3MjA3OTYyMDNtXzE1Nzk1OTY5Njc5OTE3NjUxMDZnbWFpbC07fQ0Kc3Bhbi5ob2Vu emINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4ubTU4NzQ4NzA2MTUzMjg0Mzk3MW0t Nzc4NjU3ODYyMzcyMDc5NjIwM20xNTc5NTk2OTY3OTkxNzY1MTA2Z21haWwtbS04OTU4NDY2MTcw NDEyMDI1NTA1aG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fNTg3NDg3MDYxNTMyODQzOTcxbV8t Nzc4NjU3ODYyMzcyMDc5NjIwM21fMTU3OTU5Njk2Nzk5MTc2NTEwNmdtYWlsLW1fLTg5NTg0NjYx NzA0MTIwMjU1MDVob2VuemI7fQ0Kc3Bhbi5tNTg3NDg3MDYxNTMyODQzOTcxbS03Nzg2NTc4NjIz NzIwNzk2MjAzaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOm1fNTg3NDg3MDYxNTMyODQzOTcxbV8t Nzc4NjU3ODYyMzcyMDc5NjIwM2hvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVk IHRoYXQgdGhlIFNFVFRJTkdTIGVudHJ5IGFuZCB0aGUgZnJhbWUgYXJlIHRoZSBzYW1lIDUtOCBi eXRlcyBjb25zdW1lZCwgYW5kIGl0IHdvdWxkIGJlIHNpbXBsZXIgdG8gaGF2ZSBhIHNpbmdsZSBj b2RlIHBhdGguJm5ic3A7IFNpbmNlIHRoaXMgd2hvbGUgdGhpbmcgaXMgYSBkZXBhcnR1cmUgZnJv bSBIVFRQLzIsIEnigJltIG5vdCBwZXJzb25hbGx5IHVwc2V0IGFib3V0IGRpdmVyZ2luZyBhIGxp dHRsZSBmdXJ0aGVyDQogaW4gdGhlIG5hbWUgb2Ygc2ltcGxlciBjb2RlLiZuYnNwOyBUaGlzIGlz buKAmXQgYSB2YWx1ZSB0aGF0IGVpdGhlciBwYXJ0eSBuZWVkcyB0byBrbm93IGJlZm9yZSBzZW5k aW5nIHRyYWZmaWMgdG8gYmVoYXZlIHByb3Blcmx5LCB3aGljaCBpcyB0aGUgY2FzZSB3aXRoIFFV SUPigJlzIGxpbWl0cyBvZiB0aGlzIHR5cGUgdGhhdCBoYXZlIHRoZSBkdWFsIHBhcmFtZXRlci9m cmFtZSBzdHJ1Y3R1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBu YW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDgsIDIwMTcg NTo0NSBQTTxicj4NCjxiPlRvOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7 IEthenVobyBPa3UgJmx0O2thenVob29rdUBnbWFpbC5jb20mZ3Q7OyBRVUlDIFdHICZsdDtxdWlj QGlldGYub3JnJmd0OzsgaWV0Zi1odHRwLXdnQHczLm9yZzsgTWlrZSBCaXNob3AgJmx0O01pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQdXNo IElEIC0gTWVyZ2UgSW1taW5lbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5KdXN0IHRvIGZvbGxvdyB1cCBvbiB0aGlzLCBJJ3ZlIG9wZW5lZCA8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY3MTEmYW1wO2RhdGE9 MDIlN0MwMSU3Q01pY2hhZWwuQmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2U3OWZmODk0ZTUzMTQ3 ZTcyMGIyMDhkNGRlYmZlODgwJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjM3ODM2MzIwOTQyNzMzNSZhbXA7c2RhdGE9NExuJTJGdThBSVdMVHBuS2RFRHlz TUM2RDZMV2hsZWMwajBJU0ZDak9XSHVvJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzExPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBk ZWZpbmVzIGEgbmV3IGZyYW1lIHR5cGUgdGhhdCBzZXRzIHRoZSBsaW1pdCB0byBQdXNoIElELiZu YnNwOyBJbiBhIGZpdCBvZiBpbnNwaXJhdGlvbiwgSSBjYWxsZWQgaXQgTUFYX1BVU0hfSUQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2 ZSByZXB1cnBvc2VkIFNFVFRJTkdTX0VOQUJMRV9QVVNIIGZvciBzZXR0aW5nIHRoZSBpbml0aWFs IGxpbWl0LiZuYnNwOyBUaGUgbmV3bHkgcmVuYW1lZCBTRVRUSU5HU19NQVhfUFVTSF9JRCBzZXRz IHRoZSBpbml0aWFsIE1BWF9QVVNIX0lELjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdhbnQgdG8gZGlzY3VzcyB3aGV0aGVyIHdlIG1pZ2h0 IHJlbW92ZSB0aGUgc2V0dGluZy4mbmJzcDsgU2VuZGluZyBNQVhfUFVTSF9JRCBpbW1lZGlhdGVs eSBhZnRlciBTRVRUSU5HUyBkb2Vzbid0IGFkZCBhbnkgbW9yZSBieXRlcyBhbmQgSSdtIG5vdCBz dXJlIHRoYXQgdGhlcmUgaXMgYW55IHBhcnRpY3VsYXIgbmVlZCB0byBvcHRpbWl6ZSBmb3IgSG9M QiBoZXJlLiZuYnNwOyBJJ20gYW1iaXZhbGVudCwgc28gSSBrZXB0IGl0LA0KIGJ1dCBpdCBpcyBl YXN5IHRvIHJlbW92ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiA1IEF1Z3VzdCAyMDE3IGF0IDEwOjU1LCBKYW5hIEl5ZW5nYXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaUBnb29n bGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFydGluLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBpZGVh IG9mIHNlcXVlbnRpYWwgUHVzaCBJRCBpcyBhIGdvb2Qgb25lLiBZb3UgaGF2ZSB0byBzcGVjaWZ5 IGEgTUFYX1BVU0hfSUQsIHdpdGhvdXQgd2hpY2ggdGhlIGNsaWVudCB3b24ndCBrbm93IGhvdyBm YXIgb3V0IHRvIGV4cGVjdCBDQU5DRUxfUFVTSGVzIGNhbiBiZS4uLiB0aGlzIGFsc28gcmVxdWly ZXMgdGhlbiBhIE1BWF9QVVNIX0lEX1VQREFURSBtZXNzYWdlIHdoaWNoIGNhbiBiZQ0KIHVzZWQg dG8gbW92ZSB0aGUgTUFYIHVwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbmUgbm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBVU0hfUFJPTUlT RSBpcyBzZW50IGJ5IHRoZSBzZXJ2ZXIsIGFuZCBDQU5DRUxfUFVTSCBtYXkgYmUgc2VudCBieSB0 aGUgc2VydmVyLiBUaGUgdGV4dCBjdXJyZW50bHkgc2F5cyB0aGF0IENBTkNFTF9QVVNIIG9uIGEg bm9uLWV4aXN0ZW50IFB1c2ggSUQgcmVzdWx0cyBpbiBlcnJvciwgd2hpY2ggZG9lcyBub3Qgd29y ayB3aXRoIHRoZSBwb3NzaWJpbGl0eSBvZiByZW9yZGVyaW5nIGJldHdlZW4gUFVTSF9QUk9NSVNF DQogYW5kIENBTkNFTF9QVVNILiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3MganVzdCBhIGJ1 Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGRvbid0IHRoaW5rIHNvLiBUaGUgc3BlYyBhbGxvd3MgaXQsIGFuZCBJIGNh biBlYXNpbHkgc2VlIGl0IGhhcHBlbiBpbiBwcmFjdGljZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LSBqYW5hPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNpbWlsYXJseSwgaXQncyBhbHNvIHBvc3NpYmxlIGZvciB0aGUgUFVTSF9QUk9N SVNFIHRvIG5vdCBoYXZlIGJlZW4gcmVjZWl2ZWQgYmVjYXVzZSB0aGUgc3RyZWFtIG9uIHdoaWNo IGl0IHdhcyBzZW50IHdhcyByZXNldC4uLiBiYXNpY2FsbHkgaXQncyBwb3NzaWJsZSBmb3IgYSBj bGllbnQgdG8gcmVjZWl2ZSBhIENBTkNFTF9QVVNIIHdpdGhvdXQgc2VlaW5nIHRoZSBjb3JyZXNw b25kaW5nIFBVU0hfUFJPTUlTRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIG1vcmUgaW50 ZXJlc3RpbmcuJm5ic3A7IEl0IGNyZWF0ZXMgc3RhdGUgb24gdGhlIGNsaWVudDombmJzcDsgaXQg c2F5cyB0aGF0IGNsaWVudHMgYXJlIHJlcXVpcmVkIHRvIGlnbm9yZSBwdXNoZXMgdGhhdCBpdCAq bWlnaHQqIHJlY2VpdmUgaW4gdGhlIGZ1dHVyZS4mbmJzcDsgVGhhdCBzdWdnZXN0cyBhIGRpZmZl cmVudCBmaXgsIGFraW4gdG8gd2hhdCB3ZSB1c2UgZm9yIG90aGVyIHNpbWlsYXIgcGllY2VzIG9m IHN0YXRlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4xLiBtYWtlIFB1c2ggSUQgc2VxdWVudGlhbCAocmlnaHQgbm93IHRoZSBvbmx5IHJlcXVp cmVtZW50IGlzIGZvciBjb25uZWN0aW9uLXdpZGUgdW5pcXVlbmVzcyk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHVzaW5nIGEgc2VxdWVudGlhbCBJRCB3 aWxsIGJlIGEgZ29vZCBpZGVhIG5vdCBvbmx5IGZvciBmaXhpbmcgdGhpcyBpc3N1ZSBidXQgdGhh dCBpdCBtaWdodCBiZSBwb3NzaWJsZSB0byB1c2UgdGhlIHNlcXVlbnRpYWxpdHkgdG8gZml4IHRo ZSBmaXJzdCBpc3N1ZSByYWlzZWQgaW4gdGhlIFBSIChpLmUuIGNsaWVudCBrbm93aW5nICZxdW90 O3doZW4gdGhlIHNlcnZlciB3aWxsIHN0b3AgcmVmZXJlbmNpbmcNCiBhIHB1c2ggSUQgaW4gUFVT SF9QUk9NSVNFJnF1b3Q7KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgdGhlcmUgaXMgYSBzZXF1ZW50aWFsIG9yZGVyaW5nIGd1YXJhbnRl ZSBmb3IgUHVzaCBJRCwgYSBjbGllbnQgY2FuLCBieSBsb29raW5nIGF0IHRoZSBQdXNoIElELCBk ZXRlcm1pbmUgd2hldGhlciBpZiBpdCBoYXMgYWxyZWFkeSBjb25zdW1lZCB0aGUgcHVzaGVkIHJl cXVlc3QuIElmIGl0IGhhcywgaXQgd2lsbCBpbW1lZGlhdGVseSBsb29rdXAgaXRzIGNhY2hlLCBh bmQgaW4gY2FzZSBpdCBmYWlscyB0bw0KIGZpbmQgYSBjYWNoZWQgb2JqZWN0LCB0aGVuIGlzc3Vl IGEgcHVsbC4gSWYgaXQgaGFzIG5vdCBjb25zdW1lZCB0aGUgcHVzaGVkIHJlcXVlc3QsIGl0IHNo b3VsZCB3YWl0IGZvciB0aGUgcHVzaGVkIHJlc3BvbnNlIHRvIGFycml2ZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4yLiBoYXZlIHRoZSBjbGllbnQgYWR2ZXJ0aXNlIGEgTUFY X1BVU0hfSUQgKGluIFNFVFRJTkdTLCBhbmQgd2l0aCBhIG5ldyBmcmFtZSB0eXBlOyB0aGUgc2V0 dGluZyBtaWdodCB7YWJ8cmV9dXNlIEVOQUJMRV9QVVNIKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd291bGQgYm91bmQgc3RhdGUgZm9yIGNsaWVu dHMuJm5ic3A7IEEgY2xpZW50IGNvdWxkbid0IHJlY2VpdmUgYW4gYXJiaXRyYXJ5IG51bWJlciBv ZiBDQU5DRUxfUFVTSCBtZXNzYWdlcyB0aGF0IGFyZSBkaXN0cmlidXRlZCBvdmVyIHRoZSAzMi1i aXQgUHVzaCBJRCBzcGFjZSwgc28gdHJhY2tpbmcgY2FuY2VsbGF0aW9ucyBpcyBlYXN5LiZuYnNw OyBDbGllbnRzIGNvdWxkIHVzZSBhIHNpbXBsZSBiaXR2ZWN0b3IgdG8gdHJhY2sNCiB3aGljaCBw dXNoZXMgYXJlIHBvdGVudGlhbGx5IGludGVyZXN0aW5nLCBjbGVhcmluZyBiaXRzIGFzIHB1c2hl cyBvciBjYW5jZWxsYXRpb25zIGFycml2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TUFYX1BVU0hfSUQgd291bGQgZ2l2ZSBjbGllbnRzIGEg ZmluZXItZ3JhaW5lZCBsZXZlciB0byBjb250cm9sIHB1c2guPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldlIGNvdWxkIGhhdmUgQ0FOQ0VMX1BVU0ggYmUgc2VudCBvbiB0aGUgc2FtZSBzdHJlYW1z IGFzIHRoZSBQVVNIX1BST01JU0UsIGJ1dCB0aGF0IGRvZXNuJ3QgaGVscCB3aXRoIHRoZSBjYXNl IHdoZXJlIHRoZSBQVVNIX1BST01JU0UgbWF5IG5vdCBoYXZlIGJlZW4gcmVjZWl2ZWQgZHVlIHRv IGEgc3RyZWFtIHJlc2V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIG1ha2VzIG1lIHdvbmRlciBpZiBpdCBtYWtlcyBzZW5zZSB0byBh bHdheXMgc2VuZCB0aGUgUFVTSF9QUk9NSVNFIG9uIHRoZSBjb250cm9sIHN0cmVhbSAqaW4gYWRk aXRpb24gdG8qIGFueSBzdHJlYW0gdGhhdCBpdCBpcyBzZW50IG9uLiBUaGlzIHdvdWxkIGVuc3Vy ZSB0aGF0IG5vIG1hdHRlciB3aGF0LCB0aGUgUFVTSF9QUk9NSVNFIGlzIGFsd2F5cyByZWNlaXZl ZCwgYW5kIGFkZGl0aW9uYWxseSBlbnN1cmVzDQogdGhhdCBDQU5DRUxfUFVTSCBpcyByZWNlaXZl ZCBhZnRlciBhIFBVU0hfUFJPTUlTRS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IHRoaW5r IHRoYXQgaXMgYSBnb29kIGlkZWEuJm5ic3A7IFBVU0hfUFJPTUlTRSBpbmNsdWRlcyBhIGhlYWRl cnMgYmxvY2ssIHdoaWNoIGlzIHByZXR0eSBiaWcsIGV2ZW4gd2l0aCBlZmZlY3RpdmUgY29tcHJl c3Npb24uJm5ic3A7IEhvTEIgd29uJ3QgYWZmZWN0IHRoaXMgc3RyZWFtLCBzbyBzaXplIHNob3Vs ZG4ndCBiZSBhbiBpc3N1ZSwgYnV0IHN0aWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBjb25zaWRlciBtb3ZpbmcgdGhlIGhlYWRl ciBibG9jayB0byB0aGUgY29udHJvbCBzdHJlYW0gY29tcGxldGVseSBhcyBwYXJ0IG9mIGFkZHJl c3NpbmcgdGhlIGlzc3VlIHdpdGggZHVwbGljYXRpb24gdGhhdCBJIG1lbnRpb25lZCBlYXJsaWVy LiZuYnNwOyBUaGUgYmFzaWMgcHJvYmxlbSB0aGVyZSBpcyB0aGF0IHlvdSBkb24ndCBndWFyYW50 ZWUgdGhhdCB0aGUgY2xpZW50IHNlZSB0aGUgUFVTSF9QUk9NSVNFDQogYmVmb3JlIGl0IHByb2Nl c3NlcyB0aGUgcmVzcG9uc2UgY29udGVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPi0gamFu YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAzLCAyMDE3IGF0IDU6NDkgUE0sIE1pa2Ug QmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QmFoLCBRVUlDIHRvby4mbmJzcDsNCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj4mIzEyODUyMjs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJy ZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8 L2I+IE1pa2UgQmlzaG9wIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgQXVndXN0IDMsIDIwMTcgMTA6MzYg QU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzppZXRmLWh0dHAtd2dAdzMub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aWV0Zi1odHRwLXdnQHczLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUHVzaCBJRCAtIE1lcmdlIEltbWluZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhpcyBpcyBNYXJ0aW7igJlzIFB1c2ggSUQgUFIgc3BsaXQgb2ZmIGZy b20gdW5pZGlyZWN0aW9uYWwuJm5ic3A7IEdpdmVuIHRoYXQgaXQgaGFzIGFscmVhZHkgYmVlbiBw aWNrZWQgb3ZlciBpbiB0aG9zZSBjb250ZXh0cyBhbmQgdGhlIGZlZWRiYWNrIGZyb20gdGhhdCBh bmQgaW4tcGVyc29uIGRpc2N1c3Npb24gd2FzDQogdG8gYnJpbmcgdGhpcyBjaGFuZ2UgaW4gc2Vw YXJhdGVseSwgSeKAmW0gYWJvdXQgcmVhZHkgdG8gbWVyZ2UgdGhpcy4mbmJzcDsgRXZlcnl0aGlu ZyBhbnlvbmUgaGFzIHF1aWJibGVkIHdpdGggaGFzIGJlZW4gZWRpdG9yaWFsLiZuYnNwOyBIb3dl dmVyLCBJIGRvbuKAmXQgc2VlIHJldmlld3MgZnJvbSBtYW55IGZvbGtzLCBzbyBJIHdhbnQgdG8g bWFrZSBzdXJlIHRoYXQgZXZlcnlvbmUgaW50ZXJlc3RlZCBoYXMgaGFkIGEgY2hhbmNlIHRvIGV4 cHJlc3MgYW4gb3Bpbmlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjcwMSZhbXA7 ZGF0YT0wNCU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDOGM2OGE3NDM0 MjhjNDNmZDllOTUwOGQ0ZGE5NjkyYTclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2MzczNzg3NjczNDM2MzM4JTdDVW5rbm93biU3Q1ZXNXJibTkzYm54N0ls WWlPaUl3TGpBdU1EQXdNQ0lzSWxBaU9pSlhhVzR6TWlJc0lrRk9Jam9pVDNSb1pYSWlmUSUzRCUz RCU3Qy0xJmFtcDtzZGF0YT1sRjVDcjVGZTFSdVk1Qk92UGdpeTlpYUdxSFMyNyUyQjdqZU0xSU9p cFN4dTQlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5j b20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvNzAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SeKAmWxsIGdpdmUgaXQgYSBmZXcgaG91cnMgKHVudGlsIGV2ZXJ5b25l4oCZcyBoYWQg YXQgbGVhc3QgYSBsaXR0bGUgYml0IG9mIGEgd29yayBkYXkpLCB0aGVuIG1lcmdlIHVubGVzcyBJ IGhlYXIgb3RoZXJ3aXNlLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6Izg4ODg4OCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPGJyPg0KPHNwYW4gY2xhc3M9Im01 ODc0ODcwNjE1MzI4NDM5NzFtLTc3ODY1Nzg2MjM3MjA3OTYyMDNob2VuemIiPi0tIDxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM4ODg4ODgiPkthenVobyBPa3U8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB0141633E01A781007F3A53FC878B0MWHPR21MB0141namp_-- From nobody Wed Aug 9 10:03:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A95132430 for ; Wed, 9 Aug 2017 10:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 neY8A6SFY8KI for ; Wed, 9 Aug 2017 10:03:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E440B132021 for ; Wed, 9 Aug 2017 10:03:39 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by m0122331.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v79H2pKd030539; Wed, 9 Aug 2017 18:03:34 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=57pk/4appf5xWOXFDe5yn1JAPg/vMHU4QxgaamBxO1U=; b=M8bROtlXnB9f96oUoQBNDqPf6WAVUQmZw9XRJWhyWhR770zQMh3GnEmnoF5U7AwPv6WV Mpr2xgTFqgdxIFSOCAl+IwYondBFpJq2lTktNgUdiA+QleCFXj+Qcjq9QLMUf6ZTySrR MspEo69wOswzJ1I6nM1on6QNseM5lsfO1GwKjxAG7vzO2JZ/nczzdQ5nJ3ZiEeW/GniG Nhad0y70uWloU0dbLE4jKEtifs9l2uFfew++52oIv7cX/rUMLs8BgO0RMNdhQonDtjej p5+j4ArDlBxiEoH+gwWi2peHej5dCWHSVHcEq4vjJUp9qY57y8Z05kS9vozCZlFW0l0q zw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2c7c5amxcw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 09 Aug 2017 18:03:33 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v79H1281007860; Wed, 9 Aug 2017 13:03:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c59bugk25-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Aug 2017 13:03:32 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 13:03:29 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 9 Aug 2017 13:03:29 -0400 From: "Lubashev, Igor" To: Ian Swett , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG , Ryan Hamilton Subject: RE: 5-tuple uniquess Thread-Topic: 5-tuple uniquess Thread-Index: AQHTDp1bhJPQi5zq4kWW5+Ln50FN+6J3oyiAgAABdoCAAAX3AIADr5aAgADmn5A= Date: Wed, 9 Aug 2017 17:03:29 +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.35.0] Content-Type: multipart/alternative; boundary="_000_e00be296557740d0ab720da79e1522e4usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708090263 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-09_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708090263 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Aug 2017 17:03:43 -0000 --_000_e00be296557740d0ab720da79e1522e4usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHNvbWVvbmUgZWxhYm9yYXRlIG9uIOKAnFBvc3NpYmx5IGl0IHNob3VsZCBzcGVjaWZ5IHRo ZSBjbGllbnQncyBjb25uZWN0aW9uIElEIGluIHRoZSBwYWNrZXQgaGVhZGVyIGFuZCB0aGVuIHRo ZSBuZXcgc2VydmVyIGNvbm5lY3Rpb24gSUQgaW4gdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzP+KA nQ0KDQpJcyB0aGF0IG9ubHkgZm9yIOKAnFNlcnZlciBDbGVhcnRleHTigJ0/IFdoYXQgYWJvdXQg Y29ubmVjdGlvbnMgdGhhdCBzdGFydCBvdXQgd2l0aCAwUlRUIHBhY2tldHMg4oCTIGhvdyB3b3Vs ZCB0aGUgTkFUIGtub3cgd2hpY2ggZmxvdyBTZXJ2ZXLigJlzIDFSVFQgcmVwbHkgYmVsb25ncyB0 byAoaWYgU2VydmVyIGNoYW5nZXMgdGhlIENvbmVuY3Rpb25JRCk/DQoNCk1heWJlIHJlbHlpbmcg b24gYSA1LXR1cGxlIGlzIG5vdCBzdWNoIGEgYmFkIGlkZWEgYWZ0ZXIgYWxsPyAgQSBOQVQgZG9l cyBub3QgbmVlZCBhIGRpZmZlcmVudCBlcGhlbWVyYWwgcG9ydCBmb3IgZXZlcnkgb3V0Z29pbmcg Y29ubmVjdGlvbi4gIEl0IG9ubHkgbmVlZHMgYSBkaWZmZXJlbnQgZXBoZW1lcmFsIHBvcnQgZm9y IG91dGdvaW5nIGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1lIElQLg0KDQpFdmVuIHRoZW4sIGlmIHRo ZSBOQVQgaXMgd2lsbGluZyB0byBkbyBzb21ldGhpbmcgc3BlY2lhbCBmb3IgUVVJQywgaXQgY2Fu IGJlIGEgbXVjaCBzaW1wbGVyIHRoaW5nIHRoYW4gZXhhbWluZSBRVUlDIHRyYW5zcG9ydCBwYXJh bXMuICBUaGUgTkFUIGNhbiBzaW1wbHkgcmVzZXJ2ZSBhIHNpbmdsZSBlcGhlbWVyYWwgcG9ydCBm b3IgYWxsIDFSVFQgUVVJQyBwYWNrZXRzLiAgVGhhdCBpcywgYWxsIG91dGdvaW5nIGNsZWFydGV4 dCBhbmQgMHJ0dCBRVUlDIHBhY2tldHMgd291bGQgcmVxdWlyZSBhIGRpc3RpbmN0IDUtdHVwbGUs IGJ1dCBvbmNlIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGVzIHRvIDFSVFQsIHRoZSBlcGhlbWVyYWwg cG9ydCBpdCB1c2VkIGNhbiBiZSBmcmVlZCwgYW5kIGFsbCAxUlRUIHBhY2tldHMgc291cmNlZCBm cm9tIHRoZSByZXNlcnZlZCBRSVVDIHBvcnQuICBUaGF0IHdvdWxkIHdvcmssIHNpbmNlIGFsbCAx UlRUIHBhY2tldHMgKGJvdGggZnJvbSBjbGllbnQgYW5kIHNlcnZlcikgd291bGQgYmUgdXNpbmcg U2VydmVyLXNlbGVjdGlvbiBDb25uZWN0aW9uSUQuDQoNCg0KICAqICAgSWdvcg0KDQoNCg0KRnJv bTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXks IEF1Z3VzdCAwOCwgMjAxNyA3OjAxIFBNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8 bWlra2VsZmpAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IFJ5 YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29tPg0KU3ViamVjdDogUmU6IDUtdHVwbGUgdW5pcXVl c3MNCg0KWW91J3JlIHJpZ2h0LCBlcGhlbWVyYWwgcG9ydCBleGhhdXN0aW9uIGlzIGEgdmVyeSBy ZWFsIHBvdGVudGlhbCBpc3N1ZSwgYW5kIEkgdGhpbmsgd2Ugc2hvdWxkIGVuc3VyZSBtdWx0aXBs ZSBRVUlDIGNvbm5lY3Rpb25zIGNhbiBydW4gb3ZlciB0aGUgc2FtZSA1LXR1cGxlIGFuZCB3ZSBk b24ndCBzcGVjaWZ5IFFVSUMgaW4gYSB3YXkgdGhhdCBwcmVjbHVkZXMgdGhhdC4NCg0KSSBiZWxp ZXZlIHlvdSdyZSBjb3JyZWN0IHRoYXQgdGhlIGN1cnJlbnQgU2VydmVyIENsZWFydGV4dCBtYWtl cyB0aGlzIGltcG9zc2libGUgaWYgdGhlIHNlcnZlciBjaGFuZ2VzIHRoZSBjb25uZWN0aW9uIElE LiAgUG9zc2libHkgaXQgc2hvdWxkIHNwZWNpZnkgdGhlIGNsaWVudCdzIGNvbm5lY3Rpb24gSUQg aW4gdGhlIHBhY2tldCBoZWFkZXIgYW5kIHRoZW4gdGhlIG5ldyBzZXJ2ZXIgY29ubmVjdGlvbiBJ RCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnM/ICBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vl c183MTQmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8y c2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0x TGtjTkpGTU9rZ1lkcDRfcTgmcz0tRHR2dGttRF9sWkpnRXRqdnVneDRPeHNrUkFVbXFweTVOZ0Nn TnphaEd3JmU9Pg0KDQpUaGUgdGV4dCBpcyBhbHNvIG1pc3Npbmcgc29tZSBkZXRhaWxzIG9uIGhv dyBjaGFuZ2luZyB0aGUgY29ubmVjdGlvbiBJRCBzaG91bGQgd29yayBmb3IgU3RhdGVsZXNzIFJl dHJ5LCBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNzEz PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0 aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfNzEzJmQ9RHdNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1 S1BtbG8mbT1tWGtpS0toX0ZrUk8tTUFObzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JnM9Y1Zf NUFVSlBvVzQ2U1FISlQxTml5X3p1UkN4MEU3eDI4OC1MNDYtemhkWSZlPT4sIHNvIEknZCBleHBl Y3Qgc29tZSBpbXByb3ZlbWVudHMgaW4gdGhlIG5lYXIgZnV0dXJlLg0KDQpPbiBTdW4sIEF1ZyA2 LCAyMDE3IGF0IDEwOjQzIEFNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBn bWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBSeWFuLA0K DQpJIGNhbiBkaWcgZG93biBpbiBtb3JlIGRldGFpbCBpZiB0aGVyZSBpcyBpbnRlcmVzdC4gTWVh bndoaWxlLCBzb21lIGV4YW1wbGVzIHdoZXJlIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQgaXMgbm90 IGNvbXBhdGlibGUgd2l0aCBteSByZXF1ZXN0IGlzOg0KDQpUaGUgdmVyc2lvbiBuZWdvdGlhdGlv biBwYWNrZXQgaXMgb2sgLSBpdCByZWZsZWN0cyB0aGUgY2xpZW50IHZlcnNpb24NCmh0dHBzOi8v cXVpY3dnLmdpdGh1Yi5pby9iYXNlLWRyYWZ0cy9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0Lmh0 bWwjcGFja2V0LXZlcnNpb248aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19xdWljd2cuZ2l0aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRm LTJEcXVpYy0yRHRyYW5zcG9ydC5odG1sLTIzcGFja2V0LTJEdmVyc2lvbiZkPUR3TUZhUSZjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRu X201NUtQbWxvJm09bVhraUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9xOCZz PWduejhQSjRSUU1xNnctX1dGYTFSSFlNVGdwZ3RnSW1ha1IxcVp3bV91VGsmZT0+DQoNCkJ1dA0K aHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlvL2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFu c3BvcnQuaHRtbCNwYWNrZXQtc2VydmVyLWNsZWFydGV4dDxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRy YWZ0c19kcmFmdC0yRGlldGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNwYWNrZXQtMkRzZXJ2 ZXItMkRjbGVhcnRleHQmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5v MFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmcz1EaldkbzhZaHU4dDdoMXpxZDdCSXhrOV9UTFUz NkF4bWRaMERtaFpuNnZFJmU9Pg0KIlRoZSBjb25uZWN0aW9uIElEIGZpZWxkIGluIGEgU2VydmVy IENsZWFydGV4dCBwYWNrZXQgY29udGFpbnMgYSBjb25uZWN0aW9uIElEIHRoYXQgaXMgY2hvc2Vu IGJ5IHRoZSBzZXJ2ZXIgKHNlZSBTZWN0aW9uIDUuNjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRyYWZ0 c19kcmFmdC0yRGlldGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNjb25uZWN0aW9uLTJEaWQm ZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNy VzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpG TU9rZ1lkcDRfcTgmcz01U0g2dTdBYUhfYXJ4R1kzeUVlcXd5aGlvOGRUWDlTTVFXRmMyVElsaFkw JmU9PikuIg0KVGhpcyBicmVha3MgbGlua2FnZSB0byB0aGUgb3JpZ2luYWwgY2xpZW50IGNvbm5l Y3Rpb24gaWQgc28gdGhlIGNsaWVudCBjYW5ub3QgdGVsbCB3aGljaCBjb25uZWN0aW9uIHRoZSBy ZXNwb25zZSBiZWxvbmdzIHRvIHVubGVzcyBsb29raW5nIGludG8gNS10dXBsZSwgb3IgdGVzdGlu ZyBhbGwgcmVjZW50IGNvbm5lY3Rpb25zIGFnYWluc3QgQUVBRCBzaWduYXR1cmUgKGRlcGVuZGlu ZyBvbiB3aGVyZSB0aGlzIGxhbmRzKS4NCg0KSSBoYXZlIG5vdCBjb3ZlcmVkIGFsbCBvdGhlciBw b3NzaWJsZSBzZXJ2ZXIgcmVzcG9uc2VzLCBidXQgc2ltaWxhciBjb25jZXJucyBhcHBseS4NCkl0 IGlzIG5vdCBhIG1ham9yIGNoYW5nZSwgYnV0IGN1cnJlbnRseSBpdCBpcyBub3QgcG9zc2libGUu DQoNCkFub3RoZXIgaXNzdWUgaXMgaG9zdGlsZSByZXNwb25zZSB0byBpbml0aWFsIGNvbm5lY3Rp b24gc2V0dXAsIGFuZCBwbGFpbiBlcnJvcnMgLSBob3cgdG8geW91IHJlcGx5IHdpdGggYW4gZXJy b3IuIEhhdmluZyB0aGUgY29ubmVjdGlvbiBpZCBmcm9tIHRoZSBjbGllbnQgbWFrZXMgaXQgcmVh c29uYWJseSBlYXN5IHRvIGRlYWwgd2l0aCAtIHNpbWlsYXIgdG8gdmVyc2lvbiBuZWdvdGlhdGlv bi4gQWx0ZXJuYXRpdmVseSB5b3UgaGF2ZSB0byByZWx5IG9uIDUtdHVwbGVzLiBUaGlzIHJlcXVp cmVzIGNhcmVmdWwgYW5hbHlzaXMgb2YgYm90aCB0aGUgdHJhbnNwb3J0IGRvYyBhbmQgcG9zc2li bHkgVExTIGFuZCB0aGlucyBhcmUgbm90IGZ1bGx5IHNldHRsZWQuIFN0YXRlbGVzcyByZXNldCBp cyByZWxhdGVkIHRvIHRoaXMuIEkgd2lsbCBub3QgYXJndWUgc3Ryb25nbHkgb24gdGhpcyBiZWNh dXNlIHNpbmNlIEkgbGFzdCBsb29rZWQgYXQgaXQsIG5ldyBBRUFEIGVuY3J5cHRpb24gaXMgYmVp bmcgZGlzY3Vzc2VkLCBhbmQgSSBoYXZlIG5vdCBhbmFseXNlZCB0aGlzIGluIGRldGFpbC4NCg0K VGhlbiB0aGVyZSBpcyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gVGhpcyBhbHNvIHJlcXVpcmVzIGNh cmVmdWwgYW5hbHlzaXMuIEnigJltIG5vdCBzdXJlIGlmIGl0IGN1cnJlbnRseSBjb3ZlcnMgbXkg cmVxdWVzdC4NCg0KSeKAmW0gc3VyZSB0aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2l0 aCBpbXBsaWNpdCBhc3N1bXB0aW9ucyB0aGF0IEkgYW0gbm90IGFibGUgdG8gbGlzdCBvZmYgbWVt b3J5Lg0KDQpUaGUgKG15KSBiYXNpYyBydWxlIGlzIHRoZSBhbnkgY2hhbmdlIGluIGNvbm5lY3Rp b24gSUQgc2hvdWxkIHJlZmVyIHRvIHRoZSBwcmV2aW91cyBJRCB3aXRob3V0IHJlbHlpbmcgb24g ZXh0ZXJuYWwgc3RhdGUgc3VjaCBhcyA1LXR1cGxlcyBvciBUTFMgZXh0ZW5zaW9uIHN0YXRlICh3 aGljaCByZXF1aXJlcyBjcnlwdG8gc3RhdGUgdG8gYWNjZXNzIGFuZCBjb21wbGljYXRlcyB0aGlu Z3MpLiBBbHNvLCBkdWUgY29uY2VybnMgb2YgcHJpdmFjeSBjb25jZXJucyB0aGlzIGxpbmthZ2Ug YmV0d2VlbiBjb25uZWN0aW9uIElE4oCZcyBzaG91bGQgb25seSBiZSBwb3NzaWJsZSBieSBwZWVy cywgZXhjZXB0cyBmb3IgdGhlIGluaXRpYWwgY2xpZW50IHRvIHNlcnZlciBjb25uZWN0aW9uIHRy YW5zaXRpb24gdGhhdCBpcyBhbHNvIHZpc2libGUgdG8gYW55IHBhcnR5IG9uLXBhdGguDQoNCklu IGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBlbmNvZGluZyBjb25jZXJucywgaXQgbWF5IGFsc28gYmUg aGVscGZ1bCB0byBleHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIHNhbWUgVURQIHBvcnQgbWF5IGJl IHVzZWQgdG8gaW5pdGlhdGUgbXVsdGlwbGUgaW5kZXBlbmRlbnQgUVVJQyBjb25uZWN0aW9uIHRv IHRoZSBzYW1lIHNlcnZlciBVRFAgcG9ydCB3aGVuIGNvbm5lY3Rpb24gSUQgaGFzIGJlZW4gbmVn b3RpYXRlZCB0byBiZSBwcmVzZW50IC0gb3IgZnVydGhlciBkZXRhaWwgdGhpcyBwb3NzaWJpbGl0 eSBhcyBzb21ldGhpbmcgdGhhdCBjYW4gYmUgbmVnb3RpYXRlZC4NCg0KDQpTb21lIG90aGVyIHBv aW50cyBJIGZvcmdldCB0byBtZW50aW9uIHJlZ2FyZGluZyBiZW5lZml0cyBvZiBub24tdW5pcXVl IHR1cGxlczoNCg0KNSkgbm8gaW50ZXJmZXJlbmNlIHdpdGggT1MgaXMgbmVjZXNzYXJ5IGluIG9y ZGVyIHRvIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uIHRvIGFuIGV4aXN0aW5nIGVuZHBvaW50 IGJlY2F1c2Ugbm8gbmV3IGVwaGVtZXJhbCBwb3J0IGlzIG5lZWRlZC4gVGhpcyBtYXkgYWxzbyBz aW1wbGlmeSBjbGVhbiB1cCBhbmQgc3RhdGUgbWFuYWdlbWVudCwgZXNwZWNpYWxseSBzZXJ2ZXIg dG8gc2VydmVyLg0KDQo2KSBOZXRtYXAgYW5kIHNpbWlsYXIgaGlnaCBzcGVlZCBpbnRlcmZhY2Vz IHdvdWxkIGJlIHNpbXBsZXIgd2l0aG91dCBoYXZpbmcgdG8gZGVhbCB3aXRoIGVwaGVtZXJhbCBw b3J0IGFsbG9jYXRpb24sIGVzcGVjaWFsbHkgc2VydmVyIHRvIHNlcnZlciB3aGVyZSBib3RoIGVu ZCBwb2ludHMgY2FuIHJlZmVyZW5jZSBlYWNoIG90aGVyLCBhbmQgd2hlcmUgaXQgbWlnaHQgYmUg cmFuZG9tIHdoaWNoIGVuZHBvaW50IGFjdHVhbGx5IGluaXRpYXRlcyB0byB0aGUgY29ubmVjdGlv biAoYXMgaW4gQ29yZCAvIEthZGVtbGlhIHN0eWxlIG92ZXJsYXkgbmV0d29ya3MpDQoNCktpbmQg UmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQo= --_000_e00be296557740d0ab720da79e1522e4usma1exdag1mb5msgcorpak_ 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 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEw MDUxMzY4NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xMjg4NTY3NTIwIC0xNjUyODk5NjU4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Q2FuIHNvbWVvbmUgZWxhYm9yYXRlIG9uIOKAnFBvc3NpYmx5IGl0 IHNob3VsZCBzcGVjaWZ5IHRoZSBjbGllbnQncyBjb25uZWN0aW9uIElEIGluIHRoZSBwYWNrZXQg aGVhZGVyIGFuZCB0aGVuIHRoZSBuZXcgc2VydmVyIGNvbm5lY3Rpb24gSUQgaW4gdGhlIHRyYW5z cG9ydCBwYXJhbWV0ZXJzP+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JcyB0aGF0IG9ubHkgZm9yIOKAnFNl cnZlciBDbGVhcnRleHTigJ0/IFdoYXQgYWJvdXQgY29ubmVjdGlvbnMgdGhhdCBzdGFydCBvdXQg d2l0aCAwUlRUIHBhY2tldHMg4oCTIGhvdyB3b3VsZCB0aGUgTkFUIGtub3cgd2hpY2ggZmxvdyBT ZXJ2ZXLigJlzIDFSVFQgcmVwbHkgYmVsb25ncyB0byAoaWYgU2VydmVyIGNoYW5nZXMNCiB0aGUg Q29uZW5jdGlvbklEKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWF5YmUgcmVseWluZyBvbiBhIDUtdHVwbGUg aXMgbm90IHN1Y2ggYSBiYWQgaWRlYSBhZnRlciBhbGw/Jm5ic3A7IEEgTkFUIGRvZXMgbm90IG5l ZWQgYSBkaWZmZXJlbnQgZXBoZW1lcmFsIHBvcnQgZm9yIGV2ZXJ5IG91dGdvaW5nIGNvbm5lY3Rp b24uJm5ic3A7IEl0IG9ubHkgbmVlZHMgYSBkaWZmZXJlbnQgZXBoZW1lcmFsDQogcG9ydCBmb3Ig b3V0Z29pbmcgY29ubmVjdGlvbnMgdG8gdGhlIHNhbWUgSVAuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV2ZW4g dGhlbiwgaWYgdGhlIE5BVCBpcyB3aWxsaW5nIHRvIGRvIHNvbWV0aGluZyBzcGVjaWFsIGZvciBR VUlDLCBpdCBjYW4gYmUgYSBtdWNoIHNpbXBsZXIgdGhpbmcgdGhhbiBleGFtaW5lIFFVSUMgdHJh bnNwb3J0IHBhcmFtcy4mbmJzcDsgVGhlIE5BVCBjYW4gc2ltcGx5IHJlc2VydmUgYSBzaW5nbGUg ZXBoZW1lcmFsDQogcG9ydCBmb3IgYWxsIDFSVFQgUVVJQyBwYWNrZXRzLiZuYnNwOyBUaGF0IGlz LCBhbGwgb3V0Z29pbmcgY2xlYXJ0ZXh0IGFuZCAwcnR0IFFVSUMgcGFja2V0cyB3b3VsZCByZXF1 aXJlIGEgZGlzdGluY3QgNS10dXBsZSwgYnV0IG9uY2UgdGhlIGNvbm5lY3Rpb24gbWlncmF0ZXMg dG8gMVJUVCwgdGhlIGVwaGVtZXJhbCBwb3J0IGl0IHVzZWQgY2FuIGJlIGZyZWVkLCBhbmQgYWxs IDFSVFQgcGFja2V0cyBzb3VyY2VkIGZyb20gdGhlIHJlc2VydmVkIFFJVUMNCiBwb3J0LiZuYnNw OyBUaGF0IHdvdWxkIHdvcmssIHNpbmNlIGFsbCAxUlRUIHBhY2tldHMgKGJvdGggZnJvbSBjbGll bnQgYW5kIHNlcnZlcikgd291bGQgYmUgdXNpbmcgU2VydmVyLXNlbGVjdGlvbiBDb25uZWN0aW9u SUQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JZ29yPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMDgsIDIwMTcg NzowMSBQTTxicj4NCjxiPlRvOjwvYj4gTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlr a2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWlj QGlldGYub3JnJmd0OzsgUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiA1LXR1cGxlIHVuaXF1ZXNzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UncmUgcmlnaHQsIGVwaGVtZXJhbCBw b3J0IGV4aGF1c3Rpb24gaXMgYSB2ZXJ5IHJlYWwgcG90ZW50aWFsIGlzc3VlLCBhbmQgSSB0aGlu ayB3ZSBzaG91bGQgZW5zdXJlIG11bHRpcGxlIFFVSUMgY29ubmVjdGlvbnMgY2FuIHJ1biBvdmVy IHRoZSBzYW1lIDUtdHVwbGUgYW5kIHdlIGRvbid0IHNwZWNpZnkgUVVJQyBpbiBhIHdheSB0aGF0 IHByZWNsdWRlcyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGJlbGlldmUgeW91J3JlIGNvcnJlY3QgdGhhdCB0aGUgY3VycmVudCBT ZXJ2ZXIgQ2xlYXJ0ZXh0IG1ha2VzIHRoaXMgaW1wb3NzaWJsZSBpZiB0aGUgc2VydmVyIGNoYW5n ZXMgdGhlIGNvbm5lY3Rpb24gSUQuJm5ic3A7IFBvc3NpYmx5IGl0IHNob3VsZCBzcGVjaWZ5IHRo ZSBjbGllbnQncyBjb25uZWN0aW9uIElEIGluIHRoZSBwYWNrZXQgaGVhZGVyIGFuZCB0aGVuIHRo ZSBuZXcgc2VydmVyIGNvbm5lY3Rpb24gSUQNCiBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnM/ Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfNzE0JmFt cDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpE UE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209bVhraUtLaF9Ga1JPLU1BTm8w V3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9xOCZhbXA7cz0tRHR2dGttRF9sWkpnRXRqdnVneDRPeHNr UkFVbXFweTVOZ0NnTnphaEd3JmFtcDtlPSI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL2lzc3Vlcy83MTQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0ZXh0IGlzIGFsc28gbWlzc2luZyBzb21lIGRldGFp bHMgb24gaG93IGNoYW5naW5nIHRoZSBjb25uZWN0aW9uIElEIHNob3VsZCB3b3JrIGZvciBTdGF0 ZWxlc3MgUmV0cnksIHNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0 c19pc3N1ZXNfNzEzJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFt cDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209bVhr aUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9xOCZhbXA7cz1jVl81QVVKUG9X NDZTUUhKVDFOaXlfenVSQ3gwRTd4Mjg4LUw0Ni16aGRZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVzLzcxMzwvYT4sDQog c28gSSdkIGV4cGVjdCBzb21lIGltcHJvdmVtZW50cyBpbiB0aGUgbmVhciBmdXR1cmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwg QXVnIDYsIDIwMTcgYXQgMTA6NDMgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0Ozxh IGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxm akBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUz NDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIy ODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAz NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUnlhbiw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21h aWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQz MDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgY2FuIGRpZyBkb3duIGluIG1vcmUgZGV0YWlsIGlmIHRoZXJlIGlz IGludGVyZXN0LiBNZWFud2hpbGUsIHNvbWUgZXhhbXBsZXMgd2hlcmUgdGhlIHRyYW5zcG9ydCBk b2N1bWVudCBpcyBub3QgY29tcGF0aWJsZSB3aXRoIG15IHJlcXVlc3QgaXM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1f LTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3 MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNrZXQgaXMgb2sgLSBpdCByZWZs ZWN0cyB0aGUgY2xpZW50IHZlcnNpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1f MzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX19xdWljd2cuZ2l0aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRmLTJEcXVp Yy0yRHRyYW5zcG9ydC5odG1sLTIzcGFja2V0LTJEdmVyc2lvbiZhbXA7ZD1Ed01GYVEmYW1wO2M9 OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4 eWpVWmRuX201NUtQbWxvJmFtcDttPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9r Z1lkcDRfcTgmYW1wO3M9Z256OFBKNFJRTXE2dy1fV0ZhMVJIWU1UZ3BndGdJbWFrUjFxWndtX3VU ayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3F1aWN3Zy5naXRodWIuaW8vYmFzZS1k cmFmdHMvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC5odG1sI3BhY2tldC12ZXJzaW9uPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4 NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1 NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcy OTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdpdGh1Yi5pb19iYXNlLTJEZHJhZnRzX2RyYWZ0LTJEaWV0 Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRtbC0yM3BhY2tldC0yRHNlcnZlci0yRGNsZWFydGV4dCZh bXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5K RFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPW1Ya2lLS2hfRmtSTy1NQU5v MFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1wO3M9RGpXZG84WWh1OHQ3aDF6cWQ3Qkl4azlf VExVMzZBeG1kWjBEbWhabjZ2RSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3F1aWN3 Zy5naXRodWIuaW8vYmFzZS1kcmFmdHMvZHJhZnQtaWV0Zi1xdWljLXRyYW5zcG9ydC5odG1sI3Bh Y2tldC1zZXJ2ZXItY2xlYXJ0ZXh0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0 bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mcXVvdDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5UaGUgY29ubmVjdGlv biBJRCBmaWVsZCBpbiBhIFNlcnZlciBDbGVhcnRleHQgcGFja2V0IGNvbnRhaW5zIGEgY29ubmVj dGlvbiBJRCB0aGF0IGlzIGNob3NlbiBieSB0aGUgc2VydmVyIChzZWUmbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X19xdWljd2cuZ2l0aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRmLTJEcXVpYy0yRHRy YW5zcG9ydC5odG1sLTIzY29ubmVjdGlvbi0yRGlkJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpj YU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5f bTU1S1BtbG8mYW1wO209bVhraUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9x OCZhbXA7cz01U0g2dTdBYUhfYXJ4R1kzeUVlcXd5aGlvOGRUWDlTTVFXRmMyVElsaFkwJmFtcDtl PSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyQTY0OTY7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPlNlY3Rpb24NCiA1LjY8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMzMzMzMzMiPikuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3 MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGJyZWFrcyBsaW5rYWdlIHRvIHRoZSBvcmlnaW5hbCBjbGllbnQgY29u bmVjdGlvbiBpZCBzbyB0aGUgY2xpZW50IGNhbm5vdCB0ZWxsIHdoaWNoIGNvbm5lY3Rpb24gdGhl IHJlc3BvbnNlIGJlbG9uZ3MgdG8gdW5sZXNzIGxvb2tpbmcgaW50byA1LXR1cGxlLCBvciB0ZXN0 aW5nIGFsbCByZWNlbnQgY29ubmVjdGlvbnMgYWdhaW5zdCBBRUFEIHNpZ25hdHVyZSAoZGVwZW5k aW5nIG9uIHdoZXJlIHRoaXMgbGFuZHMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0 bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAw Njk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcy MDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIG5v dCBjb3ZlcmVkIGFsbCBvdGhlciBwb3NzaWJsZSBzZXJ2ZXIgcmVzcG9uc2VzLCBidXQgc2ltaWxh ciBjb25jZXJucyBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwt bV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDky NzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQg aXMgbm90IGEgbWFqb3IgY2hhbmdlLCBidXQgY3VycmVudGx5IGl0IGlzIG5vdCBwb3NzaWJsZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0 ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2 NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgaXNzdWUgaXMgaG9zdGlsZSByZXNwb25zZSB0 byBpbml0aWFsIGNvbm5lY3Rpb24gc2V0dXAsIGFuZCBwbGFpbiBlcnJvcnMgLSBob3cgdG8geW91 IHJlcGx5IHdpdGggYW4gZXJyb3IuIEhhdmluZyB0aGUgY29ubmVjdGlvbiBpZCBmcm9tIHRoZSBj bGllbnQgbWFrZXMgaXQgcmVhc29uYWJseSBlYXN5IHRvIGRlYWwgd2l0aCAtIHNpbWlsYXIgdG8g dmVyc2lvbiBuZWdvdGlhdGlvbi4gQWx0ZXJuYXRpdmVseQ0KIHlvdSBoYXZlIHRvIHJlbHkgb24g NS10dXBsZXMuIFRoaXMgcmVxdWlyZXMgY2FyZWZ1bCBhbmFseXNpcyBvZiBib3RoIHRoZSB0cmFu c3BvcnQgZG9jIGFuZCBwb3NzaWJseSBUTFMgYW5kIHRoaW5zIGFyZSBub3QgZnVsbHkgc2V0dGxl ZC4gU3RhdGVsZXNzIHJlc2V0IGlzIHJlbGF0ZWQgdG8gdGhpcy4gSSB3aWxsIG5vdCBhcmd1ZSBz dHJvbmdseSBvbiB0aGlzIGJlY2F1c2Ugc2luY2UgSSBsYXN0IGxvb2tlZCBhdCBpdCwgbmV3IEFF QUQgZW5jcnlwdGlvbg0KIGlzIGJlaW5nIGRpc2N1c3NlZCwgYW5kIEkgaGF2ZSBub3QgYW5hbHlz ZWQgdGhpcyBpbiBkZXRhaWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWls LW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5 Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4 NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2 Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVuIHRoZXJlIGlzIGNv bm5lY3Rpb24gbWlncmF0aW9uLiBUaGlzIGFsc28gcmVxdWlyZXMgY2FyZWZ1bCBhbmFseXNpcy4g SeKAmW0gbm90IHN1cmUgaWYgaXQgY3VycmVudGx5IGNvdmVycyBteSByZXF1ZXN0LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFp bC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMw OTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SeKAmW0gc3VyZSB0aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMg d2l0aCBpbXBsaWNpdCBhc3N1bXB0aW9ucyB0aGF0IEkgYW0gbm90IGFibGUgdG8gbGlzdCBvZmYg bWVtb3J5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUy MjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIy MDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21h aWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIChteSkgYmFzaWMgcnVsZSBpcyB0aGUg YW55IGNoYW5nZSBpbiBjb25uZWN0aW9uIElEIHNob3VsZCByZWZlciB0byB0aGUgcHJldmlvdXMg SUQgd2l0aG91dCByZWx5aW5nIG9uIGV4dGVybmFsIHN0YXRlIHN1Y2ggYXMgNS10dXBsZXMgb3Ig VExTIGV4dGVuc2lvbiBzdGF0ZSAod2hpY2ggcmVxdWlyZXMgY3J5cHRvIHN0YXRlIHRvIGFjY2Vz cyBhbmQgY29tcGxpY2F0ZXMgdGhpbmdzKS4gQWxzbywgZHVlIGNvbmNlcm5zDQogb2YgcHJpdmFj eSBjb25jZXJucyB0aGlzIGxpbmthZ2UgYmV0d2VlbiBjb25uZWN0aW9uIElE4oCZcyBzaG91bGQg b25seSBiZSBwb3NzaWJsZSBieSBwZWVycywgZXhjZXB0cyBmb3IgdGhlIGluaXRpYWwgY2xpZW50 IHRvIHNlcnZlciBjb25uZWN0aW9uIHRyYW5zaXRpb24gdGhhdCBpcyBhbHNvIHZpc2libGUgdG8g YW55IHBhcnR5IG9uLXBhdGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWls LW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5 Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4 NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2 Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byB0 aGUgYWJvdmUgZW5jb2RpbmcgY29uY2VybnMsIGl0IG1heSBhbHNvIGJlIGhlbHBmdWwgdG8gZXhw bGljaXRseSBzdGF0ZSB0aGF0IHRoZSBzYW1lIFVEUCBwb3J0IG1heSBiZSB1c2VkIHRvIGluaXRp YXRlIG11bHRpcGxlIGluZGVwZW5kZW50IFFVSUMgY29ubmVjdGlvbiB0byB0aGUgc2FtZSBzZXJ2 ZXIgVURQIHBvcnQgd2hlbiBjb25uZWN0aW9uIElEIGhhcyBiZWVuIG5lZ290aWF0ZWQNCiB0byBi ZSBwcmVzZW50IC0gb3IgZnVydGhlciBkZXRhaWwgdGhpcyBwb3NzaWJpbGl0eSBhcyBzb21ldGhp bmcgdGhhdCBjYW4gYmUgbmVnb3RpYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2 NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgw MDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3 MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4 NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIG90aGVyIHBvaW50cyBJIGZv cmdldCB0byBtZW50aW9uIHJlZ2FyZGluZyBiZW5lZml0cyBvZiBub24tdW5pcXVlIHR1cGxlczo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0 ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2 NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjUpIG5vIGludGVyZmVyZW5jZSB3aXRoIE9TIGlzIG5lY2Vz c2FyeSBpbiBvcmRlciB0byBlc3RhYmxpc2ggYSBuZXcgY29ubmVjdGlvbiB0byBhbiBleGlzdGlu ZyBlbmRwb2ludCBiZWNhdXNlIG5vIG5ldyBlcGhlbWVyYWwgcG9ydCBpcyBuZWVkZWQuIFRoaXMg bWF5IGFsc28gc2ltcGxpZnkgY2xlYW4gdXAgYW5kIHN0YXRlIG1hbmFnZW1lbnQsIGVzcGVjaWFs bHkgc2VydmVyIHRvIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21h aWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcx NDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIy Mjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIw MzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjYpIE5ldG1hcCBhbmQg c2ltaWxhciBoaWdoIHNwZWVkIGludGVyZmFjZXMgd291bGQgYmUgc2ltcGxlciB3aXRob3V0IGhh dmluZyB0byBkZWFsIHdpdGggZXBoZW1lcmFsIHBvcnQgYWxsb2NhdGlvbiwgZXNwZWNpYWxseSBz ZXJ2ZXIgdG8gc2VydmVyIHdoZXJlIGJvdGggZW5kIHBvaW50cyBjYW4gcmVmZXJlbmNlIGVhY2gg b3RoZXIsIGFuZCB3aGVyZSBpdCBtaWdodCBiZSByYW5kb20gd2hpY2ggZW5kcG9pbnQNCiBhY3R1 YWxseSBpbml0aWF0ZXMgdG8gdGhlIGNvbm5lY3Rpb24gKGFzIGluIENvcmQgLyBLYWRlbWxpYSBz dHlsZSBvdmVybGF5IG5ldHdvcmtzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJn bWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8z NzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1 MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQy MjAzNmJsb29wX3NpZ25fMTUwMjAyOTM4NzA1ODg1NTkzNiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdiBpZD0iZ21h aWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcx NDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e00be296557740d0ab720da79e1522e4usma1exdag1mb5msgcorpak_-- From nobody Wed Aug 9 10:33:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 259E0132449 for ; Wed, 9 Aug 2017 10:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz8qy_y9jPtT for ; Wed, 9 Aug 2017 10:33:23 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502C8132256 for ; Wed, 9 Aug 2017 10:33:23 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q25so31487290uah.1 for ; Wed, 09 Aug 2017 10:33:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=0X03jVykUlsFRON62l14i5Lrov6+rKPDlv75J3X0vq8=; b=Lm8CeiSqnuSmOqzsb/MvDBOyisAEJzHqGFlb73+iJFeMDNAmHyM7+l9vym0TZot5Er M7hhDpo9vBuXeOc7XJS/yRuZOMsHrYwNi33GZ/64SRaCcRogSJ1cvCXQdNOIIcDTbyes mLk7uFQLN6bXUyCjh9XZagWkUOE7Q3JemnCJaXw8Sq7Kj2ClQSb0pEs21cB2M73yvnCQ BghRQxwDnFYgNJhuBbCGfmk+6+ZTV3F5ykNF8kTi4EwB+2qDRD4kzI99oWc/WdzMVrMk L0aGbghaVOEwpLlqYbSCi+mt2uNi4qR39bNwsEQzx1Fi1otPqRf2eMhJ+20f4Cikl6lf ya7g== 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=0X03jVykUlsFRON62l14i5Lrov6+rKPDlv75J3X0vq8=; b=ahpdBmCUUu6P0o8hhD3N72Vn32jLJjNj2K6fWWZol2IcQy0oVa0Dxesrum13/Bu7jY okWACRFL5JbXeC1UhAKTo5dvg2AX39Pd2YB+9Ixyft7YsFdVXP7PCKKzpE0ftIdE4HLH Pjr8CYItqiO3136soAG6TMlqTCbR5nktcX1JoVBMHJw+xbHUBwzfJ6MipalMx8Ih0kw8 vJveja6T9DpY2YdEARfcPoztj+3QdHehEVK3WeRn71vZ7cygrJq92wD13v+ocE47zzQG zDPrplGUgxp3NtrhiWiIrUlpMlavJd4MN03ZGitGSfkfiJdXZR6ALPO6EObM11gIv6En R+SQ== X-Gm-Message-State: AHYfb5hN/DeZd05m/7KSLBod5C9+wtH0PP/Nedu6KQldhG6+8kxXMHoY 2y0tJRyUtLNSYsPIOChlg5SJO4kM+Q== X-Received: by 10.176.16.17 with SMTP id f17mr6203662uab.167.1502300002294; Wed, 09 Aug 2017 10:33:22 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 9 Aug 2017 10:33:21 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 9 Aug 2017 10:33:21 -0700 Message-ID: Subject: RE: 5-tuple uniquess To: "Lubashev, Igor" , Ian Swett Cc: Ryan Hamilton , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045e32e8fba3dc0556557981" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Aug 2017 17:33:27 -0000 --f403045e32e8fba3dc0556557981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This may not address all your concerns, but I think perhaps you are looking at the problem from the wrong end with respect to ephemeral port exhaustion= : In a typical NAT scenario you have many clients reaching for one server, each client likely passing a different NAT. Hence each connection will be a unique 5-tuple, even if QUIC itself is not making any effort to achieve this. Now, if one of these clients creates two connections to the same server and chooses to reuse the outbound UDP port number, say reaching for two different images, then the NAT might think that the two connections are the same connection. And in some sense it is - not the same QUIC connection, but the same operational context. Thus, the two connections helps reduce NAT overhead and also cooperates in keeping the NAT hole open. On the other end, at the server, there is a separate problem: The server (S) does not have the requested images. It reaches to one of a few possible backend servers (B1, B2). Since the server S is not attempting to be clever, it creates a new QUIC connection from S to B1 or B2 for each inbound client connection. There may or may not be any NAT involved here, but the server S is only assigned a single IP address for outbound requests and cannot create more concurrent connections that the number of ephemeral ports + safety margin permits, that is, unless it chooses to reuse outbound port numbers which solves the problem of port exhaustion. If, on the other hand, a QUIC client were co-located with other services, it might not be able to receive the correct packets when these different services compete for port numbers. But here it suffice that they either agree to use different ports (like PING vs. DNS), or each service allocate a single ephemeral port for its service via UDP socket creation. In either case the NAT would route packets to the correct service by relying on 5-tuples even if QUIC itself does not. So, going further - what if several hosts use the same IP address, as is the case with load balancers? Again, 5-tuples are used to bind connections to each unique host, only with fewer UDP ports there is much less state to maintain. The middleware only need to route traffic to the correct endpoint, not distinguish between logical QUIC connections that happen between the same two entities. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote: Can someone elaborate on =E2=80=9CPossibly it should specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters?=E2=80=9D Is that only for =E2=80=9CServer Cleartext=E2=80=9D? What about connections= that start out with 0RTT packets =E2=80=93 how would the NAT know which flow Server=E2=80= =99s 1RTT reply belongs to (if Server changes the ConenctionID)? Maybe relying on a 5-tuple is not such a bad idea after all? A NAT does not need a different ephemeral port for every outgoing connection. It only needs a different ephemeral port for outgoing connections to the same IP. Even then, if the NAT is willing to do something special for QUIC, it can be a much simpler thing than examine QUIC transport params. The NAT can simply reserve a single ephemeral port for all 1RTT QUIC packets. That is, all outgoing cleartext and 0rtt QUIC packets would require a distinct 5-tuple, but once the connection migrates to 1RTT, the ephemeral port it used can be freed, and all 1RTT packets sourced from the reserved QIUC port. That would work, since all 1RTT packets (both from client and server) would be using Server-selection ConnectionID. - Igor *From:* Ian Swett [mailto:ianswett@google.com] *Sent:* Tuesday, August 08, 2017 7:01 PM *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen *Cc:* IETF QUIC WG ; Ryan Hamilton *Subject:* Re: 5-tuple uniquess You're right, ephemeral port exhaustion is a very real potential issue, and I think we should ensure multiple QUIC connections can run over the same 5-tuple and we don't specify QUIC in a way that precludes that. I believe you're correct that the current Server Cleartext makes this impossible if the server changes the connection ID. Possibly it should specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters? https://github.com/quicwg/base-drafts/issues/714 The text is also missing some details on how changing the connection ID should work for Stateless Retry, see https://github.com/quicwg/base-drafts/issues/713 , so I'd expect some improvements in the near future. On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: Hi Ryan, I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is: The version negotiation packet is ok - it reflects the client version https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= version But https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-= server-cleartext "The connection ID field in a Server Cleartext packet contains a connection ID that is chosen by the server (see Section 5.6 )." This breaks linkage to the original client connection id so the client cannot tell which connection the response belongs to unless looking into 5-tuple, or testing all recent connections against AEAD signature (depending on where this lands). I have not covered all other possible server responses, but similar concerns apply. It is not a major change, but currently it is not possible. Another issue is hostile response to initial connection setup, and plain errors - how to you reply with an error. Having the connection id from the client makes it reasonably easy to deal with - similar to version negotiation. Alternatively you have to rely on 5-tuples. This requires careful analysis of both the transport doc and possibly TLS and thins are not fully settled. Stateless reset is related to this. I will not argue strongly on this because since I last looked at it, new AEAD encryption is being discussed, and I have not analysed this in detail. Then there is connection migration. This also requires careful analysis. I=E2=80=99m not sure if it currently covers my request. I=E2=80=99m sure there are several other places with implicit assumptions t= hat I am not able to list off memory. The (my) basic rule is the any change in connection ID should refer to the previous ID without relying on external state such as 5-tuples or TLS extension state (which requires crypto state to access and complicates things). Also, due concerns of privacy concerns this linkage between connection ID=E2=80=99s should only be possible by peers, excepts for the i= nitial client to server connection transition that is also visible to any party on-path. In addition to the above encoding concerns, it may also be helpful to explicitly state that the same UDP port may be used to initiate multiple independent QUIC connection to the same server UDP port when connection ID has been negotiated to be present - or further detail this possibility as something that can be negotiated. Some other points I forget to mention regarding benefits of non-unique tuples: 5) no interference with OS is necessary in order to establish a new connection to an existing endpoint because no new ephemeral port is needed. This may also simplify clean up and state management, especially server to server. 6) Netmap and similar high speed interfaces would be simpler without having to deal with ephemeral port allocation, especially server to server where both end points can reference each other, and where it might be random which endpoint actually initiates to the connection (as in Cord / Kademlia style overlay networks) Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --f403045e32e8fba3dc0556557981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
This may not address all your concerns, but I thi= nk perhaps you are looking at the problem from the wrong end with respect t= o ephemeral port exhaustion:

In a typical NAT scenario you have many clients reaching for one se= rver, each client likely passing a different NAT.
Hence each connection will be a unique= 5-tuple, even if QUIC itself is not making any effort to achieve this.

Now, if one of these cli= ents creates two connections to the same server and chooses to reuse the ou= tbound UDP port number, say reaching for two different images, then the NAT= might think that the two connections are the same connection. And in some = sense it is - not the same QUIC connection, but the same operational contex= t. Thus, the two connections helps reduce NAT overhead and also cooperates = in keeping the NAT hole open.

On the other end, at the server, there is a separate problem: The = server (S) does not have the requested images. It reaches to one of a few p= ossible backend servers (B1, B2). Since the server S is not attempting to b= e clever, it creates a new QUIC connection from S to B1 or B2 for each inbo= und client connection. There may or may not be any NAT involved here, but t= he server S is only assigned a single IP address for outbound requests and = cannot create more concurrent connections that the number of ephemeral port= s + safety margin permits, that is, unless it chooses to reuse outbound por= t numbers which solves the problem of port exhaustion.

If, on the other hand, a QUIC client were= co-located with other services, it might not be able to receive the correc= t packets when these different services compete for port numbers. But here = it suffice that they either agree to use different ports (like PING vs. DNS= ), or each service allocate a single ephemeral port for its service via UDP= socket creation. In either case the NAT would route packets to the correct= service by relying on 5-tuples even if QUIC itself does not.

So, going further - what if sever= al hosts use the same IP address, as is the case with load balancers? Again= , 5-tuples are used to bind connections to each unique host, only with fewe= r UDP ports there is much less state to maintain. The middleware only need = to route traffic to the correct endpoint, not distinguish between logical Q= UIC connections that happen between the same two entities.

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


On 9 August 2017 at 19.0= 3.35, Lubashev, Igor (ilubashe@akama= i.com) wrote:

Can someone elaborate on =E2=80=9CPossibly it shoul= d specify the client's connection ID in the packet header and then the = new server connection ID in the transport parameters?=E2=80=9D

=C2=A0

Is that only for =E2=80=9CServer Cleartext=E2=80=9D= ? What about connections that start out with 0RTT packets =E2=80=93 how wou= ld the NAT know which flow Server=E2=80=99s 1RTT reply belongs to (if Serve= r changes the ConenctionID)?

=C2=A0

Maybe relying on a 5-tuple is not such a bad idea a= fter all?=C2=A0 A NAT does not need a different ephemeral port for every ou= tgoing connection.=C2=A0 It only needs a different ephemeral port for outgoing connections to the same IP.

=C2=A0

Even then, if the NAT is willing to do something sp= ecial for QUIC, it can be a much simpler thing than examine QUIC transport = params.=C2=A0 The NAT can simply reserve a single ephemeral port for all 1RTT QUIC packets.=C2=A0 That is, all outgoing cleartext and = 0rtt QUIC packets would require a distinct 5-tuple, but once the connection= migrates to 1RTT, the ephemeral port it used can be freed, and all 1RTT pa= ckets sourced from the reserved QIUC port.=C2=A0 That would work, since all 1RTT packets (both from client and = server) would be using Server-selection ConnectionID.

=C2=A0

  • Igor
    • <= /ul>

    =C2=A0

    =C2=A0

    =C2=A0

    From: Ian Swett [mailto:ianswett@google.com]
    Sent: Tuesday, August 08, 2017 7:01 PM
    To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
    Cc: IETF QUIC WG <quic@ietf.org<= /a>>; Ryan Hamilton <rch@google.com= >
    Subject: Re: 5-tuple uniquess

    =C2=A0

    You're right, ephemeral port exhaustion is a ver= y real potential issue, and I think we should ensure multiple QUIC connecti= ons can run over the same 5-tuple and we don't specify QUIC in a way th= at precludes that.

    =C2=A0

    I believe you're correct that the current Server= Cleartext makes this impossible if the server changes the connection ID.= =C2=A0 Possibly it should specify the client's connection ID in the pac= ket header and then the new server connection ID in the transport parameters?=C2=A0 https://github.com/quicwg/base-drafts/issues/714

    =C2=A0

    The text is also missing some details on how changin= g the connection ID should work for Stateless Retry, see=C2=A0https://github.com/quicwg/base-drafts/issues/713<= /a>, so I'd expect some improvements in the near future.

    =C2=A0

    On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e = J=C3=B8rgensen <= mikkelfj@gmail.com> wrote:

    =C2=A0

    Hi Ryan,

    =C2=A0

    I can dig down in more detail if there is interest. = Meanwhile, some examples where the transport document is not compatible wit= h my request is:

    =C2=A0

    The version negotiation packet is ok - it reflects t= he client version

    https://quicwg.github.io/base-drafts/draft-i= etf-quic-transport.html#packet-version

    =C2=A0

    But=C2=A0

    https://quicwg.github.io/base-dra= fts/draft-ietf-quic-transport.html#packet-server-cleartext

    "The connection ID field in a = Server Cleartext packet contains a connection ID that is chosen by the serv= er (see=C2=A0Section 5.6)."

    This breaks linkage to the original client connectio= n id so the client cannot tell which connection the response belongs to unl= ess looking into 5-tuple, or testing all recent connections against AEAD si= gnature (depending on where this lands).

    =C2=A0

    I have not covered all other possible server respons= es, but similar concerns apply.

    It is not a major change, but currently it is not po= ssible.

    =C2=A0

    Another issue is hostile response to initial connect= ion setup, and plain errors - how to you reply with an error. Having the co= nnection id from the client makes it reasonably easy to deal with - similar= to version negotiation. Alternatively you have to rely on 5-tuples. This requires careful analysis of both the t= ransport doc and possibly TLS and thins are not fully settled. Stateless re= set is related to this. I will not argue strongly on this because since I l= ast looked at it, new AEAD encryption is being discussed, and I have not analysed this in detail.

    =C2=A0

    Then there is connection migration. This also requir= es careful analysis. I=E2=80=99m not sure if it currently covers my request= .

    =C2=A0

    I=E2=80=99m sure there are several other places with= implicit assumptions that I am not able to list off memory.

    =C2=A0

    The (my) basic rule is the any change in connection = ID should refer to the previous ID without relying on external state such a= s 5-tuples or TLS extension state (which requires crypto state to access an= d complicates things). Also, due concerns of privacy concerns this linkage between connection ID=E2=80=99s should on= ly be possible by peers, excepts for the initial client to server connectio= n transition that is also visible to any party on-path.

    =C2=A0

    In addition to the above encoding concerns, it may a= lso be helpful to explicitly state that the same UDP port may be used to in= itiate multiple independent QUIC connection to the same server UDP port whe= n connection ID has been negotiated to be present - or further detail this possibility as something that can b= e negotiated.

    =C2=A0

    =C2=A0

    Some other points I forget to mention regarding bene= fits of non-unique tuples:

    =C2=A0

    5) no interference with OS is necessary in order to = establish a new connection to an existing endpoint because no new ephemeral= port is needed. This may also simplify clean up and state management, espe= cially server to server.

    =C2=A0

    6) Netmap and similar high speed interfaces would be= simpler without having to deal with ephemeral port allocation, especially = server to server where both end points can reference each other, and where = it might be random which endpoint actually initiates to the connection (as in Cord / Kademlia style overlay = networks)

    =C2=A0

    Kind Regards,

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

    =C2=A0

    =C2=A0

--f403045e32e8fba3dc0556557981-- From nobody Wed Aug 9 15:00:33 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D0913226B for ; Wed, 9 Aug 2017 15:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] 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 qOVEq3b7PSWo for ; Wed, 9 Aug 2017 15:00:29 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B450132195 for ; Wed, 9 Aug 2017 15:00:29 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id v189so33211205pgd.2 for ; Wed, 09 Aug 2017 15:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=iM+YByK8WypJuotCP099lWOwuXtxBdfW0ZkPchKOgl4=; b=twLyXy7JQ5TRuwU2pCQBim7kH/siszVhV8t/v1hL0A5etWRaq2IcFSGkCz0VPqp4+U O7e6c2OnirPmiSDwsaPtpp3C9i4n+9lzMLAsivOR4y0lTuAMkN07mfXPWfAjPdIxI0Oi vxTblHbuCsrFHWclp3BvHgpEo/3gy8XB3IciLXJA0CytfNOqa1RamnhM6PDqHJ+xuBcr dya3RkOEPj5Raz20Seys/tPteF6TUzQRwtgX3/VOVbbA7+lIgrkLT67r9vBYDy4xuJ0x XMbo3sq+uo6/JFZzggVaT4k1v+oa/CAOGG9E7QrWyeTtTEhp1KU4ueYe3ko5zk0LwQmr APyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=iM+YByK8WypJuotCP099lWOwuXtxBdfW0ZkPchKOgl4=; b=sJ8hmeofkpHqdsqBRinhiGQnXrL95O0myFL9GDa1IFy5taapwcAACoiGXF/KJpEAa8 YH6Ec5qiWSyeN6oaNsY5L9xfTGJabLuQotkHAPz5jfPgjS7RGcscNOfSh05dcg0B2pNN VFbwBn/wPh/ncGcjXxrrz+l28k5JpudVluO8uX0+YyQgXADny17sDqp8Ix4CzuL0YTnG k69ibJvhBF73Muz121zoXet/7SezZHUUwmWq7BdVoTS4vcA5EwM0dX9OuII/yanV6QVx tuID+EnMydEBpGdYWJrTbyCDIffJEb27t/Arx27Lx+yZ0mwUJ/XjGkRBtTDOgFAxL9FP OXBQ== X-Gm-Message-State: AHYfb5g2FMr/AHLaW11nj5dD3j871KnxIrfQ6JVmnuuIs9RMNB5cqpYV PK82tyySiGziy5f7gLOK5fhxJ+HXh1JY X-Received: by 10.99.109.77 with SMTP id i74mr9590128pgc.438.1502316028357; Wed, 09 Aug 2017 15:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.162 with HTTP; Wed, 9 Aug 2017 15:00:27 -0700 (PDT) From: Jana Iyengar Date: Wed, 9 Aug 2017 15:00:27 -0700 Message-ID: Subject: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Martin Thomson , Mike Bishop Cc: Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="f403045c066036a1b20556593591" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 09 Aug 2017 22:00:32 -0000 --f403045c066036a1b20556593591 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it's useful to avoid HoLB since the first request and the MAX_PUSH_ID frame may get reordered and/or the MAX_PUSH_ID frame may need retransmission. Push is already weak on benefits, so (without any evidence) I wonder whether any benefits due to it would be sensitive to this small variation. That said, this isn't a strong opinion, so I'm not going to argue for it. - jana On Wed, Aug 9, 2017 at 9:15 AM, Mike Bishop wrote: > Agreed that the SETTINGS entry and the frame are the same 5-8 bytes > consumed, and it would be simpler to have a single code path. Since this > whole thing is a departure from HTTP/2, I=E2=80=99m not personally upset = about > diverging a little further in the name of simpler code. This isn=E2=80= =99t a value > that either party needs to know before sending traffic to behave properly= , > which is the case with QUIC=E2=80=99s limits of this type that have the d= ual > parameter/frame structure. > > > > *From:* Martin Thomson [mailto:martin.thomson@gmail.com] > *Sent:* Tuesday, August 8, 2017 5:45 PM > *To:* Jana Iyengar > *Cc:* Ian Swett ; Kazuho Oku ; > QUIC WG ; ietf-http-wg@w3.org; Mike Bishop < > Michael.Bishop@microsoft.com> > *Subject:* Re: Push ID - Merge Imminent > > > > Just to follow up on this, I've opened https://github.com/quicwg/ > base-drafts/pull/711 > > > > > It defines a new frame type that sets the limit to Push ID. In a fit of > inspiration, I called it MAX_PUSH_ID. > > > > I have repurposed SETTINGS_ENABLE_PUSH for setting the initial limit. Th= e > newly renamed SETTINGS_MAX_PUSH_ID sets the initial MAX_PUSH_ID. > > > > I want to discuss whether we might remove the setting. Sending > MAX_PUSH_ID immediately after SETTINGS doesn't add any more bytes and I'm > not sure that there is any particular need to optimize for HoLB here. I'= m > ambivalent, so I kept it, but it is easy to remove. > > > > > > On 5 August 2017 at 10:55, Jana Iyengar wrote: > > Martin, > > > > I think the idea of sequential Push ID is a good one. You have to specify > a MAX_PUSH_ID, without which the client won't know how far out to expect > CANCEL_PUSHes can be... this also requires then a MAX_PUSH_ID_UPDATE > message which can be used to move the MAX up. > > > > One note: > > > > PUSH_PROMISE is sent by the server, and CANCEL_PUSH may be sent by the > server. The text currently says that CANCEL_PUSH on a non-existent Push I= D > results in error, which does not work with the possibility of reordering > between PUSH_PROMISE and CANCEL_PUSH. > > > > That's just a bug. > > > > I don't think so. The spec allows it, and I can easily see it happen in > practice. > > > > - jana > > > > > > Similarly, it's also possible for the PUSH_PROMISE to not have been > received because the stream on which it was sent was reset... basically > it's possible for a client to receive a CANCEL_PUSH without seeing the > corresponding PUSH_PROMISE. > > > > This is more interesting. It creates state on the client: it says that > clients are required to ignore pushes that it *might* receive in the > future. That suggests a different fix, akin to what we use for other > similar pieces of state: > > > > 1. make Push ID sequential (right now the only requirement is for > connection-wide uniqueness) > > > > I think that using a sequential ID will be a good idea not only for fixin= g > this issue but that it might be possible to use the sequentiality to fix > the first issue raised in the PR (i.e. client knowing "when the server wi= ll > stop referencing a push ID in PUSH_PROMISE"). > > > > If there is a sequential ordering guarantee for Push ID, a client can, by > looking at the Push ID, determine whether if it has already consumed the > pushed request. If it has, it will immediately lookup its cache, and in > case it fails to find a cached object, then issue a pull. If it has not > consumed the pushed request, it should wait for the pushed response to > arrive. > > > > > > > > 2. have the client advertise a MAX_PUSH_ID (in SETTINGS, and with a new > frame type; the setting might {ab|re}use ENABLE_PUSH) > > > > This would bound state for clients. A client couldn't receive an > arbitrary number of CANCEL_PUSH messages that are distributed over the > 32-bit Push ID space, so tracking cancellations is easy. Clients could u= se > a simple bitvector to track which pushes are potentially interesting, > clearing bits as pushes or cancellations arrive. > > > > MAX_PUSH_ID would give clients a finer-grained lever to control push. > > > > We could have CANCEL_PUSH be sent on the same streams as the PUSH_PROMISE= , > but that doesn't help with the case where the PUSH_PROMISE may not have > been received due to a stream reset. > > > > This makes me wonder if it makes sense to always send the PUSH_PROMISE on > the control stream *in addition to* any stream that it is sent on. This > would ensure that no matter what, the PUSH_PROMISE is always received, an= d > additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE. > > > > I don't think that is a good idea. PUSH_PROMISE includes a headers block= , > which is pretty big, even with effective compression. HoLB won't affect > this stream, so size shouldn't be an issue, but still. > > > > I did consider moving the header block to the control stream completely a= s > part of addressing the issue with duplication that I mentioned earlier. > The basic problem there is that you don't guarantee that the client see t= he > PUSH_PROMISE before it processes the response content. > > > > > > - jana > > > > On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop > wrote: > > Bah, QUIC too. =F0=9F=98=8A > > > > *From:* Mike Bishop [mailto:Michael.Bishop@microsoft.com] > *Sent:* Thursday, August 3, 2017 10:36 AM > *To:* ietf-http-wg@w3.org > *Subject:* Push ID - Merge Imminent > > > > This is Martin=E2=80=99s Push ID PR split off from unidirectional. Given= that it > has already been picked over in those contexts and the feedback from that > and in-person discussion was to bring this change in separately, I=E2=80= =99m about > ready to merge this. Everything anyone has quibbled with has been > editorial. However, I don=E2=80=99t see reviews from many folks, so I wa= nt to make > sure that everyone interested has had a chance to express an opinion. > > > > https://github.com/quicwg/base-drafts/pull/701 > > > > > I=E2=80=99ll give it a few hours (until everyone=E2=80=99s had at least a= little bit of a > work day), then merge unless I hear otherwise. > > > > > > > > > -- > > Kazuho Oku > > > > > > > --f403045c066036a1b20556593591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's useful to avoid HoLB since the first requ= est and the MAX_PUSH_ID frame may get reordered and/or the MAX_PUSH_ID fram= e may need retransmission. Push is already weak on benefits, so (without an= y evidence) I wonder whether any benefits due to it would be sensitive to t= his small variation.

That said, this isn't a strong = opinion, so I'm not going to argue for it.

- j= ana

On Wed, Au= g 9, 2017 at 9:15 AM, Mike Bishop <Michael.Bishop@microsoft.com= > wrote:

Agreed that the SETTINGS entry and the frame are the= same 5-8 bytes consumed, and it would be simpler to have a single code pat= h.=C2=A0 Since this whole thing is a departure from HTTP/2, I=E2=80=99m not= personally upset about diverging a little further in the name of simpler code.=C2=A0 This isn=E2=80=99t a value that either = party needs to know before sending traffic to behave properly, which is the= case with QUIC=E2=80=99s limits of this type that have the dual parameter/= frame structure.

= =C2=A0

From: Martin Thomson [mailto:martin.thomson@gmail.com= ]
Sent: Tuesday, August 8, 2017 5:45 PM
To: Jana Iyengar <jri@google.com>
Cc: Ian Swett <ianswett@google.com>; Kazuho Oku <kazuhooku@gmail.com>; QUIC WG <<= a href=3D"mailto:quic@ietf.org" target=3D"_blank">quic@ietf.org>; ietf-http-wg@w3.org<= /a>; Mike Bishop <Michael.Bishop@microsoft.com>
Subject: Re: Push ID - Merge Imminent

=C2=A0

Just to follow up on this, I've opened https://github.com/quicwg/base-drafts/pull/711

=C2=A0

It defines a new frame type that sets the limit to P= ush ID.=C2=A0 In a fit of inspiration, I called it MAX_PUSH_ID.

=C2=A0

I have repurposed SETTINGS_ENABLE_PUSH for setting t= he initial limit.=C2=A0 The newly renamed SETTINGS_MAX_PUSH_ID sets the ini= tial MAX_PUSH_ID.

=C2=A0

I want to discuss whether we might remove the settin= g.=C2=A0 Sending MAX_PUSH_ID immediately after SETTINGS doesn't add any= more bytes and I'm not sure that there is any particular need to optim= ize for HoLB here.=C2=A0 I'm ambivalent, so I kept it, but it is easy to remove.

=C2=A0

=C2=A0

On 5 August 2017 at 10:55, Jana Iyengar <jri@google.com> wrote:<= u>

Martin,

=C2=A0

I think the idea of sequential Push ID is a good one= . You have to specify a MAX_PUSH_ID, without which the client won't kno= w how far out to expect CANCEL_PUSHes can be... this also requires then a M= AX_PUSH_ID_UPDATE message which can be used to move the MAX up.

=C2=A0

One note:

=C2=A0

PUSH_PROMISE is sent by the server, and CANCEL_PUSH = may be sent by the server. The text currently says that CANCEL_PUSH on a no= n-existent Push ID results in error, which does not work with the possibili= ty of reordering between PUSH_PROMISE and CANCEL_PUSH.

=C2=A0

That's just a bug.

=C2=A0

I don't think so. The spec allows it, and I can = easily see it happen in practice.

=C2=A0

- jana

=C2=A0

=C2=A0

Similarly, it's also possible for the PUSH_PROMI= SE to not have been received because the stream on which it was sent was re= set... basically it's possible for a client to receive a CANCEL_PUSH wi= thout seeing the corresponding PUSH_PROMISE.

=C2=A0

This is more interesting.=C2=A0 It creates state on = the client:=C2=A0 it says that clients are required to ignore pushes that i= t *might* receive in the future.=C2=A0 That suggests a different fix, akin = to what we use for other similar pieces of state:

=C2=A0

1. make Push ID sequential (right now the only requi= rement is for connection-wide uniqueness)

=C2=A0

I think that using a sequential ID will be a good id= ea not only for fixing this issue but that it might be possible to use the = sequentiality to fix the first issue raised in the PR (i.e. client knowing = "when the server will stop referencing a push ID in PUSH_PROMISE").

=C2=A0

If there is a sequential ordering guarantee for Push= ID, a client can, by looking at the Push ID, determine whether if it has a= lready consumed the pushed request. If it has, it will immediately lookup i= ts cache, and in case it fails to find a cached object, then issue a pull. If it has not consumed the pushed= request, it should wait for the pushed response to arrive.

=C2=A0

=C2=A0

=C2=A0

2. have the client advertise a MAX_PUSH_ID (in SETTI= NGS, and with a new frame type; the setting might {ab|re}use ENABLE_PUSH)

=C2=A0

This would bound state for clients.=C2=A0 A client c= ouldn't receive an arbitrary number of CANCEL_PUSH messages that are di= stributed over the 32-bit Push ID space, so tracking cancellations is easy.= =C2=A0 Clients could use a simple bitvector to track which pushes are potentially interesting, clearing bits as pushes or cance= llations arrive.

=C2=A0

MAX_PUSH_ID would give clients a finer-grained lever= to control push.

=C2=A0

We could have CANCEL_PUSH be sent on the same stream= s as the PUSH_PROMISE, but that doesn't help with the case where the PU= SH_PROMISE may not have been received due to a stream reset.<= /p>

=C2=A0

This makes me wonder if it makes sense to always sen= d the PUSH_PROMISE on the control stream *in addition to* any stream that i= t is sent on. This would ensure that no matter what, the PUSH_PROMISE is al= ways received, and additionally ensures that CANCEL_PUSH is received after a PUSH_PROMISE.

=C2=A0

I don't think that is a good idea.=C2=A0 PUSH_PR= OMISE includes a headers block, which is pretty big, even with effective co= mpression.=C2=A0 HoLB won't affect this stream, so size shouldn't b= e an issue, but still.

=C2=A0

I did consider moving the header block to the contro= l stream completely as part of addressing the issue with duplication that I= mentioned earlier.=C2=A0 The basic problem there is that you don't gua= rantee that the client see the PUSH_PROMISE before it processes the response content.

=C2=A0

=C2=A0

- jana

=C2=A0

On Thu, Aug 3, 2017 at 5:49 PM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

Bah, QUIC too.=C2=A0 =F0=9F=98= =8A

=C2=A0

From: Mike Bishop [mailto:Michael.Bishop@microsof= t.com]
Sent: Thursday, August 3, 2017 10:36 AM
To: ietf-ht= tp-wg@w3.org
Subject: Push ID - Merge Imminent

=C2=A0

This is Martin=E2=80=99s Push ID PR split off from u= nidirectional.=C2=A0 Given that it has already been picked over in those co= ntexts and the feedback from that and in-person discussion was to bring this change in separately, I=E2=80=99m about ready to merge this.= =C2=A0 Everything anyone has quibbled with has been editorial.=C2=A0 Howeve= r, I don=E2=80=99t see reviews from many folks, so I want to make sure that= everyone interested has had a chance to express an opinion.<= /p>

=C2=A0

https://github.com/quicwg/base-dra= fts/pull/701

=C2=A0

I=E2=80=99ll give it a few hours (until everyone=E2= =80=99s had at least a little bit of a work day), then merge unless I hear = otherwise.

=C2=A0

=C2=A0




--

Kazuho Oku

=C2=A0

=C2=A0

=C2=A0


--f403045c066036a1b20556593591-- From nobody Wed Aug 9 17:11:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6CF131CE6 for ; Wed, 9 Aug 2017 17:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H7He94PRCpe for ; Wed, 9 Aug 2017 17:11:08 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350F0126C2F for ; Wed, 9 Aug 2017 17:11:08 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g71so3947488ioe.5 for ; Wed, 09 Aug 2017 17:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=07n78fqwLduiIGNOvrBtMvvz0O+C3dfoewkZ76CQotU=; b=eiIu/l5as7uxBcMU6iU4KEAXA/V5Nt2JRVNg9i8FuiRJPk0mZ38JNE3a28099igu8Y OYfkATng4s5X6m8aPj0Le9wIpzpG8We9sFHSVufYeLdhwzI0RxbyqqKucO/99A8wCwSB BcAJ9Mw1VoJGy6EhrmlPv+Bbo9BHUVKFiPn0ePvfDIWZzRiJV9kiJ2VMh+o8QhgaOrlf +ZcfLhYyfRcP7yuR/jIOKml68snyQhcpc8O2httTaSrWMOUxF8iRORTADENibUEKawNj IVUivUc/gaLTJiiwi+zD8vKXeK4arVqZvHvg8o3NwXdLw4PzcScxBSuLLa8mPAK+L/Ru z5Wg== 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=07n78fqwLduiIGNOvrBtMvvz0O+C3dfoewkZ76CQotU=; b=BF/WX+CSY0vCeQCVt9G3RidbC4YRsXkIZf9EN6XS78La+cd7WrFQIIe+bJeYpXOOm6 2XPJz/TlhuqtPPV3P37DdLMqjl3LXLTzvPrxz32kF14ZNJ84AJ8d0sOcx9oZ4EoHMIU4 TP7zMKoiPKrtyUkz3iEJwMZyLjQSjnV3hFNIeOmfvd6anqp6lRpKnBHT3KMriBG/lHZW IlcDhvSPN47QcoGjBx/n99VwtJH3UZNikCd/wnuHeGmsxnDoLuWki4O7h4GhbJPyfP3c +vpjkCj/xdIuk7YmunfwQj8oiCWoT2ZCduLl+NHkBZUgMpl+tC1U5XVzbo8oTS3rCiKZ 1+HA== X-Gm-Message-State: AHYfb5jdXBN6h3FpXPYNiCQqBGAR5ntOqLUa3wI03+rbRFlRFYoJkkmn vdlGo5DuR9DotuRD+H8CCa6SyCsq7w== X-Received: by 10.107.201.65 with SMTP id z62mr9296631iof.74.1502323867602; Wed, 09 Aug 2017 17:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 9 Aug 2017 17:11:07 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Aug 2017 10:11:07 +1000 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Jana Iyengar Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="94eb2c0b8afe7756a205565b08e8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 00:11:10 -0000 --94eb2c0b8afe7756a205565b08e8 Content-Type: text/plain; charset="UTF-8" On 10 August 2017 at 08:00, Jana Iyengar wrote: > I think it's useful to avoid HoLB since the first request and the > MAX_PUSH_ID frame may get reordered and/or the MAX_PUSH_ID frame may need > retransmission. Push is already weak on benefits, so (without any evidence) > I wonder whether any benefits due to it would be sensitive to this small > variation. > I was going to make exactly the same point, but then I realized that you can't push without SETTINGS anyway and that has the exact same properties. --94eb2c0b8afe7756a205565b08e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On 1= 0 August 2017 at 08:00, Jana Iyengar <jri@google.com> wrote:
I think it's useful to= avoid HoLB since the first request and the MAX_PUSH_ID frame may get reord= ered and/or the MAX_PUSH_ID frame may need retransmission. Push is already = weak on benefits, so (without any evidence) I wonder whether any benefits d= ue to it would be sensitive to this small variation.
=

I was going to make exactly the same point, but then I = realized that you can't push without SETTINGS anyway and that has the e= xact same properties.

--94eb2c0b8afe7756a205565b08e8-- From nobody Wed Aug 9 17:21:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED356132024 for ; Wed, 9 Aug 2017 17:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuI1-YZM0T4v for ; Wed, 9 Aug 2017 17:21:01 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABBE126C2F for ; Wed, 9 Aug 2017 17:21:01 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id v189so34327611pgd.2 for ; Wed, 09 Aug 2017 17:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GvORjEpcf9wV24hJIwyyMKqwBTtWa8VoKea2mXf5MMM=; b=NqkDzgpueDqPkhT0fvzV7kXK0IfV0VFWmrdX0zOlkcXBsiitIE16VyFDZI+i7ODDD3 EWKEF4ui9pDbcUMAlLYJgOsjv4YqWYaPj/GOmspHLXXoHcqvkeWnRYjdQSgtB2nWGDEF OQCLlnNIhNupU9FbvU+1aMqXhwaUdxZhbMm/VAXxZqrksXgmk1FowRj4plCqffYOqqpl Eo65Zak2Fz78XDFEtlSC5IciJvl89GxxlaTM47zUV9xJahZ+AqlFSzgoffrv1x55dfTu S+EfAmPiecqVQ//+/Ez1KcpuUrRtJiBkfsT/foe37O/PGKYiV9nm/Ykil1SA/8FiMCOY 5olA== 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=GvORjEpcf9wV24hJIwyyMKqwBTtWa8VoKea2mXf5MMM=; b=XJxrOoez+O2V0tkazOpsjoMWdgMu9FQ6kRS+aUQ5x9KXscfeA6oN0SSsfgUOCJCBfZ CrB+FG8F25QnyobG/bdDW8DRrXXEmWTm0fpE0BHnjjhyQwlxjSIHgGymMmQmy/EBnoiU tMXuVgbsC5DhhAxiFq1BrUsy+nlwMCLqdujdXm46qp3GTjhmsazhWWvKTRNAHLKqglAZ H/0ydRdwUFDrkmutEVm6hp5k+90ApjiaM1rLIiRpX0HE6FwJ6hwg82CzftbW4QlNXtJo IkcNhTaORVMdk0s2pjXuFmj5rsbIAxRXHpD/li7Y03RpL5CRLFabA6cSgcF/ulGKl+wY D5ug== X-Gm-Message-State: AHYfb5gCSHVaVc8szJXECKZB6DSsKCmyGcMOgG2Dy3Og766hN4dcKuvP yhTTe87W8N5dIqt0mNVC7q+QqM0yerNJ X-Received: by 10.84.191.131 with SMTP id a3mr11092003pld.182.1502324460388; Wed, 09 Aug 2017 17:21:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.162 with HTTP; Wed, 9 Aug 2017 17:20:59 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 9 Aug 2017 17:20:59 -0700 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Martin Thomson Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="94eb2c188024cd28c905565b2b97" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 00:21:03 -0000 --94eb2c188024cd28c905565b2b97 Content-Type: text/plain; charset="UTF-8" I've assumed that without SETTINGS, you couldn't really send a request anyways, so that was basically necessary HoLB. This introduces another frame that can cause additional HoLB. Though you could easily make the argument that we'd expect SETTINGS and the first MAX_PUSH_ID frame to be sent in the same packet. On Wed, Aug 9, 2017 at 5:11 PM, Martin Thomson wrote: > On 10 August 2017 at 08:00, Jana Iyengar wrote: > >> I think it's useful to avoid HoLB since the first request and the >> MAX_PUSH_ID frame may get reordered and/or the MAX_PUSH_ID frame may need >> retransmission. Push is already weak on benefits, so (without any evidence) >> I wonder whether any benefits due to it would be sensitive to this small >> variation. >> > > I was going to make exactly the same point, but then I realized that you > can't push without SETTINGS anyway and that has the exact same properties. > > --94eb2c188024cd28c905565b2b97 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've assumed that without SETTINGS, you couldn't r= eally send a request anyways, so that was basically necessary HoLB. This in= troduces another frame that can cause additional HoLB.=C2=A0

=
Though you could easily make the argument that we'd expect SETTING= S and the first MAX_PUSH_ID frame to be sent in the same packet.

On Wed, Aug 9, 2= 017 at 5:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 August 2= 017 at 08:00, Jana Iyengar <jri@google.com> wrote:
I think it's useful to avoid HoL= B since the first request and the MAX_PUSH_ID frame may get reordered and/o= r the MAX_PUSH_ID frame may need retransmission. Push is already weak on be= nefits, so (without any evidence) I wonder whether any benefits due to it w= ould be sensitive to this small variation.

<= /div>
I was going to make exactly the same point, but then I rea= lized that you can't push without SETTINGS anyway and that has the exac= t same properties.


--94eb2c188024cd28c905565b2b97-- From nobody Wed Aug 9 17:36:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2735132139 for ; Wed, 9 Aug 2017 17:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_aAQjiZq9ns for ; Wed, 9 Aug 2017 17:36:45 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A39F13209D for ; Wed, 9 Aug 2017 17:36:45 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id 76so5935086ith.0 for ; Wed, 09 Aug 2017 17:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g+pOm1E9TbsqCGBIimLVxJgdIU/BO4LoTfD3kUZ8RGI=; b=Qxe710+0N/4Me2VFWFAKvUC71sg/goUxblC5uyPecQYM94tID4KMkDLStdKhOQsDox 83BXABrEgtypQV1p6pDo3Yvy2jwxU61lSJnBVAqs9HZJr9dCi+mgDYdmdbu4exFtpnwB 9aSEQqLFUWNicYU9zlRCICngIXr2cBWs2kVCrfamzns5dlcajeC44VDn8LFjhexRZ8+b 1MFvKsY7umhm/U4DiZuUwTOZoP6X466No43kdz7jWGRoFJW4hgtH0O3w6trl/6/FqL2B 0kdBCqkDO0rhML84zf42pXVZBPuGUsv1omWJYjIOBHeQmUbE9uxXZHfgHuodfcI9x1AT jznQ== 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=g+pOm1E9TbsqCGBIimLVxJgdIU/BO4LoTfD3kUZ8RGI=; b=RgeMxry74Jf31sD2gm+whNjpJZ85zLP9JWnxe34w+QdsKHxj+eQuiNdj0oM6ILPPmj D/G7MJqZTfpapzibP06qfMzaGA3B2LeIMl7oY9aAheBD2v4Syas+CTkmWfslgXfwHK24 GDwA/NWV1fLg1U+Uea9X6QQAtki4hQWQBIcyKs2nVjzKr11qs8o6nZ5YVIv2jriJFS7c F5JzcfKcfpd+w4gNAkYDRNYXg/SeyyJV9SnRXgqyqw+pbQpDr6HHf/4xXw7zY5qOXY7R BieItCHvwQLcFDor47gRoi8CxqZ750524Y+upGOnQxXwOkp5ryJLhxTOjNbRZL1EkKc6 9V4g== X-Gm-Message-State: AHYfb5iwescr5EHXGVjt8FOgPc/AWi2TcPkB/DiI1Lu63sFpz2WfSFmS VjMIZajnVbuZogjti6zwCfwRBLXo9Q== X-Received: by 10.36.181.85 with SMTP id j21mr8171446iti.165.1502325404299; Wed, 09 Aug 2017 17:36:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 9 Aug 2017 17:36:43 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Aug 2017 10:36:43 +1000 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Jana Iyengar Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" 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, 10 Aug 2017 00:36:47 -0000 On 10 August 2017 at 10:20, Jana Iyengar wrote: > I've assumed that without SETTINGS, you couldn't really send a request > anyways, so that was basically necessary HoLB. This introduces another frame > that can cause additional HoLB. Right. Though I'm not sure that SETTINGS is actually blocking now that it is so severely reduced in scope. It governs what you might send in response, but only peripheral stuff, like header compression table size, which are largely avoidable. But we already had that HOLB problem for server push, so it isn't a major burden. If it is, then sending the SETTINGS (or MAX_PUSH_ID) frame in every packet is a possible, albeit crude, solution. I was going to make this argument: > Though you could easily make the argument that we'd expect SETTINGS and the > first MAX_PUSH_ID frame to be sent in the same packet. Especially since we just saved bytes from the SETTINGS frame. In any case, I've revised the PR. From nobody Wed Aug 9 17:46:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71789132025 for ; Wed, 9 Aug 2017 17:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6GL20WLa0IB for ; Wed, 9 Aug 2017 17:46:35 -0700 (PDT) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E230A131CB2 for ; Wed, 9 Aug 2017 17:46:34 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id y129so34542469pgy.4 for ; Wed, 09 Aug 2017 17:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BJnZzStrdFp+p8HiVbN8CiJbKn/mN64uic4MXMrlhaA=; b=iRJvNmqCV59nw0sMibPXbfARfJPtu+N3z8Vkh1nf6vmGaIOOAtSXyedQmLBaVAYUek y7+NoRcTQSRYo8DRTutnyICt8QLK/v4KRwoM219X159lJYjVXLAtOxbC1W65xMIKc/6I Sn6mXj6CiNGgLhuOuBlzhJpjyLTi1OqgY2EXPJLRKSnA6T+yudKHH7S0evEtb9If42zn XBUYrxwB4z6Bj3EZd7gswblUb9WG7ZtFNsE8vEB4qIzE78k64NZtN4Cf90G9YHpTPfdr 894pN0meWsB5hUUMsyfhT9kQeLEbrrpnNBSm1fzJA80jAcqga23eruQ8nJ6rkvBUEVHz RE4g== 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=BJnZzStrdFp+p8HiVbN8CiJbKn/mN64uic4MXMrlhaA=; b=Y6lm35QGkufC82HtA6OyfaHHMQ4g6K4GtKyJqWGFKV47DsexG/bWpT5rlVsd3GOu4o uIMAp+1JGAruQI7fU/hHeA+nSQnwp+CFR1MxdJuixoANON1Yie/EsNde1eqVVv2aKptt NFsOS/qHn6YpxdIdfzgijw68AEgV9/lNmHWP2tPB5sEpkVrar3KEvXU6yszqUe2MYPRJ Y2ZE6RgvXhY3jzbHWGaMbFVQ9STbNCqWNinuPu2sJw2Oqm07JZ1Q4jn33nx+yOasIDzS f+lmHlC4V6yMfI1dFnVDJr3l/zQgAvAoL8wEktfbpc2lsPSMB5vDuMd5Zk54Z0ydz+GD ce2Q== X-Gm-Message-State: AHYfb5hZt52CItnPMxHsKHMmsNrRUfu33gG09zZT3jzfHISNTP/aUb1J kxjj1Ik9SHY1KMmVuTcSJw/Uh60qqsOM X-Received: by 10.98.112.132 with SMTP id l126mr9979693pfc.181.1502325994110; Wed, 09 Aug 2017 17:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.162 with HTTP; Wed, 9 Aug 2017 17:46:33 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 9 Aug 2017 17:46:33 -0700 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Martin Thomson Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="001a113b62ac37c9f205565b878a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 00:46:37 -0000 --001a113b62ac37c9f205565b878a Content-Type: text/plain; charset="UTF-8" Yeah, this SGTM. One other point: The PR now expects the server to push only after it's heard a MAX_PUSH_ID from the client. Is it useful to still have the old boolean that would indicate push is disabled by the client? Otherwise you have a server that's waiting forever to push but can't because it didn't hear anything from the client "yet". (Tertiary point: it might be useful for various debugging/logging purposes to have an explicit disabling.) On Wed, Aug 9, 2017 at 5:36 PM, Martin Thomson wrote: > On 10 August 2017 at 10:20, Jana Iyengar wrote: > > I've assumed that without SETTINGS, you couldn't really send a request > > anyways, so that was basically necessary HoLB. This introduces another > frame > > that can cause additional HoLB. > > Right. Though I'm not sure that SETTINGS is actually blocking now > that it is so severely reduced in scope. It governs what you might > send in response, but only peripheral stuff, like header compression > table size, which are largely avoidable. But we already had that HOLB > problem for server push, so it isn't a major burden. If it is, then > sending the SETTINGS (or MAX_PUSH_ID) frame in every packet is a > possible, albeit crude, solution. > > I was going to make this argument: > > > Though you could easily make the argument that we'd expect SETTINGS and > the > > first MAX_PUSH_ID frame to be sent in the same packet. > > Especially since we just saved bytes from the SETTINGS frame. > > In any case, I've revised the PR. > --001a113b62ac37c9f205565b878a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah, this SGTM.

One other point: The P= R now expects the server to push only after it's heard a MAX_PUSH_ID fr= om the client. Is it useful to still have the old boolean that would indica= te push is disabled by the client? Otherwise you have a server that's w= aiting forever to push but can't because it didn't hear anything fr= om the client "yet". (Tertiary point: it might be useful for vari= ous debugging/logging purposes to have an explicit disabling.)
<= div class=3D"gmail_extra">
On Wed, Aug 9, 201= 7 at 5:36 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 August 2= 017 at 10:20, Jana Iyengar <jri@google= .com> wrote:
> I've assumed that without SETTINGS, you couldn't really send a= request
> anyways, so that was basically necessary HoLB. This introduces another= frame
> that can cause additional HoLB.

Right.=C2=A0 Though I'm not sure that SETTINGS is actually block= ing now
that it is so severely reduced in scope.=C2=A0 It governs what you might send in response, but only peripheral stuff, like header compression
table size, which are largely avoidable.=C2=A0 But we already had that HOLB=
problem for server push, so it isn't a major burden.=C2=A0 If it is, th= en
sending the SETTINGS (or MAX_PUSH_ID) frame in every packet is a
possible, albeit crude, solution.

I was going to make this argument:

> Though you could easily make the argument that we'd expect SETTING= S and the
> first MAX_PUSH_ID frame to be sent in the same packet.

Especially since we just saved bytes from the SETTINGS frame.

In any case, I've revised the PR.

--001a113b62ac37c9f205565b878a-- From nobody Wed Aug 9 17:54:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 021771321A3 for ; Wed, 9 Aug 2017 17:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lbJrl1eNssLM for ; Wed, 9 Aug 2017 17:54:34 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2007313219A for ; Wed, 9 Aug 2017 17:54:34 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id g71so4177729ioe.5 for ; Wed, 09 Aug 2017 17:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ljj/NAPHNNfzI2UY7KbTYMdbeoH8Fvx8ppTWur1H4js=; b=k8zlpHiGfEOsjL/sr9eslAyGvrricTkUFOmcvakQXtNpkYGI8UXszhUOyeqh1pU4gq nrvNv654emn8gKpHS7iDC3HhpKPhYdooWUSkKhHNsWLuQrbN+maIt0mf+JUutGqoxlKA y6tnHVgibpRkE7hk0zUmECm/Ge4VMYX+F6wUpWhXn8aS+2chrIgVWkf2X95srXkltDTI fucnRCKUO68odxLoBcEQclR+nZ1aUIr4tAp2eP6c6QiogPpKYbOWRFNW2ZvCWWlC+NGe ikWJiym5jACJ0NYL66JlhyDcQsozA3yz9gwiiVXrgIQobPyA02RxJiSnFPS3QgZynfeK Wvxg== 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=Ljj/NAPHNNfzI2UY7KbTYMdbeoH8Fvx8ppTWur1H4js=; b=KDlFkr8jQd+YoDDK07ERTxPyEYs4bz89Cy59C9R4nKLzoUrfmQSliwHGXYV3S4FOCZ BsX51vftP6Tjup8l1GP+0Z4Q/P8oV+HnXRZsKwsdnc+LLK2jATzzmrL/P4GWE7z1fk9A pm2J/1VEmEpeyZgyjWLoAinlAvycFnsLBiQnxJCw7YPOaz4wrua+c7YtIMr8dtP5hpBO //0jxtb1D+966V+KCMZ5QOuCaYEza1D9lDw4HBbOpEGX/n37LYbqaKp+V488YxNc94o5 qf7jkXhBAxPb5HYSetkEzoZ+NiCUdy8yKRUuSm7aflufajRho4BWZIMahpH/1IkaRisx sJ9Q== X-Gm-Message-State: AHYfb5iMnjYoACzGiWv4y0BoB6ENVTs+eUMF7BzWiRvddmNHk4zAwd/K NeZ+1GEA+kuVW5uOAw5GqioYgQbn5A== X-Received: by 10.107.16.196 with SMTP id 65mr9666234ioq.297.1502326473337; Wed, 09 Aug 2017 17:54:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 9 Aug 2017 17:54:32 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Aug 2017 10:54:32 +1000 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Jana Iyengar Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" 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, 10 Aug 2017 00:54:36 -0000 On 10 August 2017 at 10:46, Jana Iyengar wrote: > One other point: The PR now expects the server to push only after it's heard > a MAX_PUSH_ID from the client. Is it useful to still have the old boolean > that would indicate push is disabled by the client? Otherwise you have a > server that's waiting forever to push but can't because it didn't hear > anything from the client "yet". (Tertiary point: it might be useful for > various debugging/logging purposes to have an explicit disabling.) Maybe we can defer a decision on this. It seems like something that we might learn very easily from implementing. We could spend a lot of time speculating about what value that sort of signal might provide or we could wait to see if it is a real problem in practice. I suggest that we open an issue so that we don't forget. From nobody Wed Aug 9 18:02:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 908A01324D7 for ; Wed, 9 Aug 2017 18:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZHg2g2aHG-d for ; Wed, 9 Aug 2017 18:02:49 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 4557C12EAF7 for ; Wed, 9 Aug 2017 18:02:49 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id t86so34445290pfe.2 for ; Wed, 09 Aug 2017 18:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+6ObobBiYGSar07ON+GEHNo6/ObA1yWfiN8fhsvNv9s=; b=kLPF14cmDFmNRJxjQ1E3VmItQXwttHM3z3nIEzJvLtK0t+CWxQA1Q6UWxppM1c0mna stQZhpgZVbJLG+uybhwKJuJvNWrozXcoWpj60mKs9ZQwm0F7bLNvSeZAzjkKA4sUmd9c i8TPKYGrjIHcEX9r6lup9/mRtuQMCFYxRkAM3vEP3Yf9M0NRtuJ81Yk+zH5ghx5yC3Wx aZ93uinmnIKZUz6Db/pKms8mTSDVyyX0NzHH6j5wFq9UC678oIqgt+FIWg+Ur1O1KRaw 11XgFA04h1KcN7rbRnJILnDFY6o3IDs42CyFLgEk5u6fgk6+ffJdqj48Ox+AFLZi4SOF xD0A== 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=+6ObobBiYGSar07ON+GEHNo6/ObA1yWfiN8fhsvNv9s=; b=anQBHG/bi/IGylPANBY5r0sXZETlBxGLyX9om+nxNUPJWyen+aYfRf9Q+gVJhMsRrk Yf2XhmJFBkmeoFaIn3IV5OH5YFX6CrwSEykwFww9ye9Jqm9y4Sr1QaT1FpUB385q4BmD j6moTgL41ZU0+mdB1TBtbELdcG569GNE2b/0Equpwf0EUa/D9Ru5hOx+U6+p8aEybcq2 ijmJaTOcjfgpz08ctrcyEXKMN94cPstibuw71XbH3HvKDvBH8offmQpcgDE9P03E3Ygr bXQrg4Tar6CXrE+6OOf2sG2/QRpyAkvTGWeb1j8VFzJFGdZktC64GK7J3YWhxCDTma8F ww7Q== X-Gm-Message-State: AHYfb5g/OPpYhO45p37Rl28oH3VYorF2MRjz9+yKrB1fdzWv3VInDdWY 0aX7WsBLCULColjlZ2MQFTkzORlTVs0y X-Received: by 10.99.114.7 with SMTP id n7mr6258443pgc.139.1502326968356; Wed, 09 Aug 2017 18:02:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.157.162 with HTTP; Wed, 9 Aug 2017 18:02:47 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 9 Aug 2017 18:02:47 -0700 Message-ID: Subject: Re: Sequential and Max Push ID (was Re: Push ID - Merge Imminent) To: Martin Thomson Cc: Mike Bishop , Ian Swett , Kazuho Oku , QUIC WG , "ietf-http-wg@w3.org" Content-Type: multipart/alternative; boundary="f403045cdae04987ed05565bc13b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 01:02:52 -0000 --f403045cdae04987ed05565bc13b Content-Type: text/plain; charset="UTF-8" Since the boolean exists in HTTP/2, it seems natural to retain it in QUIC as well. But this isn't a strong opinion. I've filed #718 and I'm fine with deferring. On Wed, Aug 9, 2017 at 5:54 PM, Martin Thomson wrote: > On 10 August 2017 at 10:46, Jana Iyengar wrote: > > One other point: The PR now expects the server to push only after it's > heard > > a MAX_PUSH_ID from the client. Is it useful to still have the old boolean > > that would indicate push is disabled by the client? Otherwise you have a > > server that's waiting forever to push but can't because it didn't hear > > anything from the client "yet". (Tertiary point: it might be useful for > > various debugging/logging purposes to have an explicit disabling.) > > Maybe we can defer a decision on this. It seems like something that > we might learn very easily from implementing. We could spend a lot of > time speculating about what value that sort of signal might provide or > we could wait to see if it is a real problem in practice. I suggest > that we open an issue so that we don't forget. > --f403045cdae04987ed05565bc13b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Since the boolean exists in HTTP/2, it seems natural to re= tain it in QUIC as well. But this isn't a strong opinion. I've file= d #718 and= I'm fine with deferring.

On Wed, Aug 9, 2017 at 5:54 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 10 August 2017 at 10:46, Jana Iyengar <jri@google.com> wrote:
> One other point: The PR now expects the server to push only after it&#= 39;s heard
> a MAX_PUSH_ID from the client. Is it useful to still have the old bool= ean
> that would indicate push is disabled by the client? Otherwise you have= a
> server that's waiting forever to push but can't because it did= n't hear
> anything from the client "yet". (Tertiary point: it might be= useful for
> various debugging/logging purposes to have an explicit disabling.)

Maybe we can defer a decision on this.=C2=A0 It seems like something= that
we might learn very easily from implementing.=C2=A0 We could spend a lot of=
time speculating about what value that sort of signal might provide or
we could wait to see if it is a real problem in practice.=C2=A0 I suggest that we open an issue so that we don't forget.

--f403045cdae04987ed05565bc13b-- From nobody Wed Aug 9 20:09:45 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377DA132536 for ; Wed, 9 Aug 2017 20:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 flyQMYo-Ulxk for ; Wed, 9 Aug 2017 20:09:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3B5A131CB6 for ; Wed, 9 Aug 2017 20:09:40 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7A386Cb013758; Thu, 10 Aug 2017 04:09:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=7e/pBjeNtyghQXjLxBLx3St+Urj/oWIlHKJXpvrr52E=; b=cJkhTYi69hniyDo01Qlus5eBPpQtUOTNIqigSMUDZmUfSwO2vk0I7w0j5TsghMp2ke2S poeo4mT/oKJWJfmzEjduksyXD1+hHBsxwg9HHOJ6DUoK0wBtwdt9DE+auCHK8qAVL5k0 8QtmHnkPxd5cr58mGczcrIXpTEEbVlzelxk2D/B4lITcKtgjrP2Nm9PgTjhVJfetIK+7 g2cq/9BFOOGN5E/xcF16Vh4qSda40hFJxU1waHMqd5Txiz1bROjM8GZvht9Vb54QfwRc 1VeH7lhZLlLvWZTn0qAuyTJS7ULaPM4XFEDGVpKSIii7m+wByQuFHVnLoXMSXPdN/7Yq DQ== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2c8a880rd5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Aug 2017 04:09:34 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7A35xIr017406; Wed, 9 Aug 2017 23:09:34 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint4.akamai.com with ESMTP id 2c59bv4j9r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 09 Aug 2017 23:09:33 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 9 Aug 2017 23:09:32 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Wed, 9 Aug 2017 23:09:32 -0400 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Ian Swett" CC: Ryan Hamilton , IETF QUIC WG Subject: RE: 5-tuple uniquess Thread-Topic: 5-tuple uniquess Thread-Index: AQHTDp1bhJPQi5zq4kWW5+Ln50FN+6J3oyiAgAABdoCAAAX3AIADr5aAgADmn5CAAFA6gP//3Ang Date: Thu, 10 Aug 2017 03:09:32 +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.35.0] Content-Type: multipart/alternative; boundary="_000_c3c1ede4958644bf8f582e8e8370634eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-10_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708100050 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-10_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708100050 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 03:09:44 -0000 --_000_c3c1ede4958644bf8f582e8e8370634eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzZWUg4oCccG9ydCByZXVzZeKAnSBhcyBhbiBpbnN0YW5jZSBvZiBhIGdlbmVyaWMg4oCcTkFU IHJlYmluZGluZ+KAnSB0aGF0IFFVSUMgaXMgYnVpbHQgZm9yLiAgV2XigJl2ZSBtYWludGFpbmVk IHByZXZpb3VzbHksIGhvd2V2ZXIsIHRoYXQgUVVJQyB0b2xlcmFuY2UgdG8g4oCcY29ubmVjdGlv biBtaWdyYXRpb24gLyBOQVQgcmViaW5kaW5n4oCdIGR1cmluZyBjb25uZWN0aW9uIGVzdGFibGlz aG1lbnQgaXMgb3V0IG9mIHNjb3BlLiAgVGhpcyBwcm9wb3NhbCB3b3VsZCBzZWVtIHRvIHJldmlz aXQgdGhhdCBzY29wZS4NCg0KWW91IG1heSBpbmRlZWQgd2FudCB0byBvcGVuIG11bHRpcGxlIGNv bmN1cnJlbnQgY29ubmVjdGlvbnMgZnJvbSBTIHRvIEIsIGhvcGluZyB0byBzcHJlYWQgeW91ciBj b25uZWN0aW9ucyBhbW9uZyBtdWx0aXBsZSBzZXJ2ZXJzIGJlaGluZCBCLiAgQnV0IGl0IG1heSBh Y3R1YWxseSBiZSBjb3VudGVyLXByb2R1Y3RpdmUgdG8gdXNlIGEgc2luZ2xlIDUtdHVwbGUsIGlm IEIgaXMgYmVoaW5kIGFuIEVDTVAgcm91dGVyIGFjdGluZyBhcyBhIGxvYWQgYmFsYW5jZXIuICBN b3Jlb3ZlciwgdGhpcyB3aWxsIGFsc28gZGVmZWF0IFJTUy9SUFMvUkZTPGh0dHBzOi8vd3d3Lmtl cm5lbC5vcmcvZG9jL0RvY3VtZW50YXRpb24vbmV0d29ya2luZy9zY2FsaW5nLnR4dD4gbG9hZCBi YWxhbmNpbmcgbWVjaGFuaXNtcyB3aXRoaW4gc2VydmVycy4gIEJlIGF3YXJlLg0KDQoNCiAgKiAg IElnb3INCg0KDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtr ZWxmakBnbWFpbC5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAwOSwgMjAxNyAxOjMzIFBN DQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBJYW4gU3dldHQgPGlh bnN3ZXR0QGdvb2dsZS5jb20+DQpDYzogUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+OyBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogNS10dXBsZSB1bmlxdWVz cw0KDQpUaGlzIG1heSBub3QgYWRkcmVzcyBhbGwgeW91ciBjb25jZXJucywgYnV0IEkgdGhpbmsg cGVyaGFwcyB5b3UgYXJlIGxvb2tpbmcgYXQgdGhlIHByb2JsZW0gZnJvbSB0aGUgd3JvbmcgZW5k IHdpdGggcmVzcGVjdCB0byBlcGhlbWVyYWwgcG9ydCBleGhhdXN0aW9uOg0KDQpJbiBhIHR5cGlj YWwgTkFUIHNjZW5hcmlvIHlvdSBoYXZlIG1hbnkgY2xpZW50cyByZWFjaGluZyBmb3Igb25lIHNl cnZlciwgZWFjaCBjbGllbnQgbGlrZWx5IHBhc3NpbmcgYSBkaWZmZXJlbnQgTkFULg0KSGVuY2Ug ZWFjaCBjb25uZWN0aW9uIHdpbGwgYmUgYSB1bmlxdWUgNS10dXBsZSwgZXZlbiBpZiBRVUlDIGl0 c2VsZiBpcyBub3QgbWFraW5nIGFueSBlZmZvcnQgdG8gYWNoaWV2ZSB0aGlzLg0KDQpOb3csIGlm IG9uZSBvZiB0aGVzZSBjbGllbnRzIGNyZWF0ZXMgdHdvIGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1l IHNlcnZlciBhbmQgY2hvb3NlcyB0byByZXVzZSB0aGUgb3V0Ym91bmQgVURQIHBvcnQgbnVtYmVy LCBzYXkgcmVhY2hpbmcgZm9yIHR3byBkaWZmZXJlbnQgaW1hZ2VzLCB0aGVuIHRoZSBOQVQgbWln aHQgdGhpbmsgdGhhdCB0aGUgdHdvIGNvbm5lY3Rpb25zIGFyZSB0aGUgc2FtZSBjb25uZWN0aW9u LiBBbmQgaW4gc29tZSBzZW5zZSBpdCBpcyAtIG5vdCB0aGUgc2FtZSBRVUlDIGNvbm5lY3Rpb24s IGJ1dCB0aGUgc2FtZSBvcGVyYXRpb25hbCBjb250ZXh0LiBUaHVzLCB0aGUgdHdvIGNvbm5lY3Rp b25zIGhlbHBzIHJlZHVjZSBOQVQgb3ZlcmhlYWQgYW5kIGFsc28gY29vcGVyYXRlcyBpbiBrZWVw aW5nIHRoZSBOQVQgaG9sZSBvcGVuLg0KDQpPbiB0aGUgb3RoZXIgZW5kLCBhdCB0aGUgc2VydmVy LCB0aGVyZSBpcyBhIHNlcGFyYXRlIHByb2JsZW06IFRoZSBzZXJ2ZXIgKFMpIGRvZXMgbm90IGhh dmUgdGhlIHJlcXVlc3RlZCBpbWFnZXMuIEl0IHJlYWNoZXMgdG8gb25lIG9mIGEgZmV3IHBvc3Np YmxlIGJhY2tlbmQgc2VydmVycyAoQjEsIEIyKS4gU2luY2UgdGhlIHNlcnZlciBTIGlzIG5vdCBh dHRlbXB0aW5nIHRvIGJlIGNsZXZlciwgaXQgY3JlYXRlcyBhIG5ldyBRVUlDIGNvbm5lY3Rpb24g ZnJvbSBTIHRvIEIxIG9yIEIyIGZvciBlYWNoIGluYm91bmQgY2xpZW50IGNvbm5lY3Rpb24uIFRo ZXJlIG1heSBvciBtYXkgbm90IGJlIGFueSBOQVQgaW52b2x2ZWQgaGVyZSwgYnV0IHRoZSBzZXJ2 ZXIgUyBpcyBvbmx5IGFzc2lnbmVkIGEgc2luZ2xlIElQIGFkZHJlc3MgZm9yIG91dGJvdW5kIHJl cXVlc3RzIGFuZCBjYW5ub3QgY3JlYXRlIG1vcmUgY29uY3VycmVudCBjb25uZWN0aW9ucyB0aGF0 IHRoZSBudW1iZXIgb2YgZXBoZW1lcmFsIHBvcnRzICsgc2FmZXR5IG1hcmdpbiBwZXJtaXRzLCB0 aGF0IGlzLCB1bmxlc3MgaXQgY2hvb3NlcyB0byByZXVzZSBvdXRib3VuZCBwb3J0IG51bWJlcnMg d2hpY2ggc29sdmVzIHRoZSBwcm9ibGVtIG9mIHBvcnQgZXhoYXVzdGlvbi4NCg0KSWYsIG9uIHRo ZSBvdGhlciBoYW5kLCBhIFFVSUMgY2xpZW50IHdlcmUgY28tbG9jYXRlZCB3aXRoIG90aGVyIHNl cnZpY2VzLCBpdCBtaWdodCBub3QgYmUgYWJsZSB0byByZWNlaXZlIHRoZSBjb3JyZWN0IHBhY2tl dHMgd2hlbiB0aGVzZSBkaWZmZXJlbnQgc2VydmljZXMgY29tcGV0ZSBmb3IgcG9ydCBudW1iZXJz LiBCdXQgaGVyZSBpdCBzdWZmaWNlIHRoYXQgdGhleSBlaXRoZXIgYWdyZWUgdG8gdXNlIGRpZmZl cmVudCBwb3J0cyAobGlrZSBQSU5HIHZzLiBETlMpLCBvciBlYWNoIHNlcnZpY2UgYWxsb2NhdGUg YSBzaW5nbGUgZXBoZW1lcmFsIHBvcnQgZm9yIGl0cyBzZXJ2aWNlIHZpYSBVRFAgc29ja2V0IGNy ZWF0aW9uLiBJbiBlaXRoZXIgY2FzZSB0aGUgTkFUIHdvdWxkIHJvdXRlIHBhY2tldHMgdG8gdGhl IGNvcnJlY3Qgc2VydmljZSBieSByZWx5aW5nIG9uIDUtdHVwbGVzIGV2ZW4gaWYgUVVJQyBpdHNl bGYgZG9lcyBub3QuDQoNClNvLCBnb2luZyBmdXJ0aGVyIC0gd2hhdCBpZiBzZXZlcmFsIGhvc3Rz IHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNzLCBhcyBpcyB0aGUgY2FzZSB3aXRoIGxvYWQgYmFsYW5j ZXJzPyBBZ2FpbiwgNS10dXBsZXMgYXJlIHVzZWQgdG8gYmluZCBjb25uZWN0aW9ucyB0byBlYWNo IHVuaXF1ZSBob3N0LCBvbmx5IHdpdGggZmV3ZXIgVURQIHBvcnRzIHRoZXJlIGlzIG11Y2ggbGVz cyBzdGF0ZSB0byBtYWludGFpbi4gVGhlIG1pZGRsZXdhcmUgb25seSBuZWVkIHRvIHJvdXRlIHRy YWZmaWMgdG8gdGhlIGNvcnJlY3QgZW5kcG9pbnQsIG5vdCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGxv Z2ljYWwgUVVJQyBjb25uZWN0aW9ucyB0aGF0IGhhcHBlbiBiZXR3ZWVuIHRoZSBzYW1lIHR3byBl bnRpdGllcy4NCg0KS2luZCBSZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoN Ck9uIDkgQXVndXN0IDIwMTcgYXQgMTkuMDMuMzUsIEx1YmFzaGV2LCBJZ29yIChpbHViYXNoZUBh a2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPikgd3JvdGU6DQpDYW4gc29tZW9u ZSBlbGFib3JhdGUgb24g4oCcUG9zc2libHkgaXQgc2hvdWxkIHNwZWNpZnkgdGhlIGNsaWVudCdz IGNvbm5lY3Rpb24gSUQgaW4gdGhlIHBhY2tldCBoZWFkZXIgYW5kIHRoZW4gdGhlIG5ldyBzZXJ2 ZXIgY29ubmVjdGlvbiBJRCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnM/4oCdDQoNCklzIHRo YXQgb25seSBmb3Ig4oCcU2VydmVyIENsZWFydGV4dOKAnT8gV2hhdCBhYm91dCBjb25uZWN0aW9u cyB0aGF0IHN0YXJ0IG91dCB3aXRoIDBSVFQgcGFja2V0cyDigJMgaG93IHdvdWxkIHRoZSBOQVQg a25vdyB3aGljaCBmbG93IFNlcnZlcuKAmXMgMVJUVCByZXBseSBiZWxvbmdzIHRvIChpZiBTZXJ2 ZXIgY2hhbmdlcyB0aGUgQ29uZW5jdGlvbklEKT8NCg0KTWF5YmUgcmVseWluZyBvbiBhIDUtdHVw bGUgaXMgbm90IHN1Y2ggYSBiYWQgaWRlYSBhZnRlciBhbGw/ICBBIE5BVCBkb2VzIG5vdCBuZWVk IGEgZGlmZmVyZW50IGVwaGVtZXJhbCBwb3J0IGZvciBldmVyeSBvdXRnb2luZyBjb25uZWN0aW9u LiAgSXQgb25seSBuZWVkcyBhIGRpZmZlcmVudCBlcGhlbWVyYWwgcG9ydCBmb3Igb3V0Z29pbmcg Y29ubmVjdGlvbnMgdG8gdGhlIHNhbWUgSVAuDQoNCkV2ZW4gdGhlbiwgaWYgdGhlIE5BVCBpcyB3 aWxsaW5nIHRvIGRvIHNvbWV0aGluZyBzcGVjaWFsIGZvciBRVUlDLCBpdCBjYW4gYmUgYSBtdWNo IHNpbXBsZXIgdGhpbmcgdGhhbiBleGFtaW5lIFFVSUMgdHJhbnNwb3J0IHBhcmFtcy4gIFRoZSBO QVQgY2FuIHNpbXBseSByZXNlcnZlIGEgc2luZ2xlIGVwaGVtZXJhbCBwb3J0IGZvciBhbGwgMVJU VCBRVUlDIHBhY2tldHMuICBUaGF0IGlzLCBhbGwgb3V0Z29pbmcgY2xlYXJ0ZXh0IGFuZCAwcnR0 IFFVSUMgcGFja2V0cyB3b3VsZCByZXF1aXJlIGEgZGlzdGluY3QgNS10dXBsZSwgYnV0IG9uY2Ug dGhlIGNvbm5lY3Rpb24gbWlncmF0ZXMgdG8gMVJUVCwgdGhlIGVwaGVtZXJhbCBwb3J0IGl0IHVz ZWQgY2FuIGJlIGZyZWVkLCBhbmQgYWxsIDFSVFQgcGFja2V0cyBzb3VyY2VkIGZyb20gdGhlIHJl c2VydmVkIFFJVUMgcG9ydC4gIFRoYXQgd291bGQgd29yaywgc2luY2UgYWxsIDFSVFQgcGFja2V0 cyAoYm90aCBmcm9tIGNsaWVudCBhbmQgc2VydmVyKSB3b3VsZCBiZSB1c2luZyBTZXJ2ZXItc2Vs ZWN0aW9uIENvbm5lY3Rpb25JRC4NCg0KDQogICogICBJZ29yDQoNCg0KDQpGcm9tOiBJYW4gU3dl dHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29t Pl0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwOCwgMjAxNyA3OjAxIFBNDQpUbzogTWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFp bC5jb20+Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRm Lm9yZz4+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbTxtYWlsdG86cmNoQGdvb2dsZS5j b20+Pg0KU3ViamVjdDogUmU6IDUtdHVwbGUgdW5pcXVlc3MNCg0KWW91J3JlIHJpZ2h0LCBlcGhl bWVyYWwgcG9ydCBleGhhdXN0aW9uIGlzIGEgdmVyeSByZWFsIHBvdGVudGlhbCBpc3N1ZSwgYW5k IEkgdGhpbmsgd2Ugc2hvdWxkIGVuc3VyZSBtdWx0aXBsZSBRVUlDIGNvbm5lY3Rpb25zIGNhbiBy dW4gb3ZlciB0aGUgc2FtZSA1LXR1cGxlIGFuZCB3ZSBkb24ndCBzcGVjaWZ5IFFVSUMgaW4gYSB3 YXkgdGhhdCBwcmVjbHVkZXMgdGhhdC4NCg0KSSBiZWxpZXZlIHlvdSdyZSBjb3JyZWN0IHRoYXQg dGhlIGN1cnJlbnQgU2VydmVyIENsZWFydGV4dCBtYWtlcyB0aGlzIGltcG9zc2libGUgaWYgdGhl IHNlcnZlciBjaGFuZ2VzIHRoZSBjb25uZWN0aW9uIElELiAgUG9zc2libHkgaXQgc2hvdWxkIHNw ZWNpZnkgdGhlIGNsaWVudCdzIGNvbm5lY3Rpb24gSUQgaW4gdGhlIHBhY2tldCBoZWFkZXIgYW5k IHRoZW4gdGhlIG5ldyBzZXJ2ZXIgY29ubmVjdGlvbiBJRCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFt ZXRlcnM/ICBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRo dWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vlc183MTQmZD1Ed01GYVEmYz05NlpiWlpj YU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVL UG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmcz0tRHR2 dGttRF9sWkpnRXRqdnVneDRPeHNrUkFVbXFweTVOZ0NnTnphaEd3JmU9Pg0KDQpUaGUgdGV4dCBp cyBhbHNvIG1pc3Npbmcgc29tZSBkZXRhaWxzIG9uIGhvdyBjaGFuZ2luZyB0aGUgY29ubmVjdGlv biBJRCBzaG91bGQgd29yayBmb3IgU3RhdGVsZXNzIFJldHJ5LCBzZWUgaHR0cHM6Ly9naXRodWIu Y29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNzEzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRy YWZ0c19pc3N1ZXNfNzEzJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNi UTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1tWGtpS0toX0ZrUk8tTUFO bzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JnM9Y1ZfNUFVSlBvVzQ2U1FISlQxTml5X3p1UkN4 MEU3eDI4OC1MNDYtemhkWSZlPT4sIHNvIEknZCBleHBlY3Qgc29tZSBpbXByb3ZlbWVudHMgaW4g dGhlIG5lYXIgZnV0dXJlLg0KDQpPbiBTdW4sIEF1ZyA2LCAyMDE3IGF0IDEwOjQzIEFNLCBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZq QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBSeWFuLA0KDQpJIGNhbiBkaWcgZG93biBpbiBtb3Jl IGRldGFpbCBpZiB0aGVyZSBpcyBpbnRlcmVzdC4gTWVhbndoaWxlLCBzb21lIGV4YW1wbGVzIHdo ZXJlIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQgaXMgbm90IGNvbXBhdGlibGUgd2l0aCBteSByZXF1 ZXN0IGlzOg0KDQpUaGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNrZXQgaXMgb2sgLSBpdCByZWZs ZWN0cyB0aGUgY2xpZW50IHZlcnNpb24NCmh0dHBzOi8vcXVpY3dnLmdpdGh1Yi5pby9iYXNlLWRy YWZ0cy9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0Lmh0bWwjcGFja2V0LXZlcnNpb248aHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19xdWljd2cuZ2l0 aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRmLTJEcXVpYy0yRHRyYW5zcG9ydC5odG1s LTIzcGFja2V0LTJEdmVyc2lvbiZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1E am4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJm09bVhraUtLaF9Ga1JP LU1BTm8wV3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9xOCZzPWduejhQSjRSUU1xNnctX1dGYTFSSFlN VGdwZ3RnSW1ha1IxcVp3bV91VGsmZT0+DQoNCkJ1dA0KaHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlv L2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuaHRtbCNwYWNrZXQtc2VydmVy LWNsZWFydGV4dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRyYWZ0c19kcmFmdC0yRGlldGYtMkRxdWlj LTJEdHJhbnNwb3J0Lmh0bWwtMjNwYWNrZXQtMkRzZXJ2ZXItMkRjbGVhcnRleHQmZD1Ed01GYVEm Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlq VVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRf cTgmcz1EaldkbzhZaHU4dDdoMXpxZDdCSXhrOV9UTFUzNkF4bWRaMERtaFpuNnZFJmU9Pg0KIlRo ZSBjb25uZWN0aW9uIElEIGZpZWxkIGluIGEgU2VydmVyIENsZWFydGV4dCBwYWNrZXQgY29udGFp bnMgYSBjb25uZWN0aW9uIElEIHRoYXQgaXMgY2hvc2VuIGJ5IHRoZSBzZXJ2ZXIgKHNlZSBTZWN0 aW9uIDUuNjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRyYWZ0c19kcmFmdC0yRGlldGYtMkRxdWljLTJE dHJhbnNwb3J0Lmh0bWwtMjNjb25uZWN0aW9uLTJEaWQmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcw RjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZt PW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmcz01U0g2dTdBYUhf YXJ4R1kzeUVlcXd5aGlvOGRUWDlTTVFXRmMyVElsaFkwJmU9PikuIg0KVGhpcyBicmVha3MgbGlu a2FnZSB0byB0aGUgb3JpZ2luYWwgY2xpZW50IGNvbm5lY3Rpb24gaWQgc28gdGhlIGNsaWVudCBj YW5ub3QgdGVsbCB3aGljaCBjb25uZWN0aW9uIHRoZSByZXNwb25zZSBiZWxvbmdzIHRvIHVubGVz cyBsb29raW5nIGludG8gNS10dXBsZSwgb3IgdGVzdGluZyBhbGwgcmVjZW50IGNvbm5lY3Rpb25z IGFnYWluc3QgQUVBRCBzaWduYXR1cmUgKGRlcGVuZGluZyBvbiB3aGVyZSB0aGlzIGxhbmRzKS4N Cg0KSSBoYXZlIG5vdCBjb3ZlcmVkIGFsbCBvdGhlciBwb3NzaWJsZSBzZXJ2ZXIgcmVzcG9uc2Vz LCBidXQgc2ltaWxhciBjb25jZXJucyBhcHBseS4NCkl0IGlzIG5vdCBhIG1ham9yIGNoYW5nZSwg YnV0IGN1cnJlbnRseSBpdCBpcyBub3QgcG9zc2libGUuDQoNCkFub3RoZXIgaXNzdWUgaXMgaG9z dGlsZSByZXNwb25zZSB0byBpbml0aWFsIGNvbm5lY3Rpb24gc2V0dXAsIGFuZCBwbGFpbiBlcnJv cnMgLSBob3cgdG8geW91IHJlcGx5IHdpdGggYW4gZXJyb3IuIEhhdmluZyB0aGUgY29ubmVjdGlv biBpZCBmcm9tIHRoZSBjbGllbnQgbWFrZXMgaXQgcmVhc29uYWJseSBlYXN5IHRvIGRlYWwgd2l0 aCAtIHNpbWlsYXIgdG8gdmVyc2lvbiBuZWdvdGlhdGlvbi4gQWx0ZXJuYXRpdmVseSB5b3UgaGF2 ZSB0byByZWx5IG9uIDUtdHVwbGVzLiBUaGlzIHJlcXVpcmVzIGNhcmVmdWwgYW5hbHlzaXMgb2Yg Ym90aCB0aGUgdHJhbnNwb3J0IGRvYyBhbmQgcG9zc2libHkgVExTIGFuZCB0aGlucyBhcmUgbm90 IGZ1bGx5IHNldHRsZWQuIFN0YXRlbGVzcyByZXNldCBpcyByZWxhdGVkIHRvIHRoaXMuIEkgd2ls bCBub3QgYXJndWUgc3Ryb25nbHkgb24gdGhpcyBiZWNhdXNlIHNpbmNlIEkgbGFzdCBsb29rZWQg YXQgaXQsIG5ldyBBRUFEIGVuY3J5cHRpb24gaXMgYmVpbmcgZGlzY3Vzc2VkLCBhbmQgSSBoYXZl IG5vdCBhbmFseXNlZCB0aGlzIGluIGRldGFpbC4NCg0KVGhlbiB0aGVyZSBpcyBjb25uZWN0aW9u IG1pZ3JhdGlvbi4gVGhpcyBhbHNvIHJlcXVpcmVzIGNhcmVmdWwgYW5hbHlzaXMuIEnigJltIG5v dCBzdXJlIGlmIGl0IGN1cnJlbnRseSBjb3ZlcnMgbXkgcmVxdWVzdC4NCg0KSeKAmW0gc3VyZSB0 aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2l0aCBpbXBsaWNpdCBhc3N1bXB0aW9ucyB0 aGF0IEkgYW0gbm90IGFibGUgdG8gbGlzdCBvZmYgbWVtb3J5Lg0KDQpUaGUgKG15KSBiYXNpYyBy dWxlIGlzIHRoZSBhbnkgY2hhbmdlIGluIGNvbm5lY3Rpb24gSUQgc2hvdWxkIHJlZmVyIHRvIHRo ZSBwcmV2aW91cyBJRCB3aXRob3V0IHJlbHlpbmcgb24gZXh0ZXJuYWwgc3RhdGUgc3VjaCBhcyA1 LXR1cGxlcyBvciBUTFMgZXh0ZW5zaW9uIHN0YXRlICh3aGljaCByZXF1aXJlcyBjcnlwdG8gc3Rh dGUgdG8gYWNjZXNzIGFuZCBjb21wbGljYXRlcyB0aGluZ3MpLiBBbHNvLCBkdWUgY29uY2VybnMg b2YgcHJpdmFjeSBjb25jZXJucyB0aGlzIGxpbmthZ2UgYmV0d2VlbiBjb25uZWN0aW9uIElE4oCZ cyBzaG91bGQgb25seSBiZSBwb3NzaWJsZSBieSBwZWVycywgZXhjZXB0cyBmb3IgdGhlIGluaXRp YWwgY2xpZW50IHRvIHNlcnZlciBjb25uZWN0aW9uIHRyYW5zaXRpb24gdGhhdCBpcyBhbHNvIHZp c2libGUgdG8gYW55IHBhcnR5IG9uLXBhdGguDQoNCkluIGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBl bmNvZGluZyBjb25jZXJucywgaXQgbWF5IGFsc28gYmUgaGVscGZ1bCB0byBleHBsaWNpdGx5IHN0 YXRlIHRoYXQgdGhlIHNhbWUgVURQIHBvcnQgbWF5IGJlIHVzZWQgdG8gaW5pdGlhdGUgbXVsdGlw bGUgaW5kZXBlbmRlbnQgUVVJQyBjb25uZWN0aW9uIHRvIHRoZSBzYW1lIHNlcnZlciBVRFAgcG9y dCB3aGVuIGNvbm5lY3Rpb24gSUQgaGFzIGJlZW4gbmVnb3RpYXRlZCB0byBiZSBwcmVzZW50IC0g b3IgZnVydGhlciBkZXRhaWwgdGhpcyBwb3NzaWJpbGl0eSBhcyBzb21ldGhpbmcgdGhhdCBjYW4g YmUgbmVnb3RpYXRlZC4NCg0KDQpTb21lIG90aGVyIHBvaW50cyBJIGZvcmdldCB0byBtZW50aW9u IHJlZ2FyZGluZyBiZW5lZml0cyBvZiBub24tdW5pcXVlIHR1cGxlczoNCg0KNSkgbm8gaW50ZXJm ZXJlbmNlIHdpdGggT1MgaXMgbmVjZXNzYXJ5IGluIG9yZGVyIHRvIGVzdGFibGlzaCBhIG5ldyBj b25uZWN0aW9uIHRvIGFuIGV4aXN0aW5nIGVuZHBvaW50IGJlY2F1c2Ugbm8gbmV3IGVwaGVtZXJh bCBwb3J0IGlzIG5lZWRlZC4gVGhpcyBtYXkgYWxzbyBzaW1wbGlmeSBjbGVhbiB1cCBhbmQgc3Rh dGUgbWFuYWdlbWVudCwgZXNwZWNpYWxseSBzZXJ2ZXIgdG8gc2VydmVyLg0KDQo2KSBOZXRtYXAg YW5kIHNpbWlsYXIgaGlnaCBzcGVlZCBpbnRlcmZhY2VzIHdvdWxkIGJlIHNpbXBsZXIgd2l0aG91 dCBoYXZpbmcgdG8gZGVhbCB3aXRoIGVwaGVtZXJhbCBwb3J0IGFsbG9jYXRpb24sIGVzcGVjaWFs bHkgc2VydmVyIHRvIHNlcnZlciB3aGVyZSBib3RoIGVuZCBwb2ludHMgY2FuIHJlZmVyZW5jZSBl YWNoIG90aGVyLCBhbmQgd2hlcmUgaXQgbWlnaHQgYmUgcmFuZG9tIHdoaWNoIGVuZHBvaW50IGFj dHVhbGx5IGluaXRpYXRlcyB0byB0aGUgY29ubmVjdGlvbiAoYXMgaW4gQ29yZCAvIEthZGVtbGlh IHN0eWxlIG92ZXJsYXkgbmV0d29ya3MpDQoNCktpbmQgUmVnYXJkcywNCk1pa2tlbCBGYWhuw7hl IErDuHJnZW5zZW4NCg0KDQo= --_000_c3c1ede4958644bf8f582e8e8370634eusma1exdag1mb5msgcorpak_ 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 Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5haXJt YWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI2MzE1MjUwMTsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTE4Nzg1MTU1NDg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDox NjI2ODE2MDI4Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTY2NTc1NDM2NiAxMzAwNjg2NzQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDox NjcyMDI0Nzc1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0ODU5MDU0Nzg7fQ0KQGxpc3QgbDI6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JIHNlZSDigJxwb3J0IHJldXNl4oCdIGFzIGFuIGluc3RhbmNlIG9mIGEgZ2VuZXJp YyDigJxOQVQgcmViaW5kaW5n4oCdIHRoYXQgUVVJQyBpcyBidWlsdCBmb3IuJm5ic3A7IFdl4oCZ dmUgbWFpbnRhaW5lZCBwcmV2aW91c2x5LCBob3dldmVyLCB0aGF0IFFVSUMgdG9sZXJhbmNlIHRv IOKAnGNvbm5lY3Rpb24gbWlncmF0aW9uIC8NCiBOQVQgcmViaW5kaW5n4oCdIGR1cmluZyBjb25u ZWN0aW9uIGVzdGFibGlzaG1lbnQgaXMgb3V0IG9mIHNjb3BlLiZuYnNwOyBUaGlzIHByb3Bvc2Fs IHdvdWxkIHNlZW0gdG8gcmV2aXNpdCB0aGF0IHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3UgbWF5 IGluZGVlZCB3YW50IHRvIG9wZW4gbXVsdGlwbGUgY29uY3VycmVudCBjb25uZWN0aW9ucyBmcm9t IFMgdG8gQiwgaG9waW5nIHRvIHNwcmVhZCB5b3VyIGNvbm5lY3Rpb25zIGFtb25nIG11bHRpcGxl IHNlcnZlcnMgYmVoaW5kIEIuJm5ic3A7IEJ1dCBpdCBtYXkgYWN0dWFsbHkgYmUgY291bnRlci1w cm9kdWN0aXZlDQogdG8gdXNlIGEgc2luZ2xlIDUtdHVwbGUsIGlmIEIgaXMgYmVoaW5kIGFuIEVD TVAgcm91dGVyIGFjdGluZyBhcyBhIGxvYWQgYmFsYW5jZXIuJm5ic3A7IE1vcmVvdmVyLCB0aGlz IHdpbGwgYWxzbyBkZWZlYXQNCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmtlcm5lbC5vcmcvZG9jL0Rv Y3VtZW50YXRpb24vbmV0d29ya2luZy9zY2FsaW5nLnR4dCI+UlNTL1JQUy9SRlM8L2E+IGxvYWQg YmFsYW5jaW5nIG1lY2hhbmlzbXMgd2l0aGluIHNlcnZlcnMuJm5ic3A7IEJlIGF3YXJlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWdvcjxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDA5LCAyMDE3IDE6MzMgUE08YnI+DQo8 Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgSWFu IFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUnlhbiBI YW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiA1LXR1cGxlIHVuaXF1ZXNzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhpcyBtYXkgbm90IGFkZHJlc3MgYWxs IHlvdXIgY29uY2VybnMsIGJ1dCBJIHRoaW5rIHBlcmhhcHMgeW91IGFyZSBsb29raW5nIGF0IHRo ZSBwcm9ibGVtIGZyb20gdGhlIHdyb25nIGVuZCB3aXRoIHJlc3BlY3QgdG8gZXBoZW1lcmFsIHBv cnQgZXhoYXVzdGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJs b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3Vz dG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gYSB0 eXBpY2FsIE5BVCBzY2VuYXJpbyB5b3UgaGF2ZSBtYW55IGNsaWVudHMgcmVhY2hpbmcgZm9yIG9u ZSBzZXJ2ZXIsIGVhY2ggY2xpZW50IGxpa2VseSBwYXNzaW5nIGEgZGlmZmVyZW50IE5BVC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhlbmNlIGVhY2ggY29ubmVj dGlvbiB3aWxsIGJlIGEgdW5pcXVlIDUtdHVwbGUsIGV2ZW4gaWYgUVVJQyBpdHNlbGYgaXMgbm90 IG1ha2luZyBhbnkgZWZmb3J0IHRvIGFjaGlldmUgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Tm93LCBpZiBvbmUgb2YgdGhlc2UgY2xpZW50cyBjcmVhdGVzIHR3byBj b25uZWN0aW9ucyB0byB0aGUgc2FtZSBzZXJ2ZXIgYW5kIGNob29zZXMgdG8gcmV1c2UgdGhlIG91 dGJvdW5kIFVEUCBwb3J0IG51bWJlciwgc2F5IHJlYWNoaW5nIGZvciB0d28gZGlmZmVyZW50IGlt YWdlcywgdGhlbiB0aGUNCiBOQVQgbWlnaHQgdGhpbmsgdGhhdCB0aGUgdHdvIGNvbm5lY3Rpb25z IGFyZSB0aGUgc2FtZSBjb25uZWN0aW9uLiBBbmQgaW4gc29tZSBzZW5zZSBpdCBpcyAtIG5vdCB0 aGUgc2FtZSBRVUlDIGNvbm5lY3Rpb24sIGJ1dCB0aGUgc2FtZSBvcGVyYXRpb25hbCBjb250ZXh0 LiBUaHVzLCB0aGUgdHdvIGNvbm5lY3Rpb25zIGhlbHBzIHJlZHVjZSBOQVQgb3ZlcmhlYWQgYW5k IGFsc28gY29vcGVyYXRlcyBpbiBrZWVwaW5nIHRoZSBOQVQgaG9sZSBvcGVuLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiB0aGUgb3RoZXIgZW5kLCBhdCB0aGUgc2VydmVy LCB0aGVyZSBpcyBhIHNlcGFyYXRlIHByb2JsZW06IFRoZSBzZXJ2ZXIgKFMpIGRvZXMgbm90IGhh dmUgdGhlIHJlcXVlc3RlZCBpbWFnZXMuIEl0IHJlYWNoZXMgdG8gb25lIG9mIGEgZmV3IHBvc3Np YmxlIGJhY2tlbmQgc2VydmVycyAoQjEsDQogQjIpLiBTaW5jZSB0aGUgc2VydmVyIFMgaXMgbm90 IGF0dGVtcHRpbmcgdG8gYmUgY2xldmVyLCBpdCBjcmVhdGVzIGEgbmV3IFFVSUMgY29ubmVjdGlv biBmcm9tIFMgdG8gQjEgb3IgQjIgZm9yIGVhY2ggaW5ib3VuZCBjbGllbnQgY29ubmVjdGlvbi4g VGhlcmUgbWF5IG9yIG1heSBub3QgYmUgYW55IE5BVCBpbnZvbHZlZCBoZXJlLCBidXQgdGhlIHNl cnZlciBTIGlzIG9ubHkgYXNzaWduZWQgYSBzaW5nbGUgSVAgYWRkcmVzcyBmb3Igb3V0Ym91bmQN CiByZXF1ZXN0cyBhbmQgY2Fubm90IGNyZWF0ZSBtb3JlIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMg dGhhdCB0aGUgbnVtYmVyIG9mIGVwaGVtZXJhbCBwb3J0cyAmIzQzOyBzYWZldHkgbWFyZ2luIHBl cm1pdHMsIHRoYXQgaXMsIHVubGVzcyBpdCBjaG9vc2VzIHRvIHJldXNlIG91dGJvdW5kIHBvcnQg bnVtYmVycyB3aGljaCBzb2x2ZXMgdGhlIHByb2JsZW0gb2YgcG9ydCBleGhhdXN0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JZiwgb24gdGhlIG90aGVyIGhhbmQsIGEg UVVJQyBjbGllbnQgd2VyZSBjby1sb2NhdGVkIHdpdGggb3RoZXIgc2VydmljZXMsIGl0IG1pZ2h0 IG5vdCBiZSBhYmxlIHRvIHJlY2VpdmUgdGhlIGNvcnJlY3QgcGFja2V0cyB3aGVuIHRoZXNlIGRp ZmZlcmVudCBzZXJ2aWNlcyBjb21wZXRlIGZvciBwb3J0DQogbnVtYmVycy4gQnV0IGhlcmUgaXQg c3VmZmljZSB0aGF0IHRoZXkgZWl0aGVyIGFncmVlIHRvIHVzZSBkaWZmZXJlbnQgcG9ydHMgKGxp a2UgUElORyB2cy4gRE5TKSwgb3IgZWFjaCBzZXJ2aWNlIGFsbG9jYXRlIGEgc2luZ2xlIGVwaGVt ZXJhbCBwb3J0IGZvciBpdHMgc2VydmljZSB2aWEgVURQIHNvY2tldCBjcmVhdGlvbi4gSW4gZWl0 aGVyIGNhc2UgdGhlIE5BVCB3b3VsZCByb3V0ZSBwYWNrZXRzIHRvIHRoZSBjb3JyZWN0IHNlcnZp Y2UgYnkgcmVseWluZw0KIG9uIDUtdHVwbGVzIGV2ZW4gaWYgUVVJQyBpdHNlbGYgZG9lcyBub3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlNvLCBnb2luZyBmdXJ0aGVyIC0g d2hhdCBpZiBzZXZlcmFsIGhvc3RzIHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNzLCBhcyBpcyB0aGUg Y2FzZSB3aXRoIGxvYWQgYmFsYW5jZXJzPyBBZ2FpbiwgNS10dXBsZXMgYXJlIHVzZWQgdG8gYmlu ZCBjb25uZWN0aW9ucyB0byBlYWNoIHVuaXF1ZSBob3N0LCBvbmx5DQogd2l0aCBmZXdlciBVRFAg cG9ydHMgdGhlcmUgaXMgbXVjaCBsZXNzIHN0YXRlIHRvIG1haW50YWluLiBUaGUgbWlkZGxld2Fy ZSBvbmx5IG5lZWQgdG8gcm91dGUgdHJhZmZpYyB0byB0aGUgY29ycmVjdCBlbmRwb2ludCwgbm90 IGRpc3Rpbmd1aXNoIGJldHdlZW4gbG9naWNhbCBRVUlDIGNvbm5lY3Rpb25zIHRoYXQgaGFwcGVu IGJldHdlZW4gdGhlIHNhbWUgdHdvIGVudGl0aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUwMjI5OTEwNDk3NDE5NDk0 NCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQg UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+T24gOSBBdWd1c3QgMjAxNyBhdCAxOS4wMy4zNSwgTHViYXNoZXYsIElnb3IgKDwvc3Bh bj48YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PmlsdWJhc2hlQGFrYW1haS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4pDQogd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2FuIHNvbWVvbmUgZWxhYm9yYXRlIG9u IOKAnFBvc3NpYmx5IGl0IHNob3VsZCBzcGVjaWZ5IHRoZSBjbGllbnQncyBjb25uZWN0aW9uIElE IGluIHRoZSBwYWNrZXQgaGVhZGVyIGFuZCB0aGVuIHRoZQ0KIG5ldyBzZXJ2ZXIgY29ubmVjdGlv biBJRCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnM/4oCdPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SXMgdGhh dCBvbmx5IGZvciDigJxTZXJ2ZXIgQ2xlYXJ0ZXh04oCdPyBXaGF0IGFib3V0IGNvbm5lY3Rpb25z IHRoYXQgc3RhcnQgb3V0IHdpdGggMFJUVCBwYWNrZXRzIOKAkyBob3cgd291bGQgdGhlIE5BVA0K IGtub3cgd2hpY2ggZmxvdyBTZXJ2ZXLigJlzIDFSVFQgcmVwbHkgYmVsb25ncyB0byAoaWYgU2Vy dmVyIGNoYW5nZXMgdGhlIENvbmVuY3Rpb25JRCk/PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TWF5YmUgcmVseWlu ZyBvbiBhIDUtdHVwbGUgaXMgbm90IHN1Y2ggYSBiYWQgaWRlYSBhZnRlciBhbGw/Jm5ic3A7IEEg TkFUIGRvZXMgbm90IG5lZWQgYSBkaWZmZXJlbnQgZXBoZW1lcmFsIHBvcnQgZm9yDQogZXZlcnkg b3V0Z29pbmcgY29ubmVjdGlvbi4mbmJzcDsgSXQgb25seSBuZWVkcyBhIGRpZmZlcmVudCBlcGhl bWVyYWwgcG9ydCBmb3Igb3V0Z29pbmcgY29ubmVjdGlvbnMgdG8gdGhlIHNhbWUgSVAuPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RXZlbiB0aGVuLCBpZiB0aGUgTkFUIGlzIHdpbGxpbmcgdG8gZG8gc29tZXRoaW5n IHNwZWNpYWwgZm9yIFFVSUMsIGl0IGNhbiBiZSBhIG11Y2ggc2ltcGxlciB0aGluZyB0aGFuIGV4 YW1pbmUgUVVJQw0KIHRyYW5zcG9ydCBwYXJhbXMuJm5ic3A7IFRoZSBOQVQgY2FuIHNpbXBseSBy ZXNlcnZlIGEgc2luZ2xlIGVwaGVtZXJhbCBwb3J0IGZvciBhbGwgMVJUVCBRVUlDIHBhY2tldHMu Jm5ic3A7IFRoYXQgaXMsIGFsbCBvdXRnb2luZyBjbGVhcnRleHQgYW5kIDBydHQgUVVJQyBwYWNr ZXRzIHdvdWxkIHJlcXVpcmUgYSBkaXN0aW5jdCA1LXR1cGxlLCBidXQgb25jZSB0aGUgY29ubmVj dGlvbiBtaWdyYXRlcyB0byAxUlRULCB0aGUgZXBoZW1lcmFsIHBvcnQgaXQgdXNlZCBjYW4NCiBi ZSBmcmVlZCwgYW5kIGFsbCAxUlRUIHBhY2tldHMgc291cmNlZCBmcm9tIHRoZSByZXNlcnZlZCBR SVVDIHBvcnQuJm5ic3A7IFRoYXQgd291bGQgd29yaywgc2luY2UgYWxsIDFSVFQgcGFja2V0cyAo Ym90aCBmcm9tIGNsaWVudCBhbmQgc2VydmVyKSB3b3VsZCBiZSB1c2luZyBTZXJ2ZXItc2VsZWN0 aW9uIENvbm5lY3Rpb25JRC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjx1bCB0eXBl PSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwyIGxldmVsMSBsZm8zIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWdvcjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBJYW4gU3dldHQgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdv b2dsZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDA4 LCAyMDE3IDc6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4g Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPm1pa2tlbGZqQGdtYWlsLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs7IFJ5YW4gSGFtaWx0b24gJmx0Ozwvc3Bhbj48YSBocmVmPSJt YWlsdG86cmNoQGdvb2dsZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+cmNoQGdvb2dsZS5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogNS10 dXBsZSB1bmlxdWVzczwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WW91J3JlIHJpZ2h0LCBlcGhlbWVyYWwgcG9ydCBl eGhhdXN0aW9uIGlzIGEgdmVyeSByZWFsIHBvdGVudGlhbCBpc3N1ZSwgYW5kIEkgdGhpbmsgd2Ug c2hvdWxkIGVuc3VyZSBtdWx0aXBsZSBRVUlDDQogY29ubmVjdGlvbnMgY2FuIHJ1biBvdmVyIHRo ZSBzYW1lIDUtdHVwbGUgYW5kIHdlIGRvbid0IHNwZWNpZnkgUVVJQyBpbiBhIHdheSB0aGF0IHBy ZWNsdWRlcyB0aGF0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkkgYmVsaWV2ZSB5b3UncmUgY29ycmVjdCB0aGF0IHRoZSBjdXJyZW50IFNlcnZl ciBDbGVhcnRleHQgbWFrZXMgdGhpcyBpbXBvc3NpYmxlIGlmIHRoZSBzZXJ2ZXIgY2hhbmdlcyB0 aGUgY29ubmVjdGlvbg0KIElELiZuYnNwOyBQb3NzaWJseSBpdCBzaG91bGQgc3BlY2lmeSB0aGUg Y2xpZW50J3MgY29ubmVjdGlvbiBJRCBpbiB0aGUgcGFja2V0IGhlYWRlciBhbmQgdGhlbiB0aGUg bmV3IHNlcnZlciBjb25uZWN0aW9uIElEIGluIHRoZSB0cmFuc3BvcnQgcGFyYW1ldGVycz8mbmJz cDsNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzcx NCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1 dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPW1Ya2lLS2hfRmtSTy1N QU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1wO3M9LUR0dnRrbURfbFpKZ0V0anZ1Z3g0 T3hza1JBVW1xcHk1TmdDZ056YWhHdyZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5UaGUgdGV4dCBpcyBhbHNvIG1pc3Npbmcgc29tZSBkZXRhaWxzIG9uIGhvdyBj aGFuZ2luZyB0aGUgY29ubmVjdGlvbiBJRCBzaG91bGQgd29yayBmb3IgU3RhdGVsZXNzIFJldHJ5 LCBzZWUmbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lz c3Vlc183MTMmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9 RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT1tWGtpS0to X0ZrUk8tTUFObzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JmFtcDtzPWNWXzVBVUpQb1c0NlNR SEpUMU5peV96dVJDeDBFN3gyODgtTDQ2LXpoZFkmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNz dWVzLzcxMzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiwNCiBzbyBJJ2QgZXhwZWN0IHNv bWUgaW1wcm92ZW1lbnRzIGluIHRoZSBuZWFyIGZ1dHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiBTdW4sIEF1ZyA2LCAyMDE3IGF0IDEw OjQzIEFNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5taWtrZWxmakBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQog d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIy ODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAz NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2Mzky NDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkhpIFJ5YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1t XzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3 NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcy OTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgY2FuIGRpZyBkb3duIGluIG1vcmUgZGV0 YWlsIGlmIHRoZXJlIGlzIGludGVyZXN0LiBNZWFud2hpbGUsIHNvbWUgZXhhbXBsZXMgd2hlcmUg dGhlIHRyYW5zcG9ydCBkb2N1bWVudCBpcyBub3QNCiBjb21wYXRpYmxlIHdpdGggbXkgcmVxdWVz dCBpczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgw MDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3 MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2 NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHZlcnNpb24gbmVnb3RpYXRpb24gcGFja2V0 IGlzIG9rIC0gaXQgcmVmbGVjdHMgdGhlIGNsaWVudCB2ZXJzaW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1t Xy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdpdGh1Yi5pb19iYXNlLTJE ZHJhZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRtbC0yM3BhY2tldC0yRHZl cnNpb24mYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpu M2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT1tWGtpS0toX0Zr Uk8tTUFObzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JmFtcDtzPWduejhQSjRSUU1xNnctX1dG YTFSSFlNVGdwZ3RnSW1ha1IxcVp3bV91VGsmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPmh0dHBzOi8vcXVpY3dnLmdpdGh1Yi5pby9iYXNlLWRyYWZ0cy9kcmFmdC1p ZXRmLXF1aWMtdHJhbnNwb3J0Lmh0bWwjcGFja2V0LXZlcnNpb248L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWls LW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5 Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgx NzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QnV0Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFp bC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdpdGh1Yi5pb19iYXNl LTJEZHJhZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRtbC0yM3BhY2tldC0y RHNlcnZlci0yRGNsZWFydGV4dCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFt cDttPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1wO3M9RGpX ZG84WWh1OHQ3aDF6cWQ3Qkl4azlfVExVMzZBeG1kWjBEbWhabjZ2RSZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlvL2Jhc2Ut ZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuaHRtbCNwYWNrZXQtc2VydmVyLWNsZWFy dGV4dDwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1 NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPlRoZSBjb25uZWN0aW9uIElEIGZpZWxkDQog aW4gYSBTZXJ2ZXIgQ2xlYXJ0ZXh0IHBhY2tldCBjb250YWlucyBhIGNvbm5lY3Rpb24gSUQgdGhh dCBpcyBjaG9zZW4gYnkgdGhlIHNlcnZlciAoc2VlJm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdp dGh1Yi5pb19iYXNlLTJEZHJhZnRzX2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRt bC0yM2Nvbm5lY3Rpb24tMkRpZCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBO NkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFt cDttPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1wO3M9NVNI NnU3QWFIX2FyeEdZM3lFZXF3eWhpbzhkVFg5U01RV0ZjMlRJbGhZMCZhbXA7ZT0iIHRhcmdldD0i X2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkE2NDk2O3RleHQtZGVjb3JhdGlvbjpu b25lIj5TZWN0aW9uDQogNS42PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMz MzMzIj4pLiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1t Xy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGJyZWFr cyBsaW5rYWdlIHRvIHRoZSBvcmlnaW5hbCBjbGllbnQgY29ubmVjdGlvbiBpZCBzbyB0aGUgY2xp ZW50IGNhbm5vdCB0ZWxsIHdoaWNoIGNvbm5lY3Rpb24gdGhlIHJlc3BvbnNlDQogYmVsb25ncyB0 byB1bmxlc3MgbG9va2luZyBpbnRvIDUtdHVwbGUsIG9yIHRlc3RpbmcgYWxsIHJlY2VudCBjb25u ZWN0aW9ucyBhZ2FpbnN0IEFFQUQgc2lnbmF0dXJlIChkZXBlbmRpbmcgb24gd2hlcmUgdGhpcyBs YW5kcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4 MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIz NzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1 NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBub3QgY292ZXJlZCBhbGwgb3RoZXIg cG9zc2libGUgc2VydmVyIHJlc3BvbnNlcywgYnV0IHNpbWlsYXIgY29uY2VybnMgYXBwbHkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4 NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2 Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5JdCBpcyBub3QgYSBtYWpvciBjaGFuZ2UsIGJ1dCBjdXJyZW50bHkgaXQgaXMgbm90IHBv c3NpYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82 ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYy MzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3Mjky NTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Bbm90aGVyIGlzc3VlIGlzIGhvc3RpbGUgcmVz cG9uc2UgdG8gaW5pdGlhbCBjb25uZWN0aW9uIHNldHVwLCBhbmQgcGxhaW4gZXJyb3JzIC0gaG93 IHRvIHlvdSByZXBseSB3aXRoIGFuIGVycm9yLg0KIEhhdmluZyB0aGUgY29ubmVjdGlvbiBpZCBm cm9tIHRoZSBjbGllbnQgbWFrZXMgaXQgcmVhc29uYWJseSBlYXN5IHRvIGRlYWwgd2l0aCAtIHNp bWlsYXIgdG8gdmVyc2lvbiBuZWdvdGlhdGlvbi4gQWx0ZXJuYXRpdmVseSB5b3UgaGF2ZSB0byBy ZWx5IG9uIDUtdHVwbGVzLiBUaGlzIHJlcXVpcmVzIGNhcmVmdWwgYW5hbHlzaXMgb2YgYm90aCB0 aGUgdHJhbnNwb3J0IGRvYyBhbmQgcG9zc2libHkgVExTIGFuZCB0aGlucyBhcmUgbm90IGZ1bGx5 IHNldHRsZWQuDQogU3RhdGVsZXNzIHJlc2V0IGlzIHJlbGF0ZWQgdG8gdGhpcy4gSSB3aWxsIG5v dCBhcmd1ZSBzdHJvbmdseSBvbiB0aGlzIGJlY2F1c2Ugc2luY2UgSSBsYXN0IGxvb2tlZCBhdCBp dCwgbmV3IEFFQUQgZW5jcnlwdGlvbiBpcyBiZWluZyBkaXNjdXNzZWQsIGFuZCBJIGhhdmUgbm90 IGFuYWx5c2VkIHRoaXMgaW4gZGV0YWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgx NzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1t Xy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGVuIHRoZXJl IGlzIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBUaGlzIGFsc28gcmVxdWlyZXMgY2FyZWZ1bCBhbmFs eXNpcy4gSeKAmW0gbm90IHN1cmUgaWYgaXQgY3VycmVudGx5IGNvdmVycyBteQ0KIHJlcXVlc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUy MjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIy MDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Imdt YWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3 MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPknigJltIHN1cmUgdGhlcmUgYXJlIHNldmVyYWwgb3RoZXIg cGxhY2VzIHdpdGggaW1wbGljaXQgYXNzdW1wdGlvbnMgdGhhdCBJIGFtIG5vdCBhYmxlIHRvIGxp c3Qgb2ZmIG1lbW9yeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Imdt YWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3 MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMw OTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIChteSkgYmFzaWMgcnVsZSBp cyB0aGUgYW55IGNoYW5nZSBpbiBjb25uZWN0aW9uIElEIHNob3VsZCByZWZlciB0byB0aGUgcHJl dmlvdXMgSUQgd2l0aG91dCByZWx5aW5nIG9uIGV4dGVybmFsDQogc3RhdGUgc3VjaCBhcyA1LXR1 cGxlcyBvciBUTFMgZXh0ZW5zaW9uIHN0YXRlICh3aGljaCByZXF1aXJlcyBjcnlwdG8gc3RhdGUg dG8gYWNjZXNzIGFuZCBjb21wbGljYXRlcyB0aGluZ3MpLiBBbHNvLCBkdWUgY29uY2VybnMgb2Yg cHJpdmFjeSBjb25jZXJucyB0aGlzIGxpbmthZ2UgYmV0d2VlbiBjb25uZWN0aW9uIElE4oCZcyBz aG91bGQgb25seSBiZSBwb3NzaWJsZSBieSBwZWVycywgZXhjZXB0cyBmb3IgdGhlIGluaXRpYWwg Y2xpZW50IHRvIHNlcnZlcg0KIGNvbm5lY3Rpb24gdHJhbnNpdGlvbiB0aGF0IGlzIGFsc28gdmlz aWJsZSB0byBhbnkgcGFydHkgb24tcGF0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4 MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwt bV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZv bnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gYWRkaXRp b24gdG8gdGhlIGFib3ZlIGVuY29kaW5nIGNvbmNlcm5zLCBpdCBtYXkgYWxzbyBiZSBoZWxwZnVs IHRvIGV4cGxpY2l0bHkgc3RhdGUgdGhhdCB0aGUgc2FtZSBVRFAgcG9ydCBtYXkNCiBiZSB1c2Vk IHRvIGluaXRpYXRlIG11bHRpcGxlIGluZGVwZW5kZW50IFFVSUMgY29ubmVjdGlvbiB0byB0aGUg c2FtZSBzZXJ2ZXIgVURQIHBvcnQgd2hlbiBjb25uZWN0aW9uIElEIGhhcyBiZWVuIG5lZ290aWF0 ZWQgdG8gYmUgcHJlc2VudCAtIG9yIGZ1cnRoZXIgZGV0YWlsIHRoaXMgcG9zc2liaWxpdHkgYXMg c29tZXRoaW5nIHRoYXQgY2FuIGJlIG5lZ290aWF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1 NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2 OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAw Njk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcy MDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+U29tZSBvdGhlciBwb2ludHMgSSBmb3JnZXQgdG8gbWVudGlvbiByZWdhcmRp bmcgYmVuZWZpdHMgb2Ygbm9uLXVuaXF1ZSB0dXBsZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1 NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2 OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9j dXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjUp IG5vIGludGVyZmVyZW5jZSB3aXRoIE9TIGlzIG5lY2Vzc2FyeSBpbiBvcmRlciB0byBlc3RhYmxp c2ggYSBuZXcgY29ubmVjdGlvbiB0byBhbiBleGlzdGluZyBlbmRwb2ludCBiZWNhdXNlDQogbm8g bmV3IGVwaGVtZXJhbCBwb3J0IGlzIG5lZWRlZC4gVGhpcyBtYXkgYWxzbyBzaW1wbGlmeSBjbGVh biB1cCBhbmQgc3RhdGUgbWFuYWdlbWVudCwgZXNwZWNpYWxseSBzZXJ2ZXIgdG8gc2VydmVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21haWwtbV82ODAwNjk1MjIy ODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAz NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJnbWFp bC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0 OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj42KSBOZXRtYXAgYW5kIHNpbWlsYXIgaGlnaCBzcGVlZCBpbnRl cmZhY2VzIHdvdWxkIGJlIHNpbXBsZXIgd2l0aG91dCBoYXZpbmcgdG8gZGVhbCB3aXRoIGVwaGVt ZXJhbCBwb3J0IGFsbG9jYXRpb24sDQogZXNwZWNpYWxseSBzZXJ2ZXIgdG8gc2VydmVyIHdoZXJl IGJvdGggZW5kIHBvaW50cyBjYW4gcmVmZXJlbmNlIGVhY2ggb3RoZXIsIGFuZCB3aGVyZSBpdCBt aWdodCBiZSByYW5kb20gd2hpY2ggZW5kcG9pbnQgYWN0dWFsbHkgaW5pdGlhdGVzIHRvIHRoZSBj b25uZWN0aW9uIChhcyBpbiBDb3JkIC8gS2FkZW1saWEgc3R5bGUgb3ZlcmxheSBuZXR3b3Jrcyk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImdtYWlsLW1fNjgwMDY5NTIy Mjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIw MzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iZ21h aWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcx NDkyNzYyMzcyMDQyMjAzNmJsb29wX3NpZ25fMTUwMjAyOTM4NzA1ODg1NTkzNiI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2IGlkPSJnbWFpbC1tXzY4MDA2OTUyMjI4NjM5 MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxv b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c3c1ede4958644bf8f582e8e8370634eusma1exdag1mb5msgcorpak_-- From nobody Wed Aug 9 20:34:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D791F13252C for ; Wed, 9 Aug 2017 20:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8Ms6hRFQxCB for ; Wed, 9 Aug 2017 20:34:17 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB45132534 for ; Wed, 9 Aug 2017 20:34:17 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id u207so51443013ywc.3 for ; Wed, 09 Aug 2017 20:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RcFKvltvX0L7IqJHvkeYQSyaW+YVuePWkORghThwZRg=; b=RSQ03EtNa+sR4EP5QPOx+ExPIxT2Vz8ds+5LxgnzfTWLdI6D5+DkhD7vx9A3Qs/Knw 0kcsgGdWPW3ur8Um4HRbm8y7b8M32sOJCSE43tfIn3E83OTdQScT2bhRyX1z928D1+Vo iwgGprL/D22Kea848QDI6+RyPPsS3m04aQ+Iwl+dPQqQI60ikENMtqz/gdY9Mu0OoYDC FFugjVSCP1mm1+jt2GPMrOtaQGT2wA+vYM0hbQYRNdjjHkdeDObWn0vhFXXZcujszUCq 4HclkcaU+LP/Ls2eJDAcPI5yJjLeHrbqNziEPfJ7hdt3Z02UDRCzSd9oz0zT2uQs7bD6 rO5g== 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=RcFKvltvX0L7IqJHvkeYQSyaW+YVuePWkORghThwZRg=; b=dkl4FJJvbTgvBq4gDg7Jqp1LXvWqitxGqj62yco4OveZPG/atA3rQSd3KiCi+K93V1 PhM1flRQyq2wGsexDCLgcX8m51NQMuO+9p+/5KaKeNUA9fBMqCw/HplxXF/agAgzuCwR Xj7ychXoCNoUwZxyZkNFGRnHAgOxAwck3l32BFGV4A2NFPT+cstWtkszZXSQq3bat1fy 5en/fSe6rupqDmBK5SK5e9lqCpHCakEegDUq2cDcs+FkDgPn2wFFD883BOpCpxjSF2AF bmpVv453dXVoF4TKpQln6LOm0UtoewqzMQO6zO7Vj4QDDs6s6uHbJYplwEgTuiZSzneV XVHg== X-Gm-Message-State: AHYfb5huduP7EiNrkDOx+4FMyqxwKvB4JrawGeZOVLK2QHpSa1Sw9z1g V0eklsW3bnoclmtCEEH/7UY0BnYnZjBK X-Received: by 10.13.221.19 with SMTP id g19mr8750361ywe.407.1502336056073; Wed, 09 Aug 2017 20:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Wed, 9 Aug 2017 20:33:55 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 9 Aug 2017 23:33:55 -0400 Message-ID: Subject: Re: 5-tuple uniquess To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ryan Hamilton , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c064ed2f5648205565dde9b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 03:34:21 -0000 --94eb2c064ed2f5648205565dde9b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In Prague, we decided that the 5-tuple couldn't change during the handshake, but we didn't say that a 5-tuple indicated a single QUIC connection. For IPv6, a flow label can be used to spread load. From my perspective, the goal here is to allow multiple QUIC connections to share a 5-tuple, not to recommend it for all use cases. For example, it may make sense to preclude it for HTTP over QUIC clients? On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor wrote= : > I see =E2=80=9Cport reuse=E2=80=9D as an instance of a generic =E2=80=9CN= AT rebinding=E2=80=9D that QUIC > is built for. We=E2=80=99ve maintained previously, however, that QUIC to= lerance to > =E2=80=9Cconnection migration / NAT rebinding=E2=80=9D during connection = establishment is > out of scope. This proposal would seem to revisit that scope. > > > > You may indeed want to open multiple concurrent connections from S to B, > hoping to spread your connections among multiple servers behind B. But i= t > may actually be counter-productive to use a single 5-tuple, if B is behin= d > an ECMP router acting as a load balancer. Moreover, this will also defea= t > RSS/RPS/RFS > load > balancing mechanisms within servers. Be aware. > > > > - Igor > > > > > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Wednesday, August 09, 2017 1:33 PM > *To:* Lubashev, Igor ; Ian Swett > > *Cc:* Ryan Hamilton ; IETF QUIC WG > *Subject:* RE: 5-tuple uniquess > > > > This may not address all your concerns, but I think perhaps you are > looking at the problem from the wrong end with respect to ephemeral port > exhaustion: > > > > In a typical NAT scenario you have many clients reaching for one server, > each client likely passing a different NAT. > > Hence each connection will be a unique 5-tuple, even if QUIC itself is no= t > making any effort to achieve this. > > > > Now, if one of these clients creates two connections to the same server > and chooses to reuse the outbound UDP port number, say reaching for two > different images, then the NAT might think that the two connections are t= he > same connection. And in some sense it is - not the same QUIC connection, > but the same operational context. Thus, the two connections helps reduce > NAT overhead and also cooperates in keeping the NAT hole open. > > > > On the other end, at the server, there is a separate problem: The server > (S) does not have the requested images. It reaches to one of a few possib= le > backend servers (B1, B2). Since the server S is not attempting to be > clever, it creates a new QUIC connection from S to B1 or B2 for each > inbound client connection. There may or may not be any NAT involved here, > but the server S is only assigned a single IP address for outbound reques= ts > and cannot create more concurrent connections that the number of ephemera= l > ports + safety margin permits, that is, unless it chooses to reuse outbou= nd > port numbers which solves the problem of port exhaustion. > > > > If, on the other hand, a QUIC client were co-located with other services, > it might not be able to receive the correct packets when these different > services compete for port numbers. But here it suffice that they either > agree to use different ports (like PING vs. DNS), or each service allocat= e > a single ephemeral port for its service via UDP socket creation. In eithe= r > case the NAT would route packets to the correct service by relying on > 5-tuples even if QUIC itself does not. > > > > So, going further - what if several hosts use the same IP address, as is > the case with load balancers? Again, 5-tuples are used to bind connection= s > to each unique host, only with fewer UDP ports there is much less state t= o > maintain. The middleware only need to route traffic to the correct > endpoint, not distinguish between logical QUIC connections that happen > between the same two entities. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote: > > Can someone elaborate on =E2=80=9CPossibly it should specify the client's > connection ID in the packet header and then the new server connection ID = in > the transport parameters?=E2=80=9D > > > > Is that only for =E2=80=9CServer Cleartext=E2=80=9D? What about connectio= ns that start out > with 0RTT packets =E2=80=93 how would the NAT know which flow Server=E2= =80=99s 1RTT reply > belongs to (if Server changes the ConenctionID)? > > > > Maybe relying on a 5-tuple is not such a bad idea after all? A NAT does > not need a different ephemeral port for every outgoing connection. It on= ly > needs a different ephemeral port for outgoing connections to the same IP. > > > > Even then, if the NAT is willing to do something special for QUIC, it can > be a much simpler thing than examine QUIC transport params. The NAT can > simply reserve a single ephemeral port for all 1RTT QUIC packets. That i= s, > all outgoing cleartext and 0rtt QUIC packets would require a distinct > 5-tuple, but once the connection migrates to 1RTT, the ephemeral port it > used can be freed, and all 1RTT packets sourced from the reserved QIUC > port. That would work, since all 1RTT packets (both from client and > server) would be using Server-selection ConnectionID. > > > > - Igor > > > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, August 08, 2017 7:01 PM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* IETF QUIC WG ; Ryan Hamilton > *Subject:* Re: 5-tuple uniquess > > > > You're right, ephemeral port exhaustion is a very real potential issue, > and I think we should ensure multiple QUIC connections can run over the > same 5-tuple and we don't specify QUIC in a way that precludes that. > > > > I believe you're correct that the current Server Cleartext makes this > impossible if the server changes the connection ID. Possibly it should > specify the client's connection ID in the packet header and then the new > server connection ID in the transport parameters? > https://github.com/quicwg/base-drafts/issues/714 > > > > > The text is also missing some details on how changing the connection ID > should work for Stateless Retry, see https://github.com/quicwg/ > base-drafts/issues/713 > , > so I'd expect some improvements in the near future. > > > > On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > > > Hi Ryan, > > > > I can dig down in more detail if there is interest. Meanwhile, some > examples where the transport document is not compatible with my request i= s: > > > > The version negotiation packet is ok - it reflects the client version > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-version > > > > > But > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-server-cleartext > > > "The connection ID field in a Server Cleartext packet contains a > connection ID that is chosen by the server (see Section 5.6 > > )." > > This breaks linkage to the original client connection id so the client > cannot tell which connection the response belongs to unless looking into > 5-tuple, or testing all recent connections against AEAD signature > (depending on where this lands). > > > > I have not covered all other possible server responses, but similar > concerns apply. > > It is not a major change, but currently it is not possible. > > > > Another issue is hostile response to initial connection setup, and plain > errors - how to you reply with an error. Having the connection id from th= e > client makes it reasonably easy to deal with - similar to version > negotiation. Alternatively you have to rely on 5-tuples. This requires > careful analysis of both the transport doc and possibly TLS and thins are > not fully settled. Stateless reset is related to this. I will not argue > strongly on this because since I last looked at it, new AEAD encryption i= s > being discussed, and I have not analysed this in detail. > > > > Then there is connection migration. This also requires careful analysis. > I=E2=80=99m not sure if it currently covers my request. > > > > I=E2=80=99m sure there are several other places with implicit assumptions= that I > am not able to list off memory. > > > > The (my) basic rule is the any change in connection ID should refer to th= e > previous ID without relying on external state such as 5-tuples or TLS > extension state (which requires crypto state to access and complicates > things). Also, due concerns of privacy concerns this linkage between > connection ID=E2=80=99s should only be possible by peers, excepts for the= initial > client to server connection transition that is also visible to any party > on-path. > > > > In addition to the above encoding concerns, it may also be helpful to > explicitly state that the same UDP port may be used to initiate multiple > independent QUIC connection to the same server UDP port when connection I= D > has been negotiated to be present - or further detail this possibility as > something that can be negotiated. > > > > > > Some other points I forget to mention regarding benefits of non-unique > tuples: > > > > 5) no interference with OS is necessary in order to establish a new > connection to an existing endpoint because no new ephemeral port is neede= d. > This may also simplify clean up and state management, especially server t= o > server. > > > > 6) Netmap and similar high speed interfaces would be simpler without > having to deal with ephemeral port allocation, especially server to serve= r > where both end points can reference each other, and where it might be > random which endpoint actually initiates to the connection (as in Cord / > Kademlia style overlay networks) > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > > > --94eb2c064ed2f5648205565dde9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Prague, we decided that the 5-tuple couldn't c= hange during the handshake, but we didn't say that a 5-tuple indicated = a single QUIC connection.

For IPv6, a flow label can be= used to spread load.=C2=A0 From my perspective, the goal here is to allow = multiple QUIC connections to share a 5-tuple, not to recommend it for all u= se cases.=C2=A0 For example, it may make sense to preclude it for HTTP over= QUIC clients?

On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor <ilubashe@akamai.com<= /a>> wrote:

I see =E2=80=9Cport reuse=E2=80=9D as an instance o= f a generic =E2=80=9CNAT rebinding=E2=80=9D that QUIC is built for.=C2=A0 W= e=E2=80=99ve maintained previously, however, that QUIC tolerance to =E2=80= =9Cconnection migration / NAT rebinding=E2=80=9D during connection establishment is out of scope.=C2= =A0 This proposal would seem to revisit that scope.

=C2=A0

You may indeed want to open multiple concurrent con= nections from S to B, hoping to spread your connections among multiple serv= ers behind B.=C2=A0 But it may actually be counter-productive to use a single 5-tuple, if B is behind an ECMP router acting as a load ba= lancer.=C2=A0 Moreover, this will also defeat RSS/RPS/RFS load balancing mechanisms within servers= .=C2=A0 Be aware.

=C2=A0

  • = Igor

=C2=A0

=C2=A0

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgen= sen [mailto:mikkelf= j@gmail.com]
Sent: Wednesday, August 09, 2017 1:33 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswett@google.com>
Cc: Ryan Hamilton <rch@google.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: 5-tuple uniquess

=C2=A0

This may not address all your concerns, but I thi= nk perhaps you are looking at the problem from the wrong end with respect t= o ephemeral port exhaustion:

=C2=A0

In a typical NAT scenario you have many clients r= eaching for one server, each client likely passing a different NAT.<= u>

Hence each connection will be a unique 5-tuple, e= ven if QUIC itself is not making any effort to achieve this.<= /span>

=C2=A0

Now, if one of these clients creates two connecti= ons to the same server and chooses to reuse the outbound UDP port number, s= ay reaching for two different images, then the NAT might think that the two connections are the same connection. And in s= ome sense it is - not the same QUIC connection, but the same operational co= ntext. Thus, the two connections helps reduce NAT overhead and also coopera= tes in keeping the NAT hole open.

=C2=A0

On the other end, at the server, there is a separ= ate problem: The server (S) does not have the requested images. It reaches = to one of a few possible backend servers (B1, B2). Since the server S is not attempting to be clever, it creates a new Q= UIC connection from S to B1 or B2 for each inbound client connection. There= may or may not be any NAT involved here, but the server S is only assigned= a single IP address for outbound requests and cannot create more concurrent connections that the number of = ephemeral ports + safety margin permits, that is, unless it chooses to reus= e outbound port numbers which solves the problem of port exhaustion.=

=C2=A0

If, on the other hand, a QUIC client were co-loca= ted with other services, it might not be able to receive the correct packet= s when these different services compete for port numbers. But here it suffice that they either agree to use different ports= (like PING vs. DNS), or each service allocate a single ephemeral port for = its service via UDP socket creation. In either case the NAT would route pac= kets to the correct service by relying on 5-tuples even if QUIC itself does not.

=C2=A0

So, going further - what if several hosts use the= same IP address, as is the case with load balancers? Again, 5-tuples are u= sed to bind connections to each unique host, only with fewer UDP ports there is much less state to maintain. The middleware = only need to route traffic to the correct endpoint, not distinguish between= logical QUIC connections that happen between the same two entities.=

=C2=A0

Kind Regards,

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

=C2=A0

On 9 August 2017 at 19.03.35, L= ubashev, Igor (ilubashe@akamai.com) wrote:

Can someone elaborate on =E2=80=9CPossibly it shoul= d specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters?=E2=80=9D

=C2=A0

Is that only for =E2=80=9CServer Cleartext=E2=80=9D= ? What about connections that start out with 0RTT packets =E2=80=93 how wou= ld the NAT know which flow Server=E2=80=99s 1RTT reply belongs to (if Server changes = the ConenctionID)?

=C2=A0

Maybe relying on a 5-tuple is not such a bad idea a= fter all?=C2=A0 A NAT does not need a different ephemeral port for every outgoing connection.=C2=A0 It only needs a different ephemeral port = for outgoing connections to the same IP.

=C2=A0

Even then, if the NAT is willing to do something sp= ecial for QUIC, it can be a much simpler thing than examine QUIC transport params.=C2=A0 The NAT can simply reserve a single ephemeral port= for all 1RTT QUIC packets.=C2=A0 That is, all outgoing cleartext and 0rtt = QUIC packets would require a distinct 5-tuple, but once the connection migr= ates to 1RTT, the ephemeral port it used can be freed, and all 1RTT packets sourced from the reserved QIUC port.=C2=A0 = That would work, since all 1RTT packets (both from client and server) would= be using Server-selection ConnectionID.

=C2=A0

  • Igor

=C2=A0

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, August 08, 2017 7:01 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>; Ryan Hamilton <rch@google.com&g= t;
Subject: Re: 5-tuple uniquess

=C2=A0

You're right, ephemeral port exhaustion is a = very real potential issue, and I think we should ensure multiple QUIC connections can run over the same 5-tuple and we don't specify QUIC in= a way that precludes that.

=C2=A0

I believe you're correct that the current Ser= ver Cleartext makes this impossible if the server changes the connection ID.=C2=A0 Possibly it should specify the client's connection ID in the= packet header and then the new server connection ID in the transport param= eters?=C2=A0 https://github.com/quicwg/= base-drafts/issues/714

=C2=A0

The text is also missing some details on how chan= ging the connection ID should work for Stateless Retry, see=C2=A0https://github.com/quicwg/base-= drafts/issues/713, so I'd expect some improvements in the near future.

=C2=A0

On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3= =B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

=C2=A0=

Hi Ryan,

=C2=A0

I can dig down in more detail if there is interes= t. Meanwhile, some examples where the transport document is not compatible with my request is:

=C2=A0

The version negotiation packet is ok - it reflect= s the client version

https://quicwg.github.io/base-drafts= /draft-ietf-quic-transport.html#packet-version<= u>

=C2=A0

But=C2=A0

https://quicwg.github.io/base-= drafts/draft-ietf-quic-transport.html#packet-server-cleartex= t

"The connection ID f= ield in a Server Cleartext packet contains a connection ID that is chosen by th= e server (see=C2=A0Sect= ion 5.6)."

This breaks linkage to the original client connec= tion id so the client cannot tell which connection the response belongs to unless looking into 5-tuple, or testing all recent connections = against AEAD signature (depending on where this lands).

=C2=A0

I have not covered all other possible server resp= onses, but similar concerns apply.

It is not a major change, but currently it is not= possible.

=C2=A0

Another issue is hostile response to initial conn= ection setup, and plain errors - how to you reply with an error. Having the connection id from the client makes it reasonably easy to deal = with - similar to version negotiation. Alternatively you have to rely on 5-= tuples. This requires careful analysis of both the transport doc and possib= ly TLS and thins are not fully settled. Stateless reset is related to this. I will not argue strongly on this beca= use since I last looked at it, new AEAD encryption is being discussed, and = I have not analysed this in detail.

=C2=A0

Then there is connection migration. This also req= uires careful analysis. I=E2=80=99m not sure if it currently covers my request.

=C2=A0

I=E2=80=99m sure there are several other places w= ith implicit assumptions that I am not able to list off memory.

=C2=A0

The (my) basic rule is the any change in connecti= on ID should refer to the previous ID without relying on external state such as 5-tuples or TLS extension state (which requires crypto state= to access and complicates things). Also, due concerns of privacy concerns = this linkage between connection ID=E2=80=99s should only be possible by pee= rs, excepts for the initial client to server connection transition that is also visible to any party on-path.=

=C2=A0

In addition to the above encoding concerns, it ma= y also be helpful to explicitly state that the same UDP port may be used to initiate multiple independent QUIC connection to the same serve= r UDP port when connection ID has been negotiated to be present - or furthe= r detail this possibility as something that can be negotiated.

=C2=A0

=C2=A0

Some other points I forget to mention regarding b= enefits of non-unique tuples:

=C2=A0

5) no interference with OS is necessary in order = to establish a new connection to an existing endpoint because no new ephemeral port is needed. This may also simplify clean up and state= management, especially server to server.

=C2=A0

6) Netmap and similar high speed interfaces would= be simpler without having to deal with ephemeral port allocation, especially server to server where both end points can reference each other= , and where it might be random which endpoint actually initiates to the con= nection (as in Cord / Kademlia style overlay networks)=

=C2=A0

Kind Regards,

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

=C2=A0=

=C2=A0


--94eb2c064ed2f5648205565dde9b-- From nobody Wed Aug 9 21:04:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6A7132546 for ; Wed, 9 Aug 2017 21:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, 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 0nqZL6ByLu1Q for ; Wed, 9 Aug 2017 21:03:56 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A2A132545 for ; Wed, 9 Aug 2017 21:03:56 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7A41v7X008083; Thu, 10 Aug 2017 05:03:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=D5DqhpRXfu5TGn2szdEJWylTZU8WfdKJ2/AnAobY61Q=; b=fyV3r7WoprwPkcY9k/v2hL7YpMCqhWaKbWka/6mq1KBdSW/qqm3Xl4+hso2XmnAby6i5 vKl5Kx71B9dGWY/G5XxEA0BJLMisqLTpHGOk0y+GqCbCF8REPu7QT8XKBnyZeE5faUZM 68CfLCgq7PBcff20ot6INDOsOuMSBWh6GBtgU8ONYoxWUTjBSuK6QI5VhLgcQ9RvVbKy XslY+CPGkwIpoSrFiSNXRjS+ntDPXMpM+ktg2ryNazz4ThMAelvOmhVGfxN5rcmfROYG LXiulOV24iYXHiFgZj+U66KlT/VGmtdRlE6NEwKCDjfWgjmHJ0iOTTiql0Q9qlKspwhF PA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2c7yd0jsum-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Aug 2017 05:03:53 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7A41Re6011719; Thu, 10 Aug 2017 00:03:52 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2c59bv2g2e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 10 Aug 2017 00:03:51 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 10 Aug 2017 00:03:50 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 10 Aug 2017 00:03:50 -0400 From: "Lubashev, Igor" To: Ian Swett CC: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Ryan Hamilton , IETF QUIC WG Subject: RE: 5-tuple uniquess Thread-Topic: 5-tuple uniquess Thread-Index: AQHTDp1bhJPQi5zq4kWW5+Ln50FN+6J3oyiAgAABdoCAAAX3AIADr5aAgADmn5CAAFA6gP//3AnggADLwoD//71lwA== Date: Thu, 10 Aug 2017 04:03:50 +0000 Message-ID: <648f6f5202684eb3b7e9c516592f44a0@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.0] Content-Type: multipart/alternative; boundary="_000_648f6f5202684eb3b7e9c516592f44a0usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-10_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708100065 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-10_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708100065 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 04:04:00 -0000 --_000_648f6f5202684eb3b7e9c516592f44a0usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgcGFydGljdWxhcmx5IGFnYWluc3QgNS10dXBsZS1zaGFyaW5nLCBpZiBpdCBjYW4g YmUgbWFkZSB0byB3b3JrLiAgQnV0IGFsbG93aW5nIHN1Y2ggc2NlbmFyaW9zIGlzIGVmZmVjdGl2 ZWx5IG1ha2luZyB0aGUgNS10dXBsZXMgdW51c2FibGUgZm9yIGNvbm5lY3Rpb24gaWRlbnRpZmlj YXRpb24gYXQgYW55IHBvaW50LiAgSGVuY2UsIEkgZG8gbm90IHNlZSB3aGF0IHZhbHVlIOKAnDUt dHVwbGUgY2Fubm90IGNoYW5nZeKAnSBhc3NlcnRpb24gaGFzIGFueW1vcmUuICBBcyBsb25nIGFz IGEgcGFja2V0IHNvbWVob3cgZ2V0IHRvIGFuIGVuZHBvaW50LCBvbmx5IGNvbm5lY3Rpb24gaWRz IGFyZSB1c2VkIHRvIGlkZW50aWZ5IHRoZSBmbG93cy4NCg0KWWVzLCBmbG93IGxhYmVsIHdvdWxk IHdvcmsgZm9yIGlwdjYuDQoNCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29v Z2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA5LCAyMDE3IDExOjM0IFBNDQpUbzog THViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpDYzogTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2ds ZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogNS10dXBs ZSB1bmlxdWVzcw0KDQpJbiBQcmFndWUsIHdlIGRlY2lkZWQgdGhhdCB0aGUgNS10dXBsZSBjb3Vs ZG4ndCBjaGFuZ2UgZHVyaW5nIHRoZSBoYW5kc2hha2UsIGJ1dCB3ZSBkaWRuJ3Qgc2F5IHRoYXQg YSA1LXR1cGxlIGluZGljYXRlZCBhIHNpbmdsZSBRVUlDIGNvbm5lY3Rpb24uDQoNCkZvciBJUHY2 LCBhIGZsb3cgbGFiZWwgY2FuIGJlIHVzZWQgdG8gc3ByZWFkIGxvYWQuICBGcm9tIG15IHBlcnNw ZWN0aXZlLCB0aGUgZ29hbCBoZXJlIGlzIHRvIGFsbG93IG11bHRpcGxlIFFVSUMgY29ubmVjdGlv bnMgdG8gc2hhcmUgYSA1LXR1cGxlLCBub3QgdG8gcmVjb21tZW5kIGl0IGZvciBhbGwgdXNlIGNh c2VzLiAgRm9yIGV4YW1wbGUsIGl0IG1heSBtYWtlIHNlbnNlIHRvIHByZWNsdWRlIGl0IGZvciBI VFRQIG92ZXIgUVVJQyBjbGllbnRzPw0KDQpPbiBXZWQsIEF1ZyA5LCAyMDE3IGF0IDExOjA5IFBN LCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWth bWFpLmNvbT4+IHdyb3RlOg0KSSBzZWUg4oCccG9ydCByZXVzZeKAnSBhcyBhbiBpbnN0YW5jZSBv ZiBhIGdlbmVyaWMg4oCcTkFUIHJlYmluZGluZ+KAnSB0aGF0IFFVSUMgaXMgYnVpbHQgZm9yLiAg V2XigJl2ZSBtYWludGFpbmVkIHByZXZpb3VzbHksIGhvd2V2ZXIsIHRoYXQgUVVJQyB0b2xlcmFu Y2UgdG8g4oCcY29ubmVjdGlvbiBtaWdyYXRpb24gLyBOQVQgcmViaW5kaW5n4oCdIGR1cmluZyBj b25uZWN0aW9uIGVzdGFibGlzaG1lbnQgaXMgb3V0IG9mIHNjb3BlLiAgVGhpcyBwcm9wb3NhbCB3 b3VsZCBzZWVtIHRvIHJldmlzaXQgdGhhdCBzY29wZS4NCg0KWW91IG1heSBpbmRlZWQgd2FudCB0 byBvcGVuIG11bHRpcGxlIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgZnJvbSBTIHRvIEIsIGhvcGlu ZyB0byBzcHJlYWQgeW91ciBjb25uZWN0aW9ucyBhbW9uZyBtdWx0aXBsZSBzZXJ2ZXJzIGJlaGlu ZCBCLiAgQnV0IGl0IG1heSBhY3R1YWxseSBiZSBjb3VudGVyLXByb2R1Y3RpdmUgdG8gdXNlIGEg c2luZ2xlIDUtdHVwbGUsIGlmIEIgaXMgYmVoaW5kIGFuIEVDTVAgcm91dGVyIGFjdGluZyBhcyBh IGxvYWQgYmFsYW5jZXIuICBNb3Jlb3ZlciwgdGhpcyB3aWxsIGFsc28gZGVmZWF0IFJTUy9SUFMv UkZTPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3Lmtlcm5lbC5vcmdfZG9jX0RvY3VtZW50YXRpb25fbmV0d29ya2luZ19zY2FsaW5nLnR4dCZk PUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JX MXR6Y0l4eWpVWmRuX201NUtQbWxvJm09S1VOSXQyYXI0Q2Nsa3B2YngzclNuLWFOUHI2QmxVY0ZL dXJqclNHbFdBcyZzPVhBeTlYNElLY01FUmVMVDdxdTdCb2NMV0JBOUlaOUJKdElPRHdqNXF0TTgm ZT0+IGxvYWQgYmFsYW5jaW5nIG1lY2hhbmlzbXMgd2l0aGluIHNlcnZlcnMuICBCZSBhd2FyZS4N Cg0KDQogICogICBJZ29yDQoNCg0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFtt YWlsdG86bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+XQ0KU2Vu dDogV2VkbmVzZGF5LCBBdWd1c3QgMDksIDIwMTcgMTozMyBQTQ0KVG86IEx1YmFzaGV2LCBJZ29y IDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj47IElhbiBT d2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+DQpD YzogUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb208bWFpbHRvOnJjaEBnb29nbGUuY29tPj47 IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSRTogNS10dXBsZSB1bmlxdWVzcw0KDQpUaGlzIG1heSBub3QgYWRkcmVzcyBhbGwgeW91 ciBjb25jZXJucywgYnV0IEkgdGhpbmsgcGVyaGFwcyB5b3UgYXJlIGxvb2tpbmcgYXQgdGhlIHBy b2JsZW0gZnJvbSB0aGUgd3JvbmcgZW5kIHdpdGggcmVzcGVjdCB0byBlcGhlbWVyYWwgcG9ydCBl eGhhdXN0aW9uOg0KDQpJbiBhIHR5cGljYWwgTkFUIHNjZW5hcmlvIHlvdSBoYXZlIG1hbnkgY2xp ZW50cyByZWFjaGluZyBmb3Igb25lIHNlcnZlciwgZWFjaCBjbGllbnQgbGlrZWx5IHBhc3Npbmcg YSBkaWZmZXJlbnQgTkFULg0KSGVuY2UgZWFjaCBjb25uZWN0aW9uIHdpbGwgYmUgYSB1bmlxdWUg NS10dXBsZSwgZXZlbiBpZiBRVUlDIGl0c2VsZiBpcyBub3QgbWFraW5nIGFueSBlZmZvcnQgdG8g YWNoaWV2ZSB0aGlzLg0KDQpOb3csIGlmIG9uZSBvZiB0aGVzZSBjbGllbnRzIGNyZWF0ZXMgdHdv IGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1lIHNlcnZlciBhbmQgY2hvb3NlcyB0byByZXVzZSB0aGUg b3V0Ym91bmQgVURQIHBvcnQgbnVtYmVyLCBzYXkgcmVhY2hpbmcgZm9yIHR3byBkaWZmZXJlbnQg aW1hZ2VzLCB0aGVuIHRoZSBOQVQgbWlnaHQgdGhpbmsgdGhhdCB0aGUgdHdvIGNvbm5lY3Rpb25z IGFyZSB0aGUgc2FtZSBjb25uZWN0aW9uLiBBbmQgaW4gc29tZSBzZW5zZSBpdCBpcyAtIG5vdCB0 aGUgc2FtZSBRVUlDIGNvbm5lY3Rpb24sIGJ1dCB0aGUgc2FtZSBvcGVyYXRpb25hbCBjb250ZXh0 LiBUaHVzLCB0aGUgdHdvIGNvbm5lY3Rpb25zIGhlbHBzIHJlZHVjZSBOQVQgb3ZlcmhlYWQgYW5k IGFsc28gY29vcGVyYXRlcyBpbiBrZWVwaW5nIHRoZSBOQVQgaG9sZSBvcGVuLg0KDQpPbiB0aGUg b3RoZXIgZW5kLCBhdCB0aGUgc2VydmVyLCB0aGVyZSBpcyBhIHNlcGFyYXRlIHByb2JsZW06IFRo ZSBzZXJ2ZXIgKFMpIGRvZXMgbm90IGhhdmUgdGhlIHJlcXVlc3RlZCBpbWFnZXMuIEl0IHJlYWNo ZXMgdG8gb25lIG9mIGEgZmV3IHBvc3NpYmxlIGJhY2tlbmQgc2VydmVycyAoQjEsIEIyKS4gU2lu Y2UgdGhlIHNlcnZlciBTIGlzIG5vdCBhdHRlbXB0aW5nIHRvIGJlIGNsZXZlciwgaXQgY3JlYXRl cyBhIG5ldyBRVUlDIGNvbm5lY3Rpb24gZnJvbSBTIHRvIEIxIG9yIEIyIGZvciBlYWNoIGluYm91 bmQgY2xpZW50IGNvbm5lY3Rpb24uIFRoZXJlIG1heSBvciBtYXkgbm90IGJlIGFueSBOQVQgaW52 b2x2ZWQgaGVyZSwgYnV0IHRoZSBzZXJ2ZXIgUyBpcyBvbmx5IGFzc2lnbmVkIGEgc2luZ2xlIElQ IGFkZHJlc3MgZm9yIG91dGJvdW5kIHJlcXVlc3RzIGFuZCBjYW5ub3QgY3JlYXRlIG1vcmUgY29u Y3VycmVudCBjb25uZWN0aW9ucyB0aGF0IHRoZSBudW1iZXIgb2YgZXBoZW1lcmFsIHBvcnRzICsg c2FmZXR5IG1hcmdpbiBwZXJtaXRzLCB0aGF0IGlzLCB1bmxlc3MgaXQgY2hvb3NlcyB0byByZXVz ZSBvdXRib3VuZCBwb3J0IG51bWJlcnMgd2hpY2ggc29sdmVzIHRoZSBwcm9ibGVtIG9mIHBvcnQg ZXhoYXVzdGlvbi4NCg0KSWYsIG9uIHRoZSBvdGhlciBoYW5kLCBhIFFVSUMgY2xpZW50IHdlcmUg Y28tbG9jYXRlZCB3aXRoIG90aGVyIHNlcnZpY2VzLCBpdCBtaWdodCBub3QgYmUgYWJsZSB0byBy ZWNlaXZlIHRoZSBjb3JyZWN0IHBhY2tldHMgd2hlbiB0aGVzZSBkaWZmZXJlbnQgc2VydmljZXMg Y29tcGV0ZSBmb3IgcG9ydCBudW1iZXJzLiBCdXQgaGVyZSBpdCBzdWZmaWNlIHRoYXQgdGhleSBl aXRoZXIgYWdyZWUgdG8gdXNlIGRpZmZlcmVudCBwb3J0cyAobGlrZSBQSU5HIHZzLiBETlMpLCBv ciBlYWNoIHNlcnZpY2UgYWxsb2NhdGUgYSBzaW5nbGUgZXBoZW1lcmFsIHBvcnQgZm9yIGl0cyBz ZXJ2aWNlIHZpYSBVRFAgc29ja2V0IGNyZWF0aW9uLiBJbiBlaXRoZXIgY2FzZSB0aGUgTkFUIHdv dWxkIHJvdXRlIHBhY2tldHMgdG8gdGhlIGNvcnJlY3Qgc2VydmljZSBieSByZWx5aW5nIG9uIDUt dHVwbGVzIGV2ZW4gaWYgUVVJQyBpdHNlbGYgZG9lcyBub3QuDQoNClNvLCBnb2luZyBmdXJ0aGVy IC0gd2hhdCBpZiBzZXZlcmFsIGhvc3RzIHVzZSB0aGUgc2FtZSBJUCBhZGRyZXNzLCBhcyBpcyB0 aGUgY2FzZSB3aXRoIGxvYWQgYmFsYW5jZXJzPyBBZ2FpbiwgNS10dXBsZXMgYXJlIHVzZWQgdG8g YmluZCBjb25uZWN0aW9ucyB0byBlYWNoIHVuaXF1ZSBob3N0LCBvbmx5IHdpdGggZmV3ZXIgVURQ IHBvcnRzIHRoZXJlIGlzIG11Y2ggbGVzcyBzdGF0ZSB0byBtYWludGFpbi4gVGhlIG1pZGRsZXdh cmUgb25seSBuZWVkIHRvIHJvdXRlIHRyYWZmaWMgdG8gdGhlIGNvcnJlY3QgZW5kcG9pbnQsIG5v dCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGxvZ2ljYWwgUVVJQyBjb25uZWN0aW9ucyB0aGF0IGhhcHBl biBiZXR3ZWVuIHRoZSBzYW1lIHR3byBlbnRpdGllcy4NCg0KS2luZCBSZWdhcmRzLA0KTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDkgQXVndXN0IDIwMTcgYXQgMTkuMDMuMzUsIEx1 YmFzaGV2LCBJZ29yIChpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWku Y29tPikgd3JvdGU6DQpDYW4gc29tZW9uZSBlbGFib3JhdGUgb24g4oCcUG9zc2libHkgaXQgc2hv dWxkIHNwZWNpZnkgdGhlIGNsaWVudCdzIGNvbm5lY3Rpb24gSUQgaW4gdGhlIHBhY2tldCBoZWFk ZXIgYW5kIHRoZW4gdGhlIG5ldyBzZXJ2ZXIgY29ubmVjdGlvbiBJRCBpbiB0aGUgdHJhbnNwb3J0 IHBhcmFtZXRlcnM/4oCdDQoNCklzIHRoYXQgb25seSBmb3Ig4oCcU2VydmVyIENsZWFydGV4dOKA nT8gV2hhdCBhYm91dCBjb25uZWN0aW9ucyB0aGF0IHN0YXJ0IG91dCB3aXRoIDBSVFQgcGFja2V0 cyDigJMgaG93IHdvdWxkIHRoZSBOQVQga25vdyB3aGljaCBmbG93IFNlcnZlcuKAmXMgMVJUVCBy ZXBseSBiZWxvbmdzIHRvIChpZiBTZXJ2ZXIgY2hhbmdlcyB0aGUgQ29uZW5jdGlvbklEKT8NCg0K TWF5YmUgcmVseWluZyBvbiBhIDUtdHVwbGUgaXMgbm90IHN1Y2ggYSBiYWQgaWRlYSBhZnRlciBh bGw/ICBBIE5BVCBkb2VzIG5vdCBuZWVkIGEgZGlmZmVyZW50IGVwaGVtZXJhbCBwb3J0IGZvciBl dmVyeSBvdXRnb2luZyBjb25uZWN0aW9uLiAgSXQgb25seSBuZWVkcyBhIGRpZmZlcmVudCBlcGhl bWVyYWwgcG9ydCBmb3Igb3V0Z29pbmcgY29ubmVjdGlvbnMgdG8gdGhlIHNhbWUgSVAuDQoNCkV2 ZW4gdGhlbiwgaWYgdGhlIE5BVCBpcyB3aWxsaW5nIHRvIGRvIHNvbWV0aGluZyBzcGVjaWFsIGZv ciBRVUlDLCBpdCBjYW4gYmUgYSBtdWNoIHNpbXBsZXIgdGhpbmcgdGhhbiBleGFtaW5lIFFVSUMg dHJhbnNwb3J0IHBhcmFtcy4gIFRoZSBOQVQgY2FuIHNpbXBseSByZXNlcnZlIGEgc2luZ2xlIGVw aGVtZXJhbCBwb3J0IGZvciBhbGwgMVJUVCBRVUlDIHBhY2tldHMuICBUaGF0IGlzLCBhbGwgb3V0 Z29pbmcgY2xlYXJ0ZXh0IGFuZCAwcnR0IFFVSUMgcGFja2V0cyB3b3VsZCByZXF1aXJlIGEgZGlz dGluY3QgNS10dXBsZSwgYnV0IG9uY2UgdGhlIGNvbm5lY3Rpb24gbWlncmF0ZXMgdG8gMVJUVCwg dGhlIGVwaGVtZXJhbCBwb3J0IGl0IHVzZWQgY2FuIGJlIGZyZWVkLCBhbmQgYWxsIDFSVFQgcGFj a2V0cyBzb3VyY2VkIGZyb20gdGhlIHJlc2VydmVkIFFJVUMgcG9ydC4gIFRoYXQgd291bGQgd29y aywgc2luY2UgYWxsIDFSVFQgcGFja2V0cyAoYm90aCBmcm9tIGNsaWVudCBhbmQgc2VydmVyKSB3 b3VsZCBiZSB1c2luZyBTZXJ2ZXItc2VsZWN0aW9uIENvbm5lY3Rpb25JRC4NCg0KDQogICogICBJ Z29yDQoNCg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPG1h aWx0bzppYW5zd2V0dEBnb29nbGUuY29tPl0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwOCwgMjAx NyA3OjAxIFBNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwu Y29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+Pg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xl LmNvbTxtYWlsdG86cmNoQGdvb2dsZS5jb20+Pg0KU3ViamVjdDogUmU6IDUtdHVwbGUgdW5pcXVl c3MNCg0KWW91J3JlIHJpZ2h0LCBlcGhlbWVyYWwgcG9ydCBleGhhdXN0aW9uIGlzIGEgdmVyeSBy ZWFsIHBvdGVudGlhbCBpc3N1ZSwgYW5kIEkgdGhpbmsgd2Ugc2hvdWxkIGVuc3VyZSBtdWx0aXBs ZSBRVUlDIGNvbm5lY3Rpb25zIGNhbiBydW4gb3ZlciB0aGUgc2FtZSA1LXR1cGxlIGFuZCB3ZSBk b24ndCBzcGVjaWZ5IFFVSUMgaW4gYSB3YXkgdGhhdCBwcmVjbHVkZXMgdGhhdC4NCg0KSSBiZWxp ZXZlIHlvdSdyZSBjb3JyZWN0IHRoYXQgdGhlIGN1cnJlbnQgU2VydmVyIENsZWFydGV4dCBtYWtl cyB0aGlzIGltcG9zc2libGUgaWYgdGhlIHNlcnZlciBjaGFuZ2VzIHRoZSBjb25uZWN0aW9uIElE LiAgUG9zc2libHkgaXQgc2hvdWxkIHNwZWNpZnkgdGhlIGNsaWVudCdzIGNvbm5lY3Rpb24gSUQg aW4gdGhlIHBhY2tldCBoZWFkZXIgYW5kIHRoZW4gdGhlIG5ldyBzZXJ2ZXIgY29ubmVjdGlvbiBJ RCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnM/ICBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dn L2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX3F1aWN3Z19iYXNlLTJEZHJhZnRzX2lzc3Vl c183MTQmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8y c2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0x TGtjTkpGTU9rZ1lkcDRfcTgmcz0tRHR2dGttRF9sWkpnRXRqdnVneDRPeHNrUkFVbXFweTVOZ0Nn TnphaEd3JmU9Pg0KDQpUaGUgdGV4dCBpcyBhbHNvIG1pc3Npbmcgc29tZSBkZXRhaWxzIG9uIGhv dyBjaGFuZ2luZyB0aGUgY29ubmVjdGlvbiBJRCBzaG91bGQgd29yayBmb3IgU3RhdGVsZXNzIFJl dHJ5LCBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvNzEz PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0 aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfNzEzJmQ9RHdNRmFRJmM9OTZaYlpa Y2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1 S1BtbG8mbT1tWGtpS0toX0ZrUk8tTUFObzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JnM9Y1Zf NUFVSlBvVzQ2U1FISlQxTml5X3p1UkN4MEU3eDI4OC1MNDYtemhkWSZlPT4sIHNvIEknZCBleHBl Y3Qgc29tZSBpbXByb3ZlbWVudHMgaW4gdGhlIG5lYXIgZnV0dXJlLg0KDQpPbiBTdW4sIEF1ZyA2 LCAyMDE3IGF0IDEwOjQzIEFNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBn bWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIaSBSeWFuLA0K DQpJIGNhbiBkaWcgZG93biBpbiBtb3JlIGRldGFpbCBpZiB0aGVyZSBpcyBpbnRlcmVzdC4gTWVh bndoaWxlLCBzb21lIGV4YW1wbGVzIHdoZXJlIHRoZSB0cmFuc3BvcnQgZG9jdW1lbnQgaXMgbm90 IGNvbXBhdGlibGUgd2l0aCBteSByZXF1ZXN0IGlzOg0KDQpUaGUgdmVyc2lvbiBuZWdvdGlhdGlv biBwYWNrZXQgaXMgb2sgLSBpdCByZWZsZWN0cyB0aGUgY2xpZW50IHZlcnNpb24NCmh0dHBzOi8v cXVpY3dnLmdpdGh1Yi5pby9iYXNlLWRyYWZ0cy9kcmFmdC1pZXRmLXF1aWMtdHJhbnNwb3J0Lmh0 bWwjcGFja2V0LXZlcnNpb248aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX19xdWljd2cuZ2l0aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRm LTJEcXVpYy0yRHRyYW5zcG9ydC5odG1sLTIzcGFja2V0LTJEdmVyc2lvbiZkPUR3TUZhUSZjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRu X201NUtQbWxvJm09bVhraUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFMa2NOSkZNT2tnWWRwNF9xOCZz PWduejhQSjRSUU1xNnctX1dGYTFSSFlNVGdwZ3RnSW1ha1IxcVp3bV91VGsmZT0+DQoNCkJ1dA0K aHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlvL2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFu c3BvcnQuaHRtbCNwYWNrZXQtc2VydmVyLWNsZWFydGV4dDxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRy YWZ0c19kcmFmdC0yRGlldGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNwYWNrZXQtMkRzZXJ2 ZXItMkRjbGVhcnRleHQmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5v MFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmcz1EaldkbzhZaHU4dDdoMXpxZDdCSXhrOV9UTFUz NkF4bWRaMERtaFpuNnZFJmU9Pg0KIlRoZSBjb25uZWN0aW9uIElEIGZpZWxkIGluIGEgU2VydmVy IENsZWFydGV4dCBwYWNrZXQgY29udGFpbnMgYSBjb25uZWN0aW9uIElEIHRoYXQgaXMgY2hvc2Vu IGJ5IHRoZSBzZXJ2ZXIgKHNlZSBTZWN0aW9uIDUuNjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zw b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRyYWZ0 c19kcmFmdC0yRGlldGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNjb25uZWN0aW9uLTJEaWQm ZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNy VzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpG TU9rZ1lkcDRfcTgmcz01U0g2dTdBYUhfYXJ4R1kzeUVlcXd5aGlvOGRUWDlTTVFXRmMyVElsaFkw JmU9PikuIg0KVGhpcyBicmVha3MgbGlua2FnZSB0byB0aGUgb3JpZ2luYWwgY2xpZW50IGNvbm5l Y3Rpb24gaWQgc28gdGhlIGNsaWVudCBjYW5ub3QgdGVsbCB3aGljaCBjb25uZWN0aW9uIHRoZSBy ZXNwb25zZSBiZWxvbmdzIHRvIHVubGVzcyBsb29raW5nIGludG8gNS10dXBsZSwgb3IgdGVzdGlu ZyBhbGwgcmVjZW50IGNvbm5lY3Rpb25zIGFnYWluc3QgQUVBRCBzaWduYXR1cmUgKGRlcGVuZGlu ZyBvbiB3aGVyZSB0aGlzIGxhbmRzKS4NCg0KSSBoYXZlIG5vdCBjb3ZlcmVkIGFsbCBvdGhlciBw b3NzaWJsZSBzZXJ2ZXIgcmVzcG9uc2VzLCBidXQgc2ltaWxhciBjb25jZXJucyBhcHBseS4NCkl0 IGlzIG5vdCBhIG1ham9yIGNoYW5nZSwgYnV0IGN1cnJlbnRseSBpdCBpcyBub3QgcG9zc2libGUu DQoNCkFub3RoZXIgaXNzdWUgaXMgaG9zdGlsZSByZXNwb25zZSB0byBpbml0aWFsIGNvbm5lY3Rp b24gc2V0dXAsIGFuZCBwbGFpbiBlcnJvcnMgLSBob3cgdG8geW91IHJlcGx5IHdpdGggYW4gZXJy b3IuIEhhdmluZyB0aGUgY29ubmVjdGlvbiBpZCBmcm9tIHRoZSBjbGllbnQgbWFrZXMgaXQgcmVh c29uYWJseSBlYXN5IHRvIGRlYWwgd2l0aCAtIHNpbWlsYXIgdG8gdmVyc2lvbiBuZWdvdGlhdGlv bi4gQWx0ZXJuYXRpdmVseSB5b3UgaGF2ZSB0byByZWx5IG9uIDUtdHVwbGVzLiBUaGlzIHJlcXVp cmVzIGNhcmVmdWwgYW5hbHlzaXMgb2YgYm90aCB0aGUgdHJhbnNwb3J0IGRvYyBhbmQgcG9zc2li bHkgVExTIGFuZCB0aGlucyBhcmUgbm90IGZ1bGx5IHNldHRsZWQuIFN0YXRlbGVzcyByZXNldCBp cyByZWxhdGVkIHRvIHRoaXMuIEkgd2lsbCBub3QgYXJndWUgc3Ryb25nbHkgb24gdGhpcyBiZWNh dXNlIHNpbmNlIEkgbGFzdCBsb29rZWQgYXQgaXQsIG5ldyBBRUFEIGVuY3J5cHRpb24gaXMgYmVp bmcgZGlzY3Vzc2VkLCBhbmQgSSBoYXZlIG5vdCBhbmFseXNlZCB0aGlzIGluIGRldGFpbC4NCg0K VGhlbiB0aGVyZSBpcyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gVGhpcyBhbHNvIHJlcXVpcmVzIGNh cmVmdWwgYW5hbHlzaXMuIEnigJltIG5vdCBzdXJlIGlmIGl0IGN1cnJlbnRseSBjb3ZlcnMgbXkg cmVxdWVzdC4NCg0KSeKAmW0gc3VyZSB0aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2l0 aCBpbXBsaWNpdCBhc3N1bXB0aW9ucyB0aGF0IEkgYW0gbm90IGFibGUgdG8gbGlzdCBvZmYgbWVt b3J5Lg0KDQpUaGUgKG15KSBiYXNpYyBydWxlIGlzIHRoZSBhbnkgY2hhbmdlIGluIGNvbm5lY3Rp b24gSUQgc2hvdWxkIHJlZmVyIHRvIHRoZSBwcmV2aW91cyBJRCB3aXRob3V0IHJlbHlpbmcgb24g ZXh0ZXJuYWwgc3RhdGUgc3VjaCBhcyA1LXR1cGxlcyBvciBUTFMgZXh0ZW5zaW9uIHN0YXRlICh3 aGljaCByZXF1aXJlcyBjcnlwdG8gc3RhdGUgdG8gYWNjZXNzIGFuZCBjb21wbGljYXRlcyB0aGlu Z3MpLiBBbHNvLCBkdWUgY29uY2VybnMgb2YgcHJpdmFjeSBjb25jZXJucyB0aGlzIGxpbmthZ2Ug YmV0d2VlbiBjb25uZWN0aW9uIElE4oCZcyBzaG91bGQgb25seSBiZSBwb3NzaWJsZSBieSBwZWVy cywgZXhjZXB0cyBmb3IgdGhlIGluaXRpYWwgY2xpZW50IHRvIHNlcnZlciBjb25uZWN0aW9uIHRy YW5zaXRpb24gdGhhdCBpcyBhbHNvIHZpc2libGUgdG8gYW55IHBhcnR5IG9uLXBhdGguDQoNCklu IGFkZGl0aW9uIHRvIHRoZSBhYm92ZSBlbmNvZGluZyBjb25jZXJucywgaXQgbWF5IGFsc28gYmUg aGVscGZ1bCB0byBleHBsaWNpdGx5IHN0YXRlIHRoYXQgdGhlIHNhbWUgVURQIHBvcnQgbWF5IGJl IHVzZWQgdG8gaW5pdGlhdGUgbXVsdGlwbGUgaW5kZXBlbmRlbnQgUVVJQyBjb25uZWN0aW9uIHRv IHRoZSBzYW1lIHNlcnZlciBVRFAgcG9ydCB3aGVuIGNvbm5lY3Rpb24gSUQgaGFzIGJlZW4gbmVn b3RpYXRlZCB0byBiZSBwcmVzZW50IC0gb3IgZnVydGhlciBkZXRhaWwgdGhpcyBwb3NzaWJpbGl0 eSBhcyBzb21ldGhpbmcgdGhhdCBjYW4gYmUgbmVnb3RpYXRlZC4NCg0KDQpTb21lIG90aGVyIHBv aW50cyBJIGZvcmdldCB0byBtZW50aW9uIHJlZ2FyZGluZyBiZW5lZml0cyBvZiBub24tdW5pcXVl IHR1cGxlczoNCg0KNSkgbm8gaW50ZXJmZXJlbmNlIHdpdGggT1MgaXMgbmVjZXNzYXJ5IGluIG9y ZGVyIHRvIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uIHRvIGFuIGV4aXN0aW5nIGVuZHBvaW50 IGJlY2F1c2Ugbm8gbmV3IGVwaGVtZXJhbCBwb3J0IGlzIG5lZWRlZC4gVGhpcyBtYXkgYWxzbyBz aW1wbGlmeSBjbGVhbiB1cCBhbmQgc3RhdGUgbWFuYWdlbWVudCwgZXNwZWNpYWxseSBzZXJ2ZXIg dG8gc2VydmVyLg0KDQo2KSBOZXRtYXAgYW5kIHNpbWlsYXIgaGlnaCBzcGVlZCBpbnRlcmZhY2Vz IHdvdWxkIGJlIHNpbXBsZXIgd2l0aG91dCBoYXZpbmcgdG8gZGVhbCB3aXRoIGVwaGVtZXJhbCBw b3J0IGFsbG9jYXRpb24sIGVzcGVjaWFsbHkgc2VydmVyIHRvIHNlcnZlciB3aGVyZSBib3RoIGVu ZCBwb2ludHMgY2FuIHJlZmVyZW5jZSBlYWNoIG90aGVyLCBhbmQgd2hlcmUgaXQgbWlnaHQgYmUg cmFuZG9tIHdoaWNoIGVuZHBvaW50IGFjdHVhbGx5IGluaXRpYXRlcyB0byB0aGUgY29ubmVjdGlv biAoYXMgaW4gQ29yZCAvIEthZGVtbGlhIHN0eWxlIG92ZXJsYXkgbmV0d29ya3MpDQoNCktpbmQg UmVnYXJkcywNCk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQoNCg== --_000_648f6f5202684eb3b7e9c516592f44a0usma1exdag1mb5msgcorpak_ 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 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAu bTUzMDI4NDgzNzI2Mjk5ODdhaXJtYWlsb24sIGxpLm01MzAyODQ4MzcyNjI5OTg3YWlybWFpbG9u LCBkaXYubTUzMDI4NDgzNzI2Mjk5ODdhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV81MzAy ODQ4MzcyNjI5OTg3YWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTA4NTIyNTM0ODsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MjA2MTUxNjgzNDt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjE1MzQx NDgyNzM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMTM4Nzc4NzQ0O30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SSBhbSBub3QgcGFydGljdWxhcmx5IGFnYWluc3QgNS10dXBsZS1zaGFyaW5nLCBpZiBp dCBjYW4gYmUgbWFkZSB0byB3b3JrLiZuYnNwOyBCdXQgYWxsb3dpbmcgc3VjaCBzY2VuYXJpb3Mg aXMgZWZmZWN0aXZlbHkgbWFraW5nIHRoZSA1LXR1cGxlcyB1bnVzYWJsZSBmb3IgY29ubmVjdGlv biBpZGVudGlmaWNhdGlvbg0KIGF0IGFueSBwb2ludC4mbmJzcDsgSGVuY2UsIEkgZG8gbm90IHNl ZSB3aGF0IHZhbHVlIOKAnDUtdHVwbGUgY2Fubm90IGNoYW5nZeKAnSBhc3NlcnRpb24gaGFzIGFu eW1vcmUuJm5ic3A7IEFzIGxvbmcgYXMgYSBwYWNrZXQgc29tZWhvdyBnZXQgdG8gYW4gZW5kcG9p bnQsIG9ubHkgY29ubmVjdGlvbiBpZHMgYXJlIHVzZWQgdG8gaWRlbnRpZnkgdGhlIGZsb3dzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5ZZXMsIGZsb3cgbGFiZWwgd291bGQgd29yayBmb3IgaXB2Ni48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g SWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEF1Z3VzdCAwOSwgMjAxNyAxMTozNCBQTTxicj4NCjxiPlRvOjwvYj4gTHVi YXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBSeWFu IEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDs7IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IDUtdHVwbGUgdW5pcXVlc3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gUHJhZ3VlLCB3ZSBk ZWNpZGVkIHRoYXQgdGhlIDUtdHVwbGUgY291bGRuJ3QgY2hhbmdlIGR1cmluZyB0aGUgaGFuZHNo YWtlLCBidXQgd2UgZGlkbid0IHNheSB0aGF0IGEgNS10dXBsZSBpbmRpY2F0ZWQgYSBzaW5nbGUg UVVJQyBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciBJUHY2LCBhIGZsb3cgbGFiZWwgY2FuIGJlIHVzZWQgdG8gc3ByZWFkIGxvYWQu Jm5ic3A7IEZyb20gbXkgcGVyc3BlY3RpdmUsIHRoZSBnb2FsIGhlcmUgaXMgdG8gYWxsb3cgbXVs dGlwbGUgUVVJQyBjb25uZWN0aW9ucyB0byBzaGFyZSBhIDUtdHVwbGUsIG5vdCB0byByZWNvbW1l bmQgaXQgZm9yIGFsbCB1c2UgY2FzZXMuJm5ic3A7IEZvciBleGFtcGxlLCBpdCBtYXkgbWFrZSBz ZW5zZSB0byBwcmVjbHVkZSBpdCBmb3IgSFRUUA0KIG92ZXIgUVVJQyBjbGllbnRzPzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgOSwgMjAx NyBhdCAxMTowOSBQTSwgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNo ZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc2VlIOKAnHBvcnQgcmV1c2XigJ0g YXMgYW4gaW5zdGFuY2Ugb2YgYSBnZW5lcmljIOKAnE5BVCByZWJpbmRpbmfigJ0gdGhhdCBRVUlD IGlzIGJ1aWx0IGZvci4mbmJzcDsgV2XigJl2ZSBtYWludGFpbmVkIHByZXZpb3VzbHksDQogaG93 ZXZlciwgdGhhdCBRVUlDIHRvbGVyYW5jZSB0byDigJxjb25uZWN0aW9uIG1pZ3JhdGlvbiAvIE5B VCByZWJpbmRpbmfigJ0gZHVyaW5nIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCBpcyBvdXQgb2Yg c2NvcGUuJm5ic3A7IFRoaXMgcHJvcG9zYWwgd291bGQgc2VlbSB0byByZXZpc2l0IHRoYXQgc2Nv cGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Zb3UgbWF5IGluZGVlZCB3YW50IHRvIG9wZW4gbXVsdGlw bGUgY29uY3VycmVudCBjb25uZWN0aW9ucyBmcm9tIFMgdG8gQiwgaG9waW5nIHRvIHNwcmVhZCB5 b3VyIGNvbm5lY3Rpb25zIGFtb25nDQogbXVsdGlwbGUgc2VydmVycyBiZWhpbmQgQi4mbmJzcDsg QnV0IGl0IG1heSBhY3R1YWxseSBiZSBjb3VudGVyLXByb2R1Y3RpdmUgdG8gdXNlIGEgc2luZ2xl IDUtdHVwbGUsIGlmIEIgaXMgYmVoaW5kIGFuIEVDTVAgcm91dGVyIGFjdGluZyBhcyBhIGxvYWQg YmFsYW5jZXIuJm5ic3A7IE1vcmVvdmVyLCB0aGlzIHdpbGwgYWxzbyBkZWZlYXQNCjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 Lmtlcm5lbC5vcmdfZG9jX0RvY3VtZW50YXRpb25fbmV0d29ya2luZ19zY2FsaW5nLnR4dCZhbXA7 ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBN XzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPUtVTkl0MmFyNENjbGtwdmJ4M3JT bi1hTlByNkJsVWNGS3VyanJTR2xXQXMmYW1wO3M9WEF5OVg0SUtjTUVSZUxUN3F1N0JvY0xXQkE5 SVo5Qkp0SU9Ed2o1cXRNOCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NClJTUy9SUFMvUkZTPC9h PiBsb2FkIGJhbGFuY2luZyBtZWNoYW5pc21zIHdpdGhpbiBzZXJ2ZXJzLiZuYnNwOyBCZSBhd2Fy ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgQXVndXN0IDA5LCAyMDE3IDE6MzMgUE08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2 LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OzsgSWFuIFN3ZXR0ICZsdDs8YSBocmVm PSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdv b2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJjaEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmNoQGdvb2dsZS5jb208 L2E+Jmd0OzsgSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogNS10dXBsZSB1bmlxdWVzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgbWF5IG5vdCBhZGRy ZXNzIGFsbCB5b3VyIGNvbmNlcm5zLCBidXQgSSB0aGluayBwZXJoYXBzIHlvdSBhcmUgbG9va2lu ZyBhdCB0aGUgcHJvYmxlbSBmcm9tIHRoZSB3cm9uZyBlbmQgd2l0aA0KIHJlc3BlY3QgdG8gZXBo ZW1lcmFsIHBvcnQgZXhoYXVzdGlvbjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkluIGEgdHlwaWNhbCBO QVQgc2NlbmFyaW8geW91IGhhdmUgbWFueSBjbGllbnRzIHJlYWNoaW5nIGZvciBvbmUgc2VydmVy LCBlYWNoIGNsaWVudCBsaWtlbHkgcGFzc2luZyBhIGRpZmZlcmVudA0KIE5BVC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2Jsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGVu Y2UgZWFjaCBjb25uZWN0aW9uIHdpbGwgYmUgYSB1bmlxdWUgNS10dXBsZSwgZXZlbiBpZiBRVUlD IGl0c2VsZiBpcyBub3QgbWFraW5nIGFueSBlZmZvcnQgdG8gYWNoaWV2ZSB0aGlzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3 MjYyOTk4N2Jsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Tm93LCBpZiBvbmUgb2YgdGhlc2UgY2xpZW50cyBjcmVhdGVzIHR3byBjb25u ZWN0aW9ucyB0byB0aGUgc2FtZSBzZXJ2ZXIgYW5kIGNob29zZXMgdG8gcmV1c2UgdGhlIG91dGJv dW5kIFVEUCBwb3J0DQogbnVtYmVyLCBzYXkgcmVhY2hpbmcgZm9yIHR3byBkaWZmZXJlbnQgaW1h Z2VzLCB0aGVuIHRoZSBOQVQgbWlnaHQgdGhpbmsgdGhhdCB0aGUgdHdvIGNvbm5lY3Rpb25zIGFy ZSB0aGUgc2FtZSBjb25uZWN0aW9uLiBBbmQgaW4gc29tZSBzZW5zZSBpdCBpcyAtIG5vdCB0aGUg c2FtZSBRVUlDIGNvbm5lY3Rpb24sIGJ1dCB0aGUgc2FtZSBvcGVyYXRpb25hbCBjb250ZXh0LiBU aHVzLCB0aGUgdHdvIGNvbm5lY3Rpb25zIGhlbHBzIHJlZHVjZSBOQVQgb3ZlcmhlYWQNCiBhbmQg YWxzbyBjb29wZXJhdGVzIGluIGtlZXBpbmcgdGhlIE5BVCBob2xlIG9wZW4uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdibG9vcF9jdXN0 b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5 OTg3Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5PbiB0aGUgb3RoZXIgZW5kLCBhdCB0aGUgc2VydmVyLCB0aGVyZSBpcyBhIHNlcGFy YXRlIHByb2JsZW06IFRoZSBzZXJ2ZXIgKFMpIGRvZXMgbm90IGhhdmUgdGhlIHJlcXVlc3RlZCBp bWFnZXMuDQogSXQgcmVhY2hlcyB0byBvbmUgb2YgYSBmZXcgcG9zc2libGUgYmFja2VuZCBzZXJ2 ZXJzIChCMSwgQjIpLiBTaW5jZSB0aGUgc2VydmVyIFMgaXMgbm90IGF0dGVtcHRpbmcgdG8gYmUg Y2xldmVyLCBpdCBjcmVhdGVzIGEgbmV3IFFVSUMgY29ubmVjdGlvbiBmcm9tIFMgdG8gQjEgb3Ig QjIgZm9yIGVhY2ggaW5ib3VuZCBjbGllbnQgY29ubmVjdGlvbi4gVGhlcmUgbWF5IG9yIG1heSBu b3QgYmUgYW55IE5BVCBpbnZvbHZlZCBoZXJlLCBidXQgdGhlDQogc2VydmVyIFMgaXMgb25seSBh c3NpZ25lZCBhIHNpbmdsZSBJUCBhZGRyZXNzIGZvciBvdXRib3VuZCByZXF1ZXN0cyBhbmQgY2Fu bm90IGNyZWF0ZSBtb3JlIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgdGhhdCB0aGUgbnVtYmVyIG9m IGVwaGVtZXJhbCBwb3J0cyAmIzQzOyBzYWZldHkgbWFyZ2luIHBlcm1pdHMsIHRoYXQgaXMsIHVu bGVzcyBpdCBjaG9vc2VzIHRvIHJldXNlIG91dGJvdW5kIHBvcnQgbnVtYmVycyB3aGljaCBzb2x2 ZXMgdGhlIHByb2JsZW0NCiBvZiBwb3J0IGV4aGF1c3Rpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdibG9vcF9jdXN0b21mb250Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Ymxvb3Bf Y3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J Ziwgb24gdGhlIG90aGVyIGhhbmQsIGEgUVVJQyBjbGllbnQgd2VyZSBjby1sb2NhdGVkIHdpdGgg b3RoZXIgc2VydmljZXMsIGl0IG1pZ2h0IG5vdCBiZSBhYmxlIHRvIHJlY2VpdmUgdGhlIGNvcnJl Y3QNCiBwYWNrZXRzIHdoZW4gdGhlc2UgZGlmZmVyZW50IHNlcnZpY2VzIGNvbXBldGUgZm9yIHBv cnQgbnVtYmVycy4gQnV0IGhlcmUgaXQgc3VmZmljZSB0aGF0IHRoZXkgZWl0aGVyIGFncmVlIHRv IHVzZSBkaWZmZXJlbnQgcG9ydHMgKGxpa2UgUElORyB2cy4gRE5TKSwgb3IgZWFjaCBzZXJ2aWNl IGFsbG9jYXRlIGEgc2luZ2xlIGVwaGVtZXJhbCBwb3J0IGZvciBpdHMgc2VydmljZSB2aWEgVURQ IHNvY2tldCBjcmVhdGlvbi4gSW4gZWl0aGVyIGNhc2UNCiB0aGUgTkFUIHdvdWxkIHJvdXRlIHBh Y2tldHMgdG8gdGhlIGNvcnJlY3Qgc2VydmljZSBieSByZWx5aW5nIG9uIDUtdHVwbGVzIGV2ZW4g aWYgUVVJQyBpdHNlbGYgZG9lcyBub3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Ymxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5TbywgZ29pbmcgZnVy dGhlciAtIHdoYXQgaWYgc2V2ZXJhbCBob3N0cyB1c2UgdGhlIHNhbWUgSVAgYWRkcmVzcywgYXMg aXMgdGhlIGNhc2Ugd2l0aCBsb2FkIGJhbGFuY2Vycz8gQWdhaW4sIDUtdHVwbGVzDQogYXJlIHVz ZWQgdG8gYmluZCBjb25uZWN0aW9ucyB0byBlYWNoIHVuaXF1ZSBob3N0LCBvbmx5IHdpdGggZmV3 ZXIgVURQIHBvcnRzIHRoZXJlIGlzIG11Y2ggbGVzcyBzdGF0ZSB0byBtYWludGFpbi4gVGhlIG1p ZGRsZXdhcmUgb25seSBuZWVkIHRvIHJvdXRlIHRyYWZmaWMgdG8gdGhlIGNvcnJlY3QgZW5kcG9p bnQsIG5vdCBkaXN0aW5ndWlzaCBiZXR3ZWVuIGxvZ2ljYWwgUVVJQyBjb25uZWN0aW9ucyB0aGF0 IGhhcHBlbiBiZXR3ZWVuIHRoZSBzYW1lDQogdHdvIGVudGl0aWVzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3 Ymxvb3Bfc2lnbl8xNTAyMjk5MTA0OTc0MTk0OTQ0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTUzMDI4NDgzNzI2Mjk5ODdhaXJtYWls b24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiA5IEF1Z3VzdCAyMDE3IGF0IDE5LjAzLjM1LCBMdWJh c2hldiwgSWdvciAoPC9zcGFuPjxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmlsdWJhc2hlQGFrYW1haS5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4pDQogd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Q2FuIHNvbWVvbmUgZWxhYm9yYXRlIG9uIOKAnFBvc3NpYmx5IGl0IHNob3VsZCBz cGVjaWZ5IHRoZSBjbGllbnQncyBjb25uZWN0aW9uIElEIGluIHRoZSBwYWNrZXQgaGVhZGVyIGFu ZCB0aGVuIHRoZQ0KIG5ldyBzZXJ2ZXIgY29ubmVjdGlvbiBJRCBpbiB0aGUgdHJhbnNwb3J0IHBh cmFtZXRlcnM/4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JcyB0aGF0IG9ubHkgZm9yIOKAnFNlcnZl ciBDbGVhcnRleHTigJ0/IFdoYXQgYWJvdXQgY29ubmVjdGlvbnMgdGhhdCBzdGFydCBvdXQgd2l0 aCAwUlRUIHBhY2tldHMg4oCTIGhvdyB3b3VsZCB0aGUgTkFUDQoga25vdyB3aGljaCBmbG93IFNl cnZlcuKAmXMgMVJUVCByZXBseSBiZWxvbmdzIHRvIChpZiBTZXJ2ZXIgY2hhbmdlcyB0aGUgQ29u ZW5jdGlvbklEKT88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1heWJlIHJlbHlpbmcgb24gYSA1LXR1cGxl IGlzIG5vdCBzdWNoIGEgYmFkIGlkZWEgYWZ0ZXIgYWxsPyZuYnNwOyBBIE5BVCBkb2VzIG5vdCBu ZWVkIGEgZGlmZmVyZW50IGVwaGVtZXJhbCBwb3J0IGZvcg0KIGV2ZXJ5IG91dGdvaW5nIGNvbm5l Y3Rpb24uJm5ic3A7IEl0IG9ubHkgbmVlZHMgYSBkaWZmZXJlbnQgZXBoZW1lcmFsIHBvcnQgZm9y IG91dGdvaW5nIGNvbm5lY3Rpb25zIHRvIHRoZSBzYW1lIElQLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RXZlbiB0aGVuLCBpZiB0aGUgTkFUIGlzIHdpbGxpbmcgdG8gZG8gc29tZXRoaW5nIHNwZWNpYWwg Zm9yIFFVSUMsIGl0IGNhbiBiZSBhIG11Y2ggc2ltcGxlciB0aGluZyB0aGFuIGV4YW1pbmUgUVVJ Qw0KIHRyYW5zcG9ydCBwYXJhbXMuJm5ic3A7IFRoZSBOQVQgY2FuIHNpbXBseSByZXNlcnZlIGEg c2luZ2xlIGVwaGVtZXJhbCBwb3J0IGZvciBhbGwgMVJUVCBRVUlDIHBhY2tldHMuJm5ic3A7IFRo YXQgaXMsIGFsbCBvdXRnb2luZyBjbGVhcnRleHQgYW5kIDBydHQgUVVJQyBwYWNrZXRzIHdvdWxk IHJlcXVpcmUgYSBkaXN0aW5jdCA1LXR1cGxlLCBidXQgb25jZSB0aGUgY29ubmVjdGlvbiBtaWdy YXRlcyB0byAxUlRULCB0aGUgZXBoZW1lcmFsIHBvcnQgaXQgdXNlZCBjYW4NCiBiZSBmcmVlZCwg YW5kIGFsbCAxUlRUIHBhY2tldHMgc291cmNlZCBmcm9tIHRoZSByZXNlcnZlZCBRSVVDIHBvcnQu Jm5ic3A7IFRoYXQgd291bGQgd29yaywgc2luY2UgYWxsIDFSVFQgcGFja2V0cyAoYm90aCBmcm9t IGNsaWVudCBhbmQgc2VydmVyKSB3b3VsZCBiZSB1c2luZyBTZXJ2ZXItc2VsZWN0aW9uIENvbm5l Y3Rpb25JRC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZ29yPC9zcGFuPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlhbnN3 ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmlhbnN3ZXR0 QGdvb2dsZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFR1ZXNkYXksIEF1Z3VzdCAwOCwgMjAxNyA3OjAxIFBNPGJyPg0KPGI+VG86PC9iPiBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZq QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21h aWwuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IElF VEYgUVVJQyBXRyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs7IFJ5YW4gSGFtaWx0b24gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWls dG86cmNoQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnJjaEBn b29nbGUuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IDUtdHVwbGUgdW5pcXVlc3M8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5Zb3UncmUgcmlnaHQsIGVwaGVtZXJhbCBwb3J0IGV4aGF1c3Rpb24gaXMg YSB2ZXJ5IHJlYWwgcG90ZW50aWFsIGlzc3VlLCBhbmQgSSB0aGluayB3ZSBzaG91bGQgZW5zdXJl IG11bHRpcGxlIFFVSUMNCiBjb25uZWN0aW9ucyBjYW4gcnVuIG92ZXIgdGhlIHNhbWUgNS10dXBs ZSBhbmQgd2UgZG9uJ3Qgc3BlY2lmeSBRVUlDIGluIGEgd2F5IHRoYXQgcHJlY2x1ZGVzIHRoYXQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBi ZWxpZXZlIHlvdSdyZSBjb3JyZWN0IHRoYXQgdGhlIGN1cnJlbnQgU2VydmVyIENsZWFydGV4dCBt YWtlcyB0aGlzIGltcG9zc2libGUgaWYgdGhlIHNlcnZlciBjaGFuZ2VzIHRoZSBjb25uZWN0aW9u DQogSUQuJm5ic3A7IFBvc3NpYmx5IGl0IHNob3VsZCBzcGVjaWZ5IHRoZSBjbGllbnQncyBjb25u ZWN0aW9uIElEIGluIHRoZSBwYWNrZXQgaGVhZGVyIGFuZCB0aGVuIHRoZSBuZXcgc2VydmVyIGNv bm5lY3Rpb24gSUQgaW4gdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzPyZuYnNwOw0KPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZ2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfNzE0JmFtcDtkPUR3TUZh USZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwz clcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209bVhraUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFM a2NOSkZNT2tnWWRwNF9xOCZhbXA7cz0tRHR2dGttRF9sWkpnRXRqdnVneDRPeHNrUkFVbXFweTVO Z0NnTnphaEd3JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTQ8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHRleHQgaXMg YWxzbyBtaXNzaW5nIHNvbWUgZGV0YWlscyBvbiBob3cgY2hhbmdpbmcgdGhlIGNvbm5lY3Rpb24g SUQgc2hvdWxkIHdvcmsgZm9yIFN0YXRlbGVzcyBSZXRyeSwgc2VlJm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f Z2l0aHViLmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfNzEzJmFtcDtkPUR3TUZhUSZh bXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209bVhraUtLaF9Ga1JPLU1BTm8wV3F5RW4yTTFMa2NO SkZNT2tnWWRwNF9xOCZhbXA7cz1jVl81QVVKUG9XNDZTUUhKVDFOaXlfenVSQ3gwRTd4Mjg4LUw0 Ni16aGRZJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL2lzc3Vlcy83MTM8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4sDQogc28gSSdkIGV4cGVjdCBzb21lIGltcHJvdmVtZW50cyBpbiB0aGUg bmVhciBmdXR1cmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+T24gU3VuLCBBdWcgNiwgMjAxNyBhdCAxMDo0MyBBTSwgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20i IHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21haWwuY29tPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2Mzky NDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9v cF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8t ODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SGkgUnlhbiw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dt YWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3 MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5 Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBj YW4gZGlnIGRvd24gaW4gbW9yZSBkZXRhaWwgaWYgdGhlcmUgaXMgaW50ZXJlc3QuIE1lYW53aGls ZSwgc29tZSBleGFtcGxlcyB3aGVyZSB0aGUgdHJhbnNwb3J0IGRvY3VtZW50IGlzIG5vdA0KIGNv bXBhdGlibGUgd2l0aCBteSByZXF1ZXN0IGlzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5 Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2 Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3Mjky NTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBwYWNr ZXQgaXMgb2sgLSBpdCByZWZsZWN0cyB0aGUgY2xpZW50IHZlcnNpb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5 NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0 MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19xdWlj d2cuZ2l0aHViLmlvX2Jhc2UtMkRkcmFmdHNfZHJhZnQtMkRpZXRmLTJEcXVpYy0yRHRyYW5zcG9y dC5odG1sLTIzcGFja2V0LTJEdmVyc2lvbiZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3 MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQ bWxvJmFtcDttPW1Ya2lLS2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1w O3M9Z256OFBKNFJRTXE2dy1fV0ZhMVJIWU1UZ3BndGdJbWFrUjFxWndtX3VUayZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlv L2Jhc2UtZHJhZnRzL2RyYWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuaHRtbCNwYWNrZXQtdmVyc2lv bjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3 MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcy OTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIy ODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAz NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+QnV0Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJt XzUzMDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1 NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fcXVpY3dnLmdpdGh1Yi5pb19iYXNlLTJEZHJhZnRz X2RyYWZ0LTJEaWV0Zi0yRHF1aWMtMkR0cmFuc3BvcnQuaHRtbC0yM3BhY2tldC0yRHNlcnZlci0y RGNsZWFydGV4dCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7 cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPW1Ya2lL S2hfRmtSTy1NQU5vMFdxeUVuMk0xTGtjTkpGTU9rZ1lkcDRfcTgmYW1wO3M9RGpXZG84WWh1OHQ3 aDF6cWQ3Qkl4azlfVExVMzZBeG1kWjBEbWhabjZ2RSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+aHR0cHM6Ly9xdWljd2cuZ2l0aHViLmlvL2Jhc2UtZHJhZnRzL2Ry YWZ0LWlldGYtcXVpYy10cmFuc3BvcnQuaHRtbCNwYWNrZXQtc2VydmVyLWNsZWFydGV4dDwvc3Bh bj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4 N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRt XzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMzMzMzMzIj5UaGUgY29ubmVjdGlvbiBJRCBmaWVsZA0KIGluIGEgU2VydmVyIENsZWFy dGV4dCBwYWNrZXQgY29udGFpbnMgYSBjb25uZWN0aW9uIElEIHRoYXQgaXMgY2hvc2VuIGJ5IHRo ZSBzZXJ2ZXIgKHNlZSZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3F1aWN3Zy5naXRodWIuaW9fYmFzZS0yRGRy YWZ0c19kcmFmdC0yRGlldGYtMkRxdWljLTJEdHJhbnNwb3J0Lmh0bWwtMjNjb25uZWN0aW9uLTJE aWQmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmYW1wO3I9RGpuM2JR NXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZhbXA7bT1tWGtpS0toX0ZrUk8t TUFObzBXcXlFbjJNMUxrY05KRk1Pa2dZZHA0X3E4JmFtcDtzPTVTSDZ1N0FhSF9hcnhHWTN5RWVx d3loaW84ZFRYOVNNUVdGYzJUSWxoWTAmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzJBNjQ5Njt0ZXh0LWRlY29yYXRpb246bm9uZSI+U2VjdGlvbg0KIDUu Njwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+KS4mcXVvdDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dt YWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3 MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgYnJlYWtzIGxpbmthZ2UgdG8gdGhlIG9yaWdpbmFs IGNsaWVudCBjb25uZWN0aW9uIGlkIHNvIHRoZSBjbGllbnQgY2Fubm90IHRlbGwgd2hpY2ggY29u bmVjdGlvbiB0aGUgcmVzcG9uc2UNCiBiZWxvbmdzIHRvIHVubGVzcyBsb29raW5nIGludG8gNS10 dXBsZSwgb3IgdGVzdGluZyBhbGwgcmVjZW50IGNvbm5lY3Rpb25zIGFnYWluc3QgQUVBRCBzaWdu YXR1cmUgKGRlcGVuZGluZyBvbiB3aGVyZSB0aGlzIGxhbmRzKS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIy Mjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIw MzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81 MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUz NDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIG5vdCBjb3ZlcmVk IGFsbCBvdGhlciBwb3NzaWJsZSBzZXJ2ZXIgcmVzcG9uc2VzLCBidXQgc2ltaWxhciBjb25jZXJu cyBhcHBseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0 ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4 MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkl0IGlzIG5vdCBhIG1ham9yIGNoYW5n ZSwgYnV0IGN1cnJlbnRseSBpdCBpcyBub3QgcG9zc2libGUuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4 NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2 Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMw Mjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQz MDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFub3RoZXIgaXNzdWUgaXMgaG9z dGlsZSByZXNwb25zZSB0byBpbml0aWFsIGNvbm5lY3Rpb24gc2V0dXAsIGFuZCBwbGFpbiBlcnJv cnMgLSBob3cgdG8geW91IHJlcGx5IHdpdGggYW4gZXJyb3IuDQogSGF2aW5nIHRoZSBjb25uZWN0 aW9uIGlkIGZyb20gdGhlIGNsaWVudCBtYWtlcyBpdCByZWFzb25hYmx5IGVhc3kgdG8gZGVhbCB3 aXRoIC0gc2ltaWxhciB0byB2ZXJzaW9uIG5lZ290aWF0aW9uLiBBbHRlcm5hdGl2ZWx5IHlvdSBo YXZlIHRvIHJlbHkgb24gNS10dXBsZXMuIFRoaXMgcmVxdWlyZXMgY2FyZWZ1bCBhbmFseXNpcyBv ZiBib3RoIHRoZSB0cmFuc3BvcnQgZG9jIGFuZCBwb3NzaWJseSBUTFMgYW5kIHRoaW5zIGFyZSBu b3QgZnVsbHkgc2V0dGxlZC4NCiBTdGF0ZWxlc3MgcmVzZXQgaXMgcmVsYXRlZCB0byB0aGlzLiBJ IHdpbGwgbm90IGFyZ3VlIHN0cm9uZ2x5IG9uIHRoaXMgYmVjYXVzZSBzaW5jZSBJIGxhc3QgbG9v a2VkIGF0IGl0LCBuZXcgQUVBRCBlbmNyeXB0aW9uIGlzIGJlaW5nIGRpc2N1c3NlZCwgYW5kIEkg aGF2ZSBub3QgYW5hbHlzZWQgdGhpcyBpbiBkZXRhaWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5 MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxv b3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0 ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4 MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZW4gdGhlcmUgaXMgY29ubmVjdGlv biBtaWdyYXRpb24uIFRoaXMgYWxzbyByZXF1aXJlcyBjYXJlZnVsIGFuYWx5c2lzLiBJ4oCZbSBu b3Qgc3VyZSBpZiBpdCBjdXJyZW50bHkgY292ZXJzIG15DQogcmVxdWVzdC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgw MDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3 MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBp ZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8t ODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKAmW0gc3VyZSB0 aGVyZSBhcmUgc2V2ZXJhbCBvdGhlciBwbGFjZXMgd2l0aCBpbXBsaWNpdCBhc3N1bXB0aW9ucyB0 aGF0IEkgYW0gbm90IGFibGUgdG8gbGlzdCBvZmYgbWVtb3J5Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIy ODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAz NmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUz MDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0 MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgKG15KSBiYXNpYyBydWxl IGlzIHRoZSBhbnkgY2hhbmdlIGluIGNvbm5lY3Rpb24gSUQgc2hvdWxkIHJlZmVyIHRvIHRoZSBw cmV2aW91cyBJRCB3aXRob3V0IHJlbHlpbmcgb24gZXh0ZXJuYWwNCiBzdGF0ZSBzdWNoIGFzIDUt dHVwbGVzIG9yIFRMUyBleHRlbnNpb24gc3RhdGUgKHdoaWNoIHJlcXVpcmVzIGNyeXB0byBzdGF0 ZSB0byBhY2Nlc3MgYW5kIGNvbXBsaWNhdGVzIHRoaW5ncykuIEFsc28sIGR1ZSBjb25jZXJucyBv ZiBwcml2YWN5IGNvbmNlcm5zIHRoaXMgbGlua2FnZSBiZXR3ZWVuIGNvbm5lY3Rpb24gSUTigJlz IHNob3VsZCBvbmx5IGJlIHBvc3NpYmxlIGJ5IHBlZXJzLCBleGNlcHRzIGZvciB0aGUgaW5pdGlh bCBjbGllbnQgdG8gc2VydmVyDQogY29ubmVjdGlvbiB0cmFuc2l0aW9uIHRoYXQgaXMgYWxzbyB2 aXNpYmxlIHRvIGFueSBwYXJ0eSBvbi1wYXRoLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAwNjk1MjIyODYzOTI0ODY5 Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcyMDQyMjAzNmJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUzMDI4NDgzNzI2 Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0MzA5ODE3Mjky NTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JbiBhZGRpdGlvbiB0byB0aGUgYWJvdmUgZW5j b2RpbmcgY29uY2VybnMsIGl0IG1heSBhbHNvIGJlIGhlbHBmdWwgdG8gZXhwbGljaXRseSBzdGF0 ZSB0aGF0IHRoZSBzYW1lIFVEUCBwb3J0IG1heQ0KIGJlIHVzZWQgdG8gaW5pdGlhdGUgbXVsdGlw bGUgaW5kZXBlbmRlbnQgUVVJQyBjb25uZWN0aW9uIHRvIHRoZSBzYW1lIHNlcnZlciBVRFAgcG9y dCB3aGVuIGNvbm5lY3Rpb24gSUQgaGFzIGJlZW4gbmVnb3RpYXRlZCB0byBiZSBwcmVzZW50IC0g b3IgZnVydGhlciBkZXRhaWwgdGhpcyBwb3NzaWJpbGl0eSBhcyBzb21ldGhpbmcgdGhhdCBjYW4g YmUgbmVnb3RpYXRlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1f NTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1 MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82 ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYy MzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1t Xy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9u dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Tb21lIG90aGVy IHBvaW50cyBJIGZvcmdldCB0byBtZW50aW9uIHJlZ2FyZGluZyBiZW5lZml0cyBvZiBub24tdW5p cXVlIHR1cGxlczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMw Mjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQz MDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwtbV82ODAw Njk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDkyNzYyMzcy MDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+NSkgbm8gaW50ZXJmZXJlbmNlIHdpdGggT1MgaXMgbmVjZXNzYXJ5IGluIG9y ZGVyIHRvIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uIHRvIGFuIGV4aXN0aW5nIGVuZHBvaW50 IGJlY2F1c2UNCiBubyBuZXcgZXBoZW1lcmFsIHBvcnQgaXMgbmVlZGVkLiBUaGlzIG1heSBhbHNv IHNpbXBsaWZ5IGNsZWFuIHVwIGFuZCBzdGF0ZSBtYW5hZ2VtZW50LCBlc3BlY2lhbGx5IHNlcnZl ciB0byBzZXJ2ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzUz MDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFpbC1tXy04NjU1NTM0 MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgw MDY5NTIyMjg2MzkyNDg2OWdtYWlsLW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3 MjA0MjIwMzZibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjYpIE5ldG1hcCBhbmQgc2ltaWxhciBoaWdoIHNwZWVkIGludGVyZmFjZXMg d291bGQgYmUgc2ltcGxlciB3aXRob3V0IGhhdmluZyB0byBkZWFsIHdpdGggZXBoZW1lcmFsIHBv cnQgYWxsb2NhdGlvbiwNCiBlc3BlY2lhbGx5IHNlcnZlciB0byBzZXJ2ZXIgd2hlcmUgYm90aCBl bmQgcG9pbnRzIGNhbiByZWZlcmVuY2UgZWFjaCBvdGhlciwgYW5kIHdoZXJlIGl0IG1pZ2h0IGJl IHJhbmRvbSB3aGljaCBlbmRwb2ludCBhY3R1YWxseSBpbml0aWF0ZXMgdG8gdGhlIGNvbm5lY3Rp b24gKGFzIGluIENvcmQgLyBLYWRlbWxpYSBzdHlsZSBvdmVybGF5IG5ldHdvcmtzKTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV81MzAyODQ4MzcyNjI5OTg3Z21haWwt bV82ODAwNjk1MjIyODYzOTI0ODY5Z21haWwtbV8tODY1NTUzNDMwOTgxNzI5MjU2NG1fMzcxNDky NzYyMzcyMDQyMjAzNmJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtXzUzMDI4NDgzNzI2Mjk5ODdnbWFpbC1tXzY4MDA2OTUyMjI4NjM5MjQ4NjlnbWFp bC1tXy04NjU1NTM0MzA5ODE3MjkyNTY0bV8zNzE0OTI3NjIzNzIwNDIyMDM2Ymxvb3Bfc2lnbl8x NTAyMDI5Mzg3MDU4ODU1OTM2Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7D uGUgSsO4cmdlbnNlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXYgaWQ9Im1fNTMwMjg0ODM3MjYyOTk4N2dtYWlsLW1fNjgwMDY5NTIyMjg2MzkyNDg2OWdtYWls LW1fLTg2NTU1MzQzMDk4MTcyOTI1NjRtXzM3MTQ5Mjc2MjM3MjA0MjIwMzZibG9vcF9jdXN0b21m b250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_648f6f5202684eb3b7e9c516592f44a0usma1exdag1mb5msgcorpak_-- From nobody Wed Aug 9 21:08:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85C1132547 for ; Wed, 9 Aug 2017 21:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdg3gXb_ZbZJ for ; Wed, 9 Aug 2017 21:08:12 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251F3132545 for ; Wed, 9 Aug 2017 21:08:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id s143so51706383ywg.1 for ; Wed, 09 Aug 2017 21:08:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=05YsHCeT83oFP+9vYPCPE4LCkjGZ5yGbj4S1UJ4VpPs=; b=acgyhS+kAMaeXNC+JQILlCiG69JXVsTx8FJM7PPTeXjP85jGNMyN/gA92ew9DMYTUe 2tyPCNkZPeAfrVeQxRhVIUVxnQHYcdmsunb6eqlRkEH9YEnkQ7gQ9coVzhV5BxGvQfWQ TzQsOgk8ZUI1Qs6Bm1Ww2o22H6xRtIQ4XGJMC+sQX+LWyJ9TmfY04fqk8uq3It4xE16W LfaF3sPFRrM2mBMTtKqasjb6IHyjLJcaJ38evuOQSBbiZmYsh10Bh2UeNfWxeHllG/YG 1DfQTMM9/317rDPWFeUO2PFsquH8E+95kWvJntB71q2RXNgfx4yCz2rJAOc4CYhQMHU0 Exkw== 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=05YsHCeT83oFP+9vYPCPE4LCkjGZ5yGbj4S1UJ4VpPs=; b=ie3AQRtTXQqGmQLiwiMxEceUgjc3Z+d0pOMLOmLXLNPzVuF7JJrzDDuRnoCBgw6MdF sDdLwDmPHdXFra1Zh09IQm90Yr8dh0UfMc7oZOXvVclNKbjP5Cmhtdg1AWC1lkKJBS60 eDL+Ku3QEwM9DcRUFxjKpjWkv8SV5G185+AuV0DeGkASr7AtOkR4JjQOlZ95me6DycZR 1hj3tPh+MscBa8yMDA0ZmZM/c/asnDbM69ZzUz24w87O0sZ1F5KZDbbNn2ktV2TBGlPm JFTFuWTWVNArMZiIFBzjfdcBTeRoCiGrv/qLqw//eLbMxeGkvbo5sNS0a0MISec/ea76 7KCg== X-Gm-Message-State: AHYfb5iJtnsxhda5cdwiZtufjB8WW0YoGxoPOWH/ht2IpIWniOY4k5md HQAtjqnoMdy7/KQn5F3a/rjlkvE9QAvR X-Received: by 10.129.55.19 with SMTP id e19mr1706075ywa.370.1502338091194; Wed, 09 Aug 2017 21:08:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Wed, 9 Aug 2017 21:07:50 -0700 (PDT) In-Reply-To: <648f6f5202684eb3b7e9c516592f44a0@usma1ex-dag1mb5.msg.corp.akamai.com> References: <648f6f5202684eb3b7e9c516592f44a0@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ian Swett Date: Thu, 10 Aug 2017 00:07:50 -0400 Message-ID: Subject: Re: 5-tuple uniquess To: "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Ryan Hamilton , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1143feb842d0bb05565e586e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 04:08:16 -0000 --001a1143feb842d0bb05565e586e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ensuring the 5-tuple cannot change during the handshake is useful to prevent a variety of off-path attacks, as well as a handshake simplification. On Thu, Aug 10, 2017 at 12:03 AM, Lubashev, Igor wrote: > I am not particularly against 5-tuple-sharing, if it can be made to work. > But allowing such scenarios is effectively making the 5-tuples unusable f= or > connection identification at any point. Hence, I do not see what value > =E2=80=9C5-tuple cannot change=E2=80=9D assertion has anymore. As long a= s a packet somehow > get to an endpoint, only connection ids are used to identify the flows. > > > > Yes, flow label would work for ipv6. > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, August 09, 2017 11:34 PM > *To:* Lubashev, Igor > *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Ryan Hamilt= on < > rch@google.com>; IETF QUIC WG > *Subject:* Re: 5-tuple uniquess > > > > In Prague, we decided that the 5-tuple couldn't change during the > handshake, but we didn't say that a 5-tuple indicated a single QUIC > connection. > > > > For IPv6, a flow label can be used to spread load. From my perspective, > the goal here is to allow multiple QUIC connections to share a 5-tuple, n= ot > to recommend it for all use cases. For example, it may make sense to > preclude it for HTTP over QUIC clients? > > > > On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor > wrote: > > I see =E2=80=9Cport reuse=E2=80=9D as an instance of a generic =E2=80=9CN= AT rebinding=E2=80=9D that QUIC > is built for. We=E2=80=99ve maintained previously, however, that QUIC to= lerance to > =E2=80=9Cconnection migration / NAT rebinding=E2=80=9D during connection = establishment is > out of scope. This proposal would seem to revisit that scope. > > > > You may indeed want to open multiple concurrent connections from S to B, > hoping to spread your connections among multiple servers behind B. But i= t > may actually be counter-productive to use a single 5-tuple, if B is behin= d > an ECMP router acting as a load balancer. Moreover, this will also defea= t > RSS/RPS/RFS > > load balancing mechanisms within servers. Be aware. > > > > - Igor > > > > > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Wednesday, August 09, 2017 1:33 PM > *To:* Lubashev, Igor ; Ian Swett > > *Cc:* Ryan Hamilton ; IETF QUIC WG > *Subject:* RE: 5-tuple uniquess > > > > This may not address all your concerns, but I think perhaps you are > looking at the problem from the wrong end with respect to ephemeral port > exhaustion: > > > > In a typical NAT scenario you have many clients reaching for one server, > each client likely passing a different NAT. > > Hence each connection will be a unique 5-tuple, even if QUIC itself is no= t > making any effort to achieve this. > > > > Now, if one of these clients creates two connections to the same server > and chooses to reuse the outbound UDP port number, say reaching for two > different images, then the NAT might think that the two connections are t= he > same connection. And in some sense it is - not the same QUIC connection, > but the same operational context. Thus, the two connections helps reduce > NAT overhead and also cooperates in keeping the NAT hole open. > > > > On the other end, at the server, there is a separate problem: The server > (S) does not have the requested images. It reaches to one of a few possib= le > backend servers (B1, B2). Since the server S is not attempting to be > clever, it creates a new QUIC connection from S to B1 or B2 for each > inbound client connection. There may or may not be any NAT involved here, > but the server S is only assigned a single IP address for outbound reques= ts > and cannot create more concurrent connections that the number of ephemera= l > ports + safety margin permits, that is, unless it chooses to reuse outbou= nd > port numbers which solves the problem of port exhaustion. > > > > If, on the other hand, a QUIC client were co-located with other services, > it might not be able to receive the correct packets when these different > services compete for port numbers. But here it suffice that they either > agree to use different ports (like PING vs. DNS), or each service allocat= e > a single ephemeral port for its service via UDP socket creation. In eithe= r > case the NAT would route packets to the correct service by relying on > 5-tuples even if QUIC itself does not. > > > > So, going further - what if several hosts use the same IP address, as is > the case with load balancers? Again, 5-tuples are used to bind connection= s > to each unique host, only with fewer UDP ports there is much less state t= o > maintain. The middleware only need to route traffic to the correct > endpoint, not distinguish between logical QUIC connections that happen > between the same two entities. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote: > > Can someone elaborate on =E2=80=9CPossibly it should specify the client's > connection ID in the packet header and then the new server connection ID = in > the transport parameters?=E2=80=9D > > > > Is that only for =E2=80=9CServer Cleartext=E2=80=9D? What about connectio= ns that start out > with 0RTT packets =E2=80=93 how would the NAT know which flow Server=E2= =80=99s 1RTT reply > belongs to (if Server changes the ConenctionID)? > > > > Maybe relying on a 5-tuple is not such a bad idea after all? A NAT does > not need a different ephemeral port for every outgoing connection. It on= ly > needs a different ephemeral port for outgoing connections to the same IP. > > > > Even then, if the NAT is willing to do something special for QUIC, it can > be a much simpler thing than examine QUIC transport params. The NAT can > simply reserve a single ephemeral port for all 1RTT QUIC packets. That i= s, > all outgoing cleartext and 0rtt QUIC packets would require a distinct > 5-tuple, but once the connection migrates to 1RTT, the ephemeral port it > used can be freed, and all 1RTT packets sourced from the reserved QIUC > port. That would work, since all 1RTT packets (both from client and > server) would be using Server-selection ConnectionID. > > > > - Igor > > > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, August 08, 2017 7:01 PM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* IETF QUIC WG ; Ryan Hamilton > *Subject:* Re: 5-tuple uniquess > > > > You're right, ephemeral port exhaustion is a very real potential issue, > and I think we should ensure multiple QUIC connections can run over the > same 5-tuple and we don't specify QUIC in a way that precludes that. > > > > I believe you're correct that the current Server Cleartext makes this > impossible if the server changes the connection ID. Possibly it should > specify the client's connection ID in the packet header and then the new > server connection ID in the transport parameters? > https://github.com/quicwg/base-drafts/issues/714 > > > > > The text is also missing some details on how changing the connection ID > should work for Stateless Retry, see https://github.com/quicwg/ > base-drafts/issues/713 > , > so I'd expect some improvements in the near future. > > > > On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > > > Hi Ryan, > > > > I can dig down in more detail if there is interest. Meanwhile, some > examples where the transport document is not compatible with my request i= s: > > > > The version negotiation packet is ok - it reflects the client version > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-version > > > > > But > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-server-cleartext > > > "The connection ID field in a Server Cleartext packet contains a > connection ID that is chosen by the server (see Section 5.6 > > )." > > This breaks linkage to the original client connection id so the client > cannot tell which connection the response belongs to unless looking into > 5-tuple, or testing all recent connections against AEAD signature > (depending on where this lands). > > > > I have not covered all other possible server responses, but similar > concerns apply. > > It is not a major change, but currently it is not possible. > > > > Another issue is hostile response to initial connection setup, and plain > errors - how to you reply with an error. Having the connection id from th= e > client makes it reasonably easy to deal with - similar to version > negotiation. Alternatively you have to rely on 5-tuples. This requires > careful analysis of both the transport doc and possibly TLS and thins are > not fully settled. Stateless reset is related to this. I will not argue > strongly on this because since I last looked at it, new AEAD encryption i= s > being discussed, and I have not analysed this in detail. > > > > Then there is connection migration. This also requires careful analysis. > I=E2=80=99m not sure if it currently covers my request. > > > > I=E2=80=99m sure there are several other places with implicit assumptions= that I > am not able to list off memory. > > > > The (my) basic rule is the any change in connection ID should refer to th= e > previous ID without relying on external state such as 5-tuples or TLS > extension state (which requires crypto state to access and complicates > things). Also, due concerns of privacy concerns this linkage between > connection ID=E2=80=99s should only be possible by peers, excepts for the= initial > client to server connection transition that is also visible to any party > on-path. > > > > In addition to the above encoding concerns, it may also be helpful to > explicitly state that the same UDP port may be used to initiate multiple > independent QUIC connection to the same server UDP port when connection I= D > has been negotiated to be present - or further detail this possibility as > something that can be negotiated. > > > > > > Some other points I forget to mention regarding benefits of non-unique > tuples: > > > > 5) no interference with OS is necessary in order to establish a new > connection to an existing endpoint because no new ephemeral port is neede= d. > This may also simplify clean up and state management, especially server t= o > server. > > > > 6) Netmap and similar high speed interfaces would be simpler without > having to deal with ephemeral port allocation, especially server to serve= r > where both end points can reference each other, and where it might be > random which endpoint actually initiates to the connection (as in Cord / > Kademlia style overlay networks) > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > > > > --001a1143feb842d0bb05565e586e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ensuring the 5-tuple cannot change during the handshake is= useful to prevent a variety of off-path attacks, as well as a handshake si= mplification.

On Thu, Aug 10, 2017 at 12:03 AM, Lubashev, Igor <ilubashe@akamai.com<= /a>> wrote:

I am not particularly against 5-tuple-sharing, if i= t can be made to work.=C2=A0 But allowing such scenarios is effectively mak= ing the 5-tuples unusable for connection identification at any point.=C2=A0 Hence, I do not see what value =E2=80=9C5-tuple cannot= change=E2=80=9D assertion has anymore.=C2=A0 As long as a packet somehow g= et to an endpoint, only connection ids are used to identify the flows.

=C2=A0

Yes, flow label would work for ipv6.<= /span>

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Wednesday, August 09, 2017 11:34 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Ryan Hamilton <= ;rch@google.com>= ; IETF QUIC WG <quic@= ietf.org>
Subject: Re: 5-tuple uniquess

=C2=A0

In Prague, we decided that the 5-tuple couldn't = change during the handshake, but we didn't say that a 5-tuple indicated= a single QUIC connection.

=C2=A0

For IPv6, a flow label can be used to spread load.= =C2=A0 From my perspective, the goal here is to allow multiple QUIC connect= ions to share a 5-tuple, not to recommend it for all use cases.=C2=A0 For e= xample, it may make sense to preclude it for HTTP over QUIC clients?

=C2=A0

On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor <= ilubashe@akamai.co= m> wrote:

I see =E2=80=9Cport reuse=E2=80=9D as an instance o= f a generic =E2=80=9CNAT rebinding=E2=80=9D that QUIC is built for.=C2=A0 W= e=E2=80=99ve maintained previously, however, that QUIC tolerance to =E2=80=9Cconnection migration / NAT rebind= ing=E2=80=9D during connection establishment is out of scope.=C2=A0 This pr= oposal would seem to revisit that scope.

=C2=A0

You may indeed want to open multiple concurrent con= nections from S to B, hoping to spread your connections among multiple servers behind B.=C2=A0 But it may actually be counter-productive= to use a single 5-tuple, if B is behind an ECMP router acting as a load ba= lancer.=C2=A0 Moreover, this will also defeat RSS/RPS/RFS load balancing mechanisms within servers.=C2=A0 Be aware.

=C2=A0

  • Igor

=C2=A0

=C2=A0

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgen= sen [mailto:mikkelf= j@gmail.com]
Sent: Wednesday, August 09, 2017 1:33 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswett@google.com>
Cc: Ryan Hamilton <rch@google.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: 5-tuple uniquess

=C2=A0

This may not address all your concerns, but I thi= nk perhaps you are looking at the problem from the wrong end with respect to ephemeral port exhaustion:

=C2=A0

In a typical NAT scenario you have many clients r= eaching for one server, each client likely passing a different NAT.

Hence each connection will be a unique 5-tuple, e= ven if QUIC itself is not making any effort to achieve this.<= u>

=C2=A0

Now, if one of these clients creates two connecti= ons to the same server and chooses to reuse the outbound UDP port number, say reaching for two different images, then the NAT might think th= at the two connections are the same connection. And in some sense it is - n= ot the same QUIC connection, but the same operational context. Thus, the tw= o connections helps reduce NAT overhead and also cooperates in keeping the NAT hole open.

=C2=A0

On the other end, at the server, there is a separ= ate problem: The server (S) does not have the requested images. It reaches to one of a few possible backend servers (B1, B2). Since the se= rver S is not attempting to be clever, it creates a new QUIC connection fro= m S to B1 or B2 for each inbound client connection. There may or may not be= any NAT involved here, but the server S is only assigned a single IP address for outbound requests and ca= nnot create more concurrent connections that the number of ephemeral ports = + safety margin permits, that is, unless it chooses to reuse outbound port = numbers which solves the problem of port exhaustion.

=C2=A0

If, on the other hand, a QUIC client were co-loca= ted with other services, it might not be able to receive the correct packets when these different services compete for port numbers. But here i= t suffice that they either agree to use different ports (like PING vs. DNS)= , or each service allocate a single ephemeral port for its service via UDP = socket creation. In either case the NAT would route packets to the correct service by relying on 5-tuples = even if QUIC itself does not.

=C2=A0

So, going further - what if several hosts use the= same IP address, as is the case with load balancers? Again, 5-tuples are used to bind connections to each unique host, only with fewer UDP port= s there is much less state to maintain. The middleware only need to route t= raffic to the correct endpoint, not distinguish between logical QUIC connec= tions that happen between the same two entities.

=C2=A0

Kind Regards,

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

=C2=A0

On 9 Aug= ust 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote:

Can someone elaborate on =E2=80=9CPossibly it shoul= d specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters?=E2=80=9D

=C2=A0

Is that only for =E2=80=9CServer Cleartext=E2=80=9D= ? What about connections that start out with 0RTT packets =E2=80=93 how wou= ld the NAT know which flow Server=E2=80=99s 1RTT reply belongs to (if Server changes = the ConenctionID)?

=C2=A0

Maybe relying on a 5-tuple is not such a bad idea a= fter all?=C2=A0 A NAT does not need a different ephemeral port for every outgoing connection.=C2=A0 It only needs a different ephemeral port = for outgoing connections to the same IP.

=C2=A0

Even then, if the NAT is willing to do something sp= ecial for QUIC, it can be a much simpler thing than examine QUIC transport params.=C2=A0 The NAT can simply reserve a single ephemeral port= for all 1RTT QUIC packets.=C2=A0 That is, all outgoing cleartext and 0rtt = QUIC packets would require a distinct 5-tuple, but once the connection migr= ates to 1RTT, the ephemeral port it used can be freed, and all 1RTT packets sourced from the reserved QIUC port.=C2=A0 = That would work, since all 1RTT packets (both from client and server) would= be using Server-selection ConnectionID.

=C2=A0

  • Igor

=C2=A0

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, August 08, 2017 7:01 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>; Ryan Hamilton <rch@google.com&g= t;
Subject: Re: 5-tuple uniquess

=C2=A0

You're right, ephemeral port exhaustion is a = very real potential issue, and I think we should ensure multiple QUIC connections can run over the same 5-tuple and we don't specify QUIC in= a way that precludes that.

=C2=A0

I believe you're correct that the current Ser= ver Cleartext makes this impossible if the server changes the connection ID.=C2=A0 Possibly it should specify the client's connection ID in the= packet header and then the new server connection ID in the transport param= eters?=C2=A0 https://github.com/quicwg/= base-drafts/issues/714

=C2=A0

The text is also missing some details on how chan= ging the connection ID should work for Stateless Retry, see=C2=A0https://github.com/quicwg/base-= drafts/issues/713, so I'd expect some improvements in the near future.

=C2=A0

On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3= =B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:

=C2=A0

Hi Ryan,

=C2=A0

I can dig down in more detail if there is interes= t. Meanwhile, some examples where the transport document is not compatible with my request is:

=C2=A0

The version negotiation packet is ok - it reflect= s the client version

https://quicwg.github.io/base-drafts= /draft-ietf-quic-transport.html#packet-version

=C2=A0

But=C2=A0

https://quicwg.github.io/base-= drafts/draft-ietf-quic-transport.html#packet-server-cleartex= t

"The connection ID f= ield in a Server Cleartext packet contains a connection ID that is chosen by th= e server (see=C2=A0Sect= ion 5.6)."

This breaks linkage to the original client connec= tion id so the client cannot tell which connection the response belongs to unless looking into 5-tuple, or testing all recent connections = against AEAD signature (depending on where this lands).

=C2=A0

I have not covered all other possible server resp= onses, but similar concerns apply.

It is not a major change, but currently it is not= possible.

=C2=A0

Another issue is hostile response to initial conn= ection setup, and plain errors - how to you reply with an error. Having the connection id from the client makes it reasonably easy to deal = with - similar to version negotiation. Alternatively you have to rely on 5-= tuples. This requires careful analysis of both the transport doc and possib= ly TLS and thins are not fully settled. Stateless reset is related to this. I will not argue strongly on this beca= use since I last looked at it, new AEAD encryption is being discussed, and = I have not analysed this in detail.

=C2=A0

Then there is connection migration. This also req= uires careful analysis. I=E2=80=99m not sure if it currently covers my request.

=C2=A0

I=E2=80=99m sure there are several other places w= ith implicit assumptions that I am not able to list off memory.

=C2=A0

The (my) basic rule is the any change in connecti= on ID should refer to the previous ID without relying on external state such as 5-tuples or TLS extension state (which requires crypto state= to access and complicates things). Also, due concerns of privacy concerns = this linkage between connection ID=E2=80=99s should only be possible by pee= rs, excepts for the initial client to server connection transition that is also visible to any party on-path.=

=C2=A0

In addition to the above encoding concerns, it ma= y also be helpful to explicitly state that the same UDP port may be used to initiate multiple independent QUIC connection to the same serve= r UDP port when connection ID has been negotiated to be present - or furthe= r detail this possibility as something that can be negotiated.

=C2=A0

=C2=A0

Some other points I forget to mention regarding b= enefits of non-unique tuples:

=C2=A0

5) no interference with OS is necessary in order = to establish a new connection to an existing endpoint because no new ephemeral port is needed. This may also simplify clean up and state= management, especially server to server.

=C2=A0

6) Netmap and similar high speed interfaces would= be simpler without having to deal with ephemeral port allocation, especially server to server where both end points can reference each other= , and where it might be random which endpoint actually initiates to the con= nection (as in Cord / Kademlia style overlay networks)=

=C2=A0

Kind Regards,

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

=C2=A0

=C2=A0

=C2=A0


--001a1143feb842d0bb05565e586e-- From nobody Wed Aug 9 22:33:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C51D4132542 for ; Wed, 9 Aug 2017 22:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 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, HTTPS_HTTP_MISMATCH=1.989, 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 k-F10nmXK5dj for ; Wed, 9 Aug 2017 22:33:33 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01EF132556 for ; Wed, 9 Aug 2017 22:33:32 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id r199so33138758vke.4 for ; Wed, 09 Aug 2017 22:33:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nx7qv+9StzNGF9G/Fq3OutpUPS/w167t5SaA6F34ryE=; b=raUsSzBL6AqhG7NCwyIJDKkzk9XpUfhGQ02VFifLqgPHHYtMk1VqBuvIr6oiR9vVgu VR27MpiVBKplniqQfiEs7+AuXgdBgJVnR5kDgJeJVsoZeQgCKWzkkUqVe8xAZlPXgl3l 2OIqg48VAfmQP0YrRTX3eOzxS/iRv4lpbMzVKUoTRdDNrfn2ZsdaCM35oBtLTDmznJVM +vWxiXuDj0Us6i5LFZmRpIK6Fscxr1aSLewifE7wzSgTO7mluFzS6zFSTVEJ6di76EZ3 +EwgB4G/VhisnJU0kWhcimQCj4JFODNnAUUL47vjxQPs+LXmV9HcO6Xlw2eeqwi/AtC9 7JIQ== 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=nx7qv+9StzNGF9G/Fq3OutpUPS/w167t5SaA6F34ryE=; b=aNFZjWzwE39JgUHKehh+AphaeoZcW5HTxocPnULNwWmHibR0JwQbWCOGq46u6Rma/6 WPWCs/KuHNSnGNE6jkk/meQ8s8xRmAbBv3nwZ3+Q2r2yuI0+JGZCgm+w7wMjwXiWq6FH x2H7bQngriucTfJVEegspnWxuUWDPipv7Yxu2FFn/xdKUfFJP25i+LSNJmTtYC188Vb4 u2dgZmYUb5Knu2oRLCw1lc1p95Xf1r+2XWGcUkb/nET6www8vqnk9eJfxF8mV/+5OrCZ 6iS2duZPPrsPDg/K7Tp/BE5qHn+SjzYR+7q7fheSkY4q0Z9tRRsjk3JC0RndBIDlFsRA jXsg== X-Gm-Message-State: AHYfb5gRkNt0OR277fyrtLn5nlKbxYoUxPYYgNCTA5QNvnOUhBMDDY43 jMqfDt+2Ug+b6qXZEdImPJfO1Wg8zA== X-Received: by 10.31.244.66 with SMTP id s63mr6102968vkh.124.1502343210870; Wed, 09 Aug 2017 22:33:30 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 9 Aug 2017 22:33:29 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <648f6f5202684eb3b7e9c516592f44a0@usma1ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 9 Aug 2017 22:33:29 -0700 Message-ID: Subject: Re: 5-tuple uniquess To: "Lubashev, Igor" , Ian Swett Cc: IETF QUIC WG , Ryan Hamilton Content-Type: multipart/alternative; boundary="94eb2c14b5066a2e0d05565f89c0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 05:33:39 -0000 --94eb2c14b5066a2e0d05565f89c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On HTTP clients being excluding from port-reuse - it might make sense for browser clients but not necessarily for reverse proxy clients, and thus most programming language standard libraries. On RFS (flow steering) - CloudFlare made a contribution to Netmap so they could steer some traffic to Netmap while the remaining traffic landed on the Linux TCP stack. https://blog.cloudflare.com/single-rx-queue-kernel-bypass-with-netmap/ In this case you could pro-actively use this to partially take over the network traffic - or - an application could internally manage multiple core loads by actively managing port allocations. So yes, there is a concern if not used with care, but it also opens up opportunities. On backend routing - it may be a good idea to allocate port numbers from a limited sized pool avoiding both extremes. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 10 August 2017 at 06.08.11, Ian Swett (ianswett@google.com) wrote: Ensuring the 5-tuple cannot change during the handshake is useful to prevent a variety of off-path attacks, as well as a handshake simplification. On Thu, Aug 10, 2017 at 12:03 AM, Lubashev, Igor wrote: > I am not particularly against 5-tuple-sharing, if it can be made to work. > But allowing such scenarios is effectively making the 5-tuples unusable f= or > connection identification at any point. Hence, I do not see what value > =E2=80=9C5-tuple cannot change=E2=80=9D assertion has anymore. As long a= s a packet somehow > get to an endpoint, only connection ids are used to identify the flows. > > > > Yes, flow label would work for ipv6. > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Wednesday, August 09, 2017 11:34 PM > *To:* Lubashev, Igor > *Cc:* Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Ryan Hamilt= on < > rch@google.com>; IETF QUIC WG > *Subject:* Re: 5-tuple uniquess > > > > In Prague, we decided that the 5-tuple couldn't change during the > handshake, but we didn't say that a 5-tuple indicated a single QUIC > connection. > > > > For IPv6, a flow label can be used to spread load. From my perspective, > the goal here is to allow multiple QUIC connections to share a 5-tuple, n= ot > to recommend it for all use cases. For example, it may make sense to > preclude it for HTTP over QUIC clients? > > > > On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor > wrote: > > I see =E2=80=9Cport reuse=E2=80=9D as an instance of a generic =E2=80=9CN= AT rebinding=E2=80=9D that QUIC > is built for. We=E2=80=99ve maintained previously, however, that QUIC to= lerance to > =E2=80=9Cconnection migration / NAT rebinding=E2=80=9D during connection = establishment is > out of scope. This proposal would seem to revisit that scope. > > > > You may indeed want to open multiple concurrent connections from S to B, > hoping to spread your connections among multiple servers behind B. But i= t > may actually be counter-productive to use a single 5-tuple, if B is behin= d > an ECMP router acting as a load balancer. Moreover, this will also defea= t > RSS/RPS/RFS > > load balancing mechanisms within servers. Be aware. > > > > - Igor > > > > > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Wednesday, August 09, 2017 1:33 PM > *To:* Lubashev, Igor ; Ian Swett > > *Cc:* Ryan Hamilton ; IETF QUIC WG > *Subject:* RE: 5-tuple uniquess > > > > This may not address all your concerns, but I think perhaps you are > looking at the problem from the wrong end with respect to ephemeral port > exhaustion: > > > > In a typical NAT scenario you have many clients reaching for one server, > each client likely passing a different NAT. > > Hence each connection will be a unique 5-tuple, even if QUIC itself is no= t > making any effort to achieve this. > > > > Now, if one of these clients creates two connections to the same server > and chooses to reuse the outbound UDP port number, say reaching for two > different images, then the NAT might think that the two connections are t= he > same connection. And in some sense it is - not the same QUIC connection, > but the same operational context. Thus, the two connections helps reduce > NAT overhead and also cooperates in keeping the NAT hole open. > > > > On the other end, at the server, there is a separate problem: The server > (S) does not have the requested images. It reaches to one of a few possib= le > backend servers (B1, B2). Since the server S is not attempting to be > clever, it creates a new QUIC connection from S to B1 or B2 for each > inbound client connection. There may or may not be any NAT involved here, > but the server S is only assigned a single IP address for outbound reques= ts > and cannot create more concurrent connections that the number of ephemera= l > ports + safety margin permits, that is, unless it chooses to reuse outbou= nd > port numbers which solves the problem of port exhaustion. > > > > If, on the other hand, a QUIC client were co-located with other services, > it might not be able to receive the correct packets when these different > services compete for port numbers. But here it suffice that they either > agree to use different ports (like PING vs. DNS), or each service allocat= e > a single ephemeral port for its service via UDP socket creation. In eithe= r > case the NAT would route packets to the correct service by relying on > 5-tuples even if QUIC itself does not. > > > > So, going further - what if several hosts use the same IP address, as is > the case with load balancers? Again, 5-tuples are used to bind connection= s > to each unique host, only with fewer UDP ports there is much less state t= o > maintain. The middleware only need to route traffic to the correct > endpoint, not distinguish between logical QUIC connections that happen > between the same two entities. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote: > > Can someone elaborate on =E2=80=9CPossibly it should specify the client's > connection ID in the packet header and then the new server connection ID = in > the transport parameters?=E2=80=9D > > > > Is that only for =E2=80=9CServer Cleartext=E2=80=9D? What about connectio= ns that start out > with 0RTT packets =E2=80=93 how would the NAT know which flow Server=E2= =80=99s 1RTT reply > belongs to (if Server changes the ConenctionID)? > > > > Maybe relying on a 5-tuple is not such a bad idea after all? A NAT does > not need a different ephemeral port for every outgoing connection. It on= ly > needs a different ephemeral port for outgoing connections to the same IP. > > > > Even then, if the NAT is willing to do something special for QUIC, it can > be a much simpler thing than examine QUIC transport params. The NAT can > simply reserve a single ephemeral port for all 1RTT QUIC packets. That i= s, > all outgoing cleartext and 0rtt QUIC packets would require a distinct > 5-tuple, but once the connection migrates to 1RTT, the ephemeral port it > used can be freed, and all 1RTT packets sourced from the reserved QIUC > port. That would work, since all 1RTT packets (both from client and > server) would be using Server-selection ConnectionID. > > > > - Igor > > > > > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* Tuesday, August 08, 2017 7:01 PM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* IETF QUIC WG ; Ryan Hamilton > *Subject:* Re: 5-tuple uniquess > > > > You're right, ephemeral port exhaustion is a very real potential issue, > and I think we should ensure multiple QUIC connections can run over the > same 5-tuple and we don't specify QUIC in a way that precludes that. > > > > I believe you're correct that the current Server Cleartext makes this > impossible if the server changes the connection ID. Possibly it should > specify the client's connection ID in the packet header and then the new > server connection ID in the transport parameters? > https://github.com/quicwg/base-drafts/issues/714 > > > > > The text is also missing some details on how changing the connection ID > should work for Stateless Retry, see https://github.com/quicwg/ > base-drafts/issues/713 > , > so I'd expect some improvements in the near future. > > > > On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > > > Hi Ryan, > > > > I can dig down in more detail if there is interest. Meanwhile, some > examples where the transport document is not compatible with my request i= s: > > > > The version negotiation packet is ok - it reflects the client version > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-version > > > > > But > > https://quicwg.github.io/base-drafts/draft-ietf-quic- > transport.html#packet-server-cleartext > > > "The connection ID field in a Server Cleartext packet contains a > connection ID that is chosen by the server (see Section 5.6 > > )." > > This breaks linkage to the original client connection id so the client > cannot tell which connection the response belongs to unless looking into > 5-tuple, or testing all recent connections against AEAD signature > (depending on where this lands). > > > > I have not covered all other possible server responses, but similar > concerns apply. > > It is not a major change, but currently it is not possible. > > > > Another issue is hostile response to initial connection setup, and plain > errors - how to you reply with an error. Having the connection id from th= e > client makes it reasonably easy to deal with - similar to version > negotiation. Alternatively you have to rely on 5-tuples. This requires > careful analysis of both the transport doc and possibly TLS and thins are > not fully settled. Stateless reset is related to this. I will not argue > strongly on this because since I last looked at it, new AEAD encryption i= s > being discussed, and I have not analysed this in detail. > > > > Then there is connection migration. This also requires careful analysis. > I=E2=80=99m not sure if it currently covers my request. > > > > I=E2=80=99m sure there are several other places with implicit assumptions= that I > am not able to list off memory. > > > > The (my) basic rule is the any change in connection ID should refer to th= e > previous ID without relying on external state such as 5-tuples or TLS > extension state (which requires crypto state to access and complicates > things). Also, due concerns of privacy concerns this linkage between > connection ID=E2=80=99s should only be possible by peers, excepts for the= initial > client to server connection transition that is also visible to any party > on-path. > > > > In addition to the above encoding concerns, it may also be helpful to > explicitly state that the same UDP port may be used to initiate multiple > independent QUIC connection to the same server UDP port when connection I= D > has been negotiated to be present - or further detail this possibility as > something that can be negotiated. > > > > > > Some other points I forget to mention regarding benefits of non-unique > tuples: > > > > 5) no interference with OS is necessary in order to establish a new > connection to an existing endpoint because no new ephemeral port is neede= d. > This may also simplify clean up and state management, especially server t= o > server. > > > > 6) Netmap and similar high speed interfaces would be simpler without > having to deal with ephemeral port allocation, especially server to serve= r > where both end points can reference each other, and where it might be > random which endpoint actually initiates to the connection (as in Cord / > Kademlia style overlay networks) > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > > > > --94eb2c14b5066a2e0d05565f89c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On HTTP clients being excluding from port-reuse -= it might make sense for browser clients but not necessarily for reverse pr= oxy clients, and thus most programming language standard libraries.

On RFS (flow steering) - Clo= udFlare made a contribution to Netmap so they could steer some traffic to N= etmap while the remaining traffic landed on the Linux TCP stack. ht= tps://blog.cloudflare.com/single-rx-queue-kernel-bypass-with-netmap/
In this case yo= u could pro-actively use this to partially take over the network traffic - = or - an application could internally manage multiple core loads by actively= managing port allocations. So yes, there is a concern if not used with car= e, but it also opens up opportunities.

On backend routing - it may be a good idea to allocate po= rt numbers from a limited sized pool avoiding both extremes.

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

On 10 August 2017 at 06.08.11, Ia= n Swett (ianswett@google.com) wr= ote:

Ensuring the 5-tuple cannot change during the handshake is useful to prevent a variety of off-path attacks, as well as a handshake simplification.

On Thu, Aug 10, 2017 at 12:03 AM, Lubashev, Igor <ilubashe@akamai.com> wrote:

I am not particularly against 5-tuple-sharing, if it can be made to work.=C2=A0 But allowing such scenarios is effectively making the 5-tuples unusable for connection identification at any point.=C2=A0 Hence, I do not see what value =E2=80=9C5-tuple cannot change=E2=80=9D asse= rtion has anymore.=C2=A0 As long as a packet somehow get to an endpoint, only connection ids are used to identify the flows.

=C2=A0

Yes, flow label would work for ipv6.

=C2=A0

=C2=A0

From: Ian Swett [mailto:ians= wett@google.com]
Sent: Wednesday, August 09, 2017 11:34 PM
To: Lubashev, Igor <ilubashe@akamai.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Ryan Hamilton <= ;rch@google.com>= ; IETF QUIC WG <quic@ie= tf.org>
Subject: Re: 5-tuple uniquess

=C2=A0

In Prague, we decided that the 5-tuple couldn't change during the handshake, but we didn't say that a 5-tuple indicated a single QUIC connection.

=C2=A0

For IPv6, a flow label can be used to spread load.=C2=A0 From my perspective, the goal here is to allow multiple QUIC connections to share a 5-tuple, not to recommend it for all use cases.=C2=A0 For example, it may make sense to preclude it for HTTP over QUIC clients?

=C2=A0

On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor <ilubashe@= akamai.com> wrote:

I see =E2=80=9Cport reuse=E2=80=9D as an instance of a generic =E2=80=9CNAT rebin= ding=E2=80=9D that QUIC is built for.=C2=A0 We=E2=80=99ve maintained previously, however, that QUIC tolerance to =E2=80=9Cconnection migration / NAT rebinding=E2=80=9D during connection establishment is out of scope.=C2=A0 This proposal would seem to revisit that scope.

=C2=A0

You may indeed want to open multiple concurrent connections from S to B, hoping to spread your connections among multiple servers behind B.=C2=A0 But it may actually be counter-productive to use a single 5-tuple, if B is behind an ECMP router acting as a load balancer.=C2=A0 Moreover, this will also defeat RSS/RPS/RFS load balancing mechanisms within servers.=C2=A0 Be aware.

=C2=A0

  • Igor

=C2=A0

=C2=A0

=C2=A0

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
Sent: Wednesday, August 09, 2017 1:33 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Ian Swett <ianswett@google.com>
Cc: Ryan Hamilton <rch@google.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: 5-tuple uniquess

=C2=A0

This may not address all your concerns, but I think perhaps you are looking at the problem from the wrong end with respect to ephemeral port exhaustion:

=C2=A0

In a typical NAT scenario you have many clients reaching for one server, each client likely passing a different NAT.

Hence each connection will be a unique 5-tuple, even if QUIC itself is not making any effort to achieve this.

=C2=A0

Now, if one of these clients creates two connections to the same server and chooses to reuse the outbound UDP port number, say reaching for two different images, then the NAT might think that the two connections are the same connection. And in some sense it is - not the same QUIC connection, but the same operational context. Thus, the two connections helps reduce NAT overhead and also cooperates in keeping the NAT hole open.

=C2=A0

On the other end, at the server, there is a separate problem: The server (S) does not have the requested images. It reaches to one of a few possible backend servers (B1, B2). Since the server S is not attempting to be clever, it creates a new QUIC connection from S to B1 or B2 for each inbound client connection. There may or may not be any NAT involved here, but the server S is only assigned a single IP address for outbound requests and cannot create more concurrent connections that the number of ephemeral ports + safety margin permits, that is, unless it chooses to reuse outbound port numbers which solves the problem of port exhaustion.

=C2=A0

If, on the other hand, a QUIC client were co-located with other services, it might not be able to receive the correct packets when these different services compete for port numbers. But here it suffice that they either agree to use different ports (like PING vs. DNS), or each service allocate a single ephemeral port for its service via UDP socket creation. In either case the NAT would route packets to the correct service by relying on 5-tuples even if QUIC itself does not.

=C2=A0

So, going further - what if several hosts use the same IP address, as is the case with load balancers? Again, 5-tuples are used to bind connections to each unique host, only with fewer UDP ports there is much less state to maintain. The middleware only need to route traffic to the correct endpoint, not distinguish between logical QUIC connections that happen between the same two entities.

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e J=C3=B8rgensen

=C2=A0

On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com) wrote:

Can someone elaborate on =E2=80=9CPossibly it should specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters?=E2=80=9D

=C2=A0

Is that only for =E2=80=9CServer Cleartext=E2=80=9D? What about connections th= at start out with 0RTT packets =E2=80=93 how would the NAT know which flow Server=E2= =80=99s 1RTT reply belongs to (if Server changes the ConenctionID)?

=C2=A0

Maybe relying on a 5-tuple is not such a bad idea after all?=C2=A0 A NAT does not need a different ephemeral port for every outgoing connection.=C2=A0 It only needs a different ephemeral port for outgoing connections to the same IP.

=C2=A0

Even then, if the NAT is willing to do something special for QUIC, it can be a much simpler thing than examine QUIC transport params.=C2=A0 The NAT can simply reserve a single ephemeral port for all 1RTT QUIC packets.=C2=A0 That is, all outgoing cleartext and 0rtt QUIC packets would require a distinct 5-tuple, but once the connection migrates to 1RTT, the ephemeral port it used can be freed, and all 1RTT packets sourced from the reserved QIUC port.=C2=A0 That would work, since all 1RTT packets (both from client and server) would be using Server-selection ConnectionID.

=C2=A0

  • Igor

=C2=A0

=C2=A0

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: Tuesday, August 08, 2017 7:01 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> Cc: IETF QUIC WG <quic@ietf.org>; Ryan Hamilton <rch@google.com>
Subject: Re: 5-tuple uniquess

=C2=A0

You're right, ephemeral port exhaustion is a very real potential issue, and I think we should ensure multiple QUIC connections can run over the same 5-tuple and we don't specify QUIC in a way that precludes that.

=C2=A0

I believe you're correct that the current Server Cleartext makes this impossible if the server changes the connection ID.=C2=A0 Possibly it should specify the client's connection ID in the packet header and then the new server connection ID in the transport parameters?=C2=A0 https://= github.com/quicwg/base-drafts/issues/714

=C2=A0

The text is also missing some details on how changing the connection ID should work for Stateless Retry, see=C2=A0https://github.com/quicwg/base-drafts/issues/713, so I'd expect some improvements in the near future.

=C2=A0

On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikke= lfj@gmail.com> wrote:

=C2=A0

Hi Ryan,

=C2=A0

I can dig down in more detail if there is interest. Meanwhile, some examples where the transport document is not compatible with my request is:

=C2=A0

The version negotiation packet is ok - it reflects the client version

https://quicwg.github.io/base-drafts= /draft-ietf-quic-transport.html#packet-version

=C2=A0

But=C2=A0

https://quicwg.github.io/base-= drafts/draft-ietf-quic-transport.html#packet-server-cleartex= t

"The connection ID field in a Server Cleartext packet contains a connection ID that is chosen by the server (see=C2=A0Section 5.6)."

This breaks linkage to the original client connection id so the client cannot tell which connection the response belongs to unless looking into 5-tuple, or testing all recent connections against AEAD signature (depending on where this lands).

=C2=A0

I have not covered all other possible server responses, but similar concerns apply.

It is not a major change, but currently it is not possible.

=C2=A0

Another issue is hostile response to initial connection setup, and plain errors - how to you reply with an error. Having the connection id from the client makes it reasonably easy to deal with - similar to version negotiation. Alternatively you have to rely on 5-tuples. This requires careful analysis of both the transport doc and possibly TLS and thins are not fully settled. Stateless reset is related to this. I will not argue strongly on this because since I last looked at it, new AEAD encryption is being discussed, and I have not analysed this in detail.

=C2=A0

Then there is connection migration. This also requires careful analysis. I=E2=80=99m not sure if it currently covers my request.

=C2=A0

I=E2=80=99m sure there are several other places with implicit assumptions that I am not able to list off memory.

=C2=A0

The (my) basic rule is the any change in connection ID should refer to the previous ID without relying on external state such as 5-tuples or TLS extension state (which requires crypto state to access and complicates things). Also, due concerns of privacy concerns this linkage between connection ID=E2=80=99s should only be possible by peers, excepts for the initial client to server connection transition that is also visible to any party on-path.

=C2=A0

In addition to the above encoding concerns, it may also be helpful to explicitly state that the same UDP port may be used to initiate multiple independent QUIC connection to the same server UDP port when connection ID has been negotiated to be present - or further detail this possibility as something that can be negotiated.

=C2=A0

=C2=A0

Some other points I forget to mention regarding benefits of non-unique tuples:

=C2=A0

5) no interference with OS is necessary in order to establish a new connection to an existing endpoint because no new ephemeral port is needed. This may also simplify clean up and state management, especially server to server.

=C2=A0

6) Netmap and similar high speed interfaces would be simpler without having to deal with ephemeral port allocation, especially server to server where both end points can reference each other, and where it might be random which endpoint actually initiates to the connection (as in Cord / Kademlia style overlay networks)

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e J=C3=B8rgensen

=C2=A0

=C2=A0

=C2=A0


--94eb2c14b5066a2e0d05565f89c0-- From nobody Thu Aug 10 05:24:52 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E7D132125 for ; Thu, 10 Aug 2017 05:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBvbQy_H8aOD for ; Thu, 10 Aug 2017 05:24:48 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 6587D1293E1 for ; Thu, 10 Aug 2017 05:24:48 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id t37so2906282qtg.5 for ; Thu, 10 Aug 2017 05:24:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=O1HDe1zxFABcWLkLjGw8cpgMi+2oXFYePgGwqlOS+CY=; b=OdhNDSMZ5W157Cn8CkEbpDj3/hy/odFufpz0tkNGr993ANwNHapQNEGcYNy01LeNRc UV3hMvxZndKJ9t0K5rftKXY807IxoA78od6ox65GQCoAXgZ1o2mYk9E6MaHLvA/lL7EJ 5oLeS41IhuqouAKYhuiV8TFWgjXgrcEc7sWQbGzgeEQRcsIP5yWkpjYj8vnmT1cuEV+N B5o14nJZUzAU6yX4pUGsiBqY7m94pBYx1WErpqGw4kaOPI1BJUrgi6tj5rKDEGs7dmM5 m1l7fVeNE3uBvQpNh58MKT6Jk8NrqnMrVMQdkpDPs3eEGoGLxN6pdQpDVCUnntbhvVu6 eTwQ== 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=O1HDe1zxFABcWLkLjGw8cpgMi+2oXFYePgGwqlOS+CY=; b=GYsa7/9udhs5e9PPMO5prcGYKHlcoCUfKGI8xkNaDJaUPQyvlb++Xa32Z58b7kpyh3 GwOxvKJufqiCwT84p5bSxTubDmVlvwQOq3YUn2fttROCbkQ+7zdRARLY3ORzgDhcgPAS CF8tX6iOIZoJf/Ot3RWRBfM4J3HRzW5rgNxCocwCoZ+FQrw1Wv0DfeXNoJJe473mYaHX r1Q2jzDGjPGgaEsX/dc6t5nc+mr+QI+2+zF01tFF6Fr8O6vBUcql2+r1cNcOImajG2u0 8TAAuD5rPVh+qCCfCRlNN2K3jPjvhYCTcUYtM16cZkMoGVCHJTJi6TuUAqoBrYUXum2O gTxw== X-Gm-Message-State: AHYfb5jql3SscbzDo85MF3WTAwQB+jutpHGw4OooC4KwhSL8O2tujU42 6usntah1nuNqhxWxghtRPOX5s0XLnjii X-Received: by 10.200.48.66 with SMTP id g2mr15621841qte.119.1502367887349; Thu, 10 Aug 2017 05:24:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.52.150 with HTTP; Thu, 10 Aug 2017 05:24:26 -0700 (PDT) From: Tatsuhiro Tsujikawa Date: Thu, 10 Aug 2017 21:24:26 +0900 Message-ID: Subject: stream 0 and flow control To: IETF Content-Type: multipart/alternative; boundary="001a11456a9c3f5ee005566548c3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 12:24:50 -0000 --001a11456a9c3f5ee005566548c3 Content-Type: text/plain; charset="UTF-8" Hi, The current spec says that stream 0 is exempt from connection level flow control. It is still subject to stream-level flow control. But the spec does not allow MAX_STREAM_DATA frame in Client cleartext and Server cleartext. So if credit is exhausted, peer cannot send more STREAM frame, and opposite peer also cannot extend the offset, which creates deadlock. Is it just an editorial issue that MAX_STREAM_DATA is missing in Client cleartext or Server cleartext? Or are there any other way to handle this situation? Should we assume that initial max offset is sufficient for TLS handshake? Best regards, Tatsuhiro Tsujikawa --001a11456a9c3f5ee005566548c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

The= current spec says that stream 0 is exempt from connection level flow contr= ol.=C2=A0 It is still subject to stream-level flow control.=C2=A0 But the s= pec does not allow MAX_STREAM_DATA frame in Client cleartext and Server cle= artext.=C2=A0 So if credit is exhausted, peer cannot send more STREAM frame= , and opposite peer also cannot extend the offset, which creates deadlock.<= br>
Is it just an editorial issue that MAX_STREAM_D= ATA is missing in Client cleartext or Server cleartext?=C2=A0 Or are there = any other way to handle this situation?=C2=A0 Should we assume that initial= max offset is sufficient for TLS handshake?

Best regards,
Tatsuhiro Tsujikawa



--001a11456a9c3f5ee005566548c3-- From nobody Thu Aug 10 09:46:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBE51323A5 for ; Thu, 10 Aug 2017 09:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuHCkpSRxrtZ for ; Thu, 10 Aug 2017 09:46:28 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF509132190 for ; Thu, 10 Aug 2017 09:46:27 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id u207so8144441ywc.3 for ; Thu, 10 Aug 2017 09:46:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PHArx+ZSzUS4EiU50oBLVROrBRxKgFtKHpe+Em6COgQ=; b=VGdNPJqYZH5ZPyhW6Qs04D+WsXFb9d71KYpagN/fXr+dhXLEEe8V2ACAAFdg0XDoYv oJ3KuSYWF+NphpAHmALr6idYwjZNIukE5V2ufp5px+WcFBRHee3myGYat/g3rWmoaCQ6 1sRF8lJKiugGidSHMqejNBJ24iXXL+SROirmkrK+ILT/nazg6ZdFKzuvwaqn6y1tdiSL 9nXfdpCjFAVUSdt7vKl3H6oSzjeK2IjOjKIJZkKlEllJchRSgB2x3k980Tr4ySxyqhUh 7dHT1yTLDGnPwZup2/1cdXl0B+r5YauYbAb7yEKKcKoQlBx8J2nhZOdHqSs0q3VOHFYe dY9A== 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=PHArx+ZSzUS4EiU50oBLVROrBRxKgFtKHpe+Em6COgQ=; b=QFTwlZ32WA5A0llr2HQ0tidfBTvA5rpFvgvqPOJ18AfxTNjNkiYx5kTijvbVIFoCUj +B77RbieIRV6C1DYKQTpZFHweRsOQDYfqYWfdRmFiwENeEpB39kluT6j9MFYc2c2bBvQ JmivDPIDnvtxFHuViFsJhOy6YpYrfQNn6hemvHs+GMhbbtN/kvNJIxymtSoXtIGcaxv9 zCi8E2ypJUAVlQPRNFOUhpfgOuza9llmcKQTXOnpNsRKCCZG0dAQKbiRRqkKeXweg3vX RaVEeQEGf9sAqRrOVQfWIs+DU1hYGt1luNfIXYgwG8EtS/JDPSnrWkrjqmCdHauj1rE0 X+ZQ== X-Gm-Message-State: AHYfb5h6XKoZKJX+ITn9TzYOIYTlXbj4vlGuAGsOyTsO6pv7ePurXfOR yiE2A2HAXVEH1Et2fIypNjixd36SWDUm X-Received: by 10.13.233.198 with SMTP id s189mr9717516ywe.32.1502383586780; Thu, 10 Aug 2017 09:46:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Thu, 10 Aug 2017 09:46:06 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Thu, 10 Aug 2017 12:46:06 -0400 Message-ID: Subject: Re: stream 0 and flow control To: Tatsuhiro Tsujikawa Cc: IETF Content-Type: multipart/alternative; boundary="94eb2c07cbe4027f2a055668f017" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 10 Aug 2017 16:46:29 -0000 --94eb2c07cbe4027f2a055668f017 Content-Type: text/plain; charset="UTF-8" I believe the assumption is that the initial max offsets are sufficient for the TLS handshake. On Thu, Aug 10, 2017 at 8:24 AM, Tatsuhiro Tsujikawa wrote: > Hi, > > The current spec says that stream 0 is exempt from connection level flow > control. It is still subject to stream-level flow control. But the spec > does not allow MAX_STREAM_DATA frame in Client cleartext and Server > cleartext. So if credit is exhausted, peer cannot send more STREAM frame, > and opposite peer also cannot extend the offset, which creates deadlock. > Is it just an editorial issue that MAX_STREAM_DATA is missing in Client > cleartext or Server cleartext? Or are there any other way to handle this > situation? Should we assume that initial max offset is sufficient for TLS > handshake? > > Best regards, > Tatsuhiro Tsujikawa > > > > --94eb2c07cbe4027f2a055668f017 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the assumption is that the initial max offsets a= re sufficient for the TLS handshake.

On Thu, Aug 10, 2017 at 8:24 AM, Tatsuhiro Tsujika= wa <tatsuhiro.t@gmail.com> wrote:
Hi,

The current spec says that stream 0 is exempt from connection le= vel flow control.=C2=A0 It is still subject to stream-level flow control.= =C2=A0 But the spec does not allow MAX_STREAM_DATA frame in Client cleartex= t and Server cleartext.=C2=A0 So if credit is exhausted, peer cannot send m= ore STREAM frame, and opposite peer also cannot extend the offset, which cr= eates deadlock.
Is it just an editorial issue t= hat MAX_STREAM_DATA is missing in Client cleartext or Server cleartext?=C2= =A0 Or are there any other way to handle this situation?=C2=A0 Should we as= sume that initial max offset is sufficient for TLS handshake?

=
Best regards,
Tatsuhiro Tsuj= ikawa




--94eb2c07cbe4027f2a055668f017-- From nobody Thu Aug 10 19:09:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 234D6132021 for ; Thu, 10 Aug 2017 19:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32b1-pg-839L for ; Thu, 10 Aug 2017 19:09:14 -0700 (PDT) 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 6C17C131CED for ; Thu, 10 Aug 2017 19:09:14 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id j32so15891926iod.0 for ; Thu, 10 Aug 2017 19:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0H/hPMq+O13K7BgPm5MP+7h2pl7agWqLj66qb0WW/00=; b=SrunHbstaFO4NdpzeocbVtYcAjRbradTKPNIG9WnAzPmWekW3r0Ac7cYGtAI4NFEJU ClmXyoHa9NY/itR6H+sXu0xoB4UY9eDIP7xjzlC7uKnaekMkb5v6a6y9iBQ2Ua30Ky1j ZqSXHPSCxPmj2g5LtBVYbGNwhBvvKVfZ9aiZuVQZqXnoT5X1b/wvrdiDlM29kka/OpUg 4QGYv7ObSxNGpOkLG2CYrOjhiauKqUQFUrqosCVxE0jqsvnwH9BFzSDmjEmC6AAVpWk8 ofFvfto+b9ptO0SU6Xu4J8VmuOpS3U8rgABk5RwJqxgMekE20+X/nOvABLD3VvPGsGWr MzFg== 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=0H/hPMq+O13K7BgPm5MP+7h2pl7agWqLj66qb0WW/00=; b=TKssdnrX1wwwlq5Zp/XumC/swnIjQ36inasBlWSEdNhcagSZ3cI4VSwfQZNkxNRXEr 9eIIDvrT789i9kZIAbK9UWYXB54j0BOlGxHqqhcWu7uvdZXAEV8dH+E5G85i0aconB+U jgMyF24VjV+n8/epYGrVj7TxL8dwqDWQfEKpgAtMTQjnfQQM/8IfGSGLEYTlDPSokv+3 29u45E07MIwEJ0N1irze+jCzq3qwjeY921/81eAS9gfSjtGtoPjd++LQWnwVCgSfY4oc jXosWSP/EpRJ+EbzGlYt9elZKWBdA8mTRTKfls44jBsgNFy0x4PhqTmYFsCRF5DTA9C6 8k7Q== X-Gm-Message-State: AHYfb5ihuASgq5SQV092VrHR7rrhisk57sQbqEWcCW+O568XoeParT2r SPsOFIxf1t8BfnzCgfjW7FdSgiEnCQ== X-Received: by 10.107.46.155 with SMTP id u27mr11093106iou.107.1502417353776; Thu, 10 Aug 2017 19:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 10 Aug 2017 19:09:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 11 Aug 2017 12:09:13 +1000 Message-ID: Subject: Re: stream 0 and flow control To: Ian Swett Cc: Tatsuhiro Tsujikawa , IETF 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, 11 Aug 2017 02:09:16 -0000 s/initial/default, but yes. On 11 August 2017 at 02:46, Ian Swett wrote: > I believe the assumption is that the initial max offsets are sufficient for > the TLS handshake. > > On Thu, Aug 10, 2017 at 8:24 AM, Tatsuhiro Tsujikawa > wrote: >> >> Hi, >> >> The current spec says that stream 0 is exempt from connection level flow >> control. It is still subject to stream-level flow control. But the spec >> does not allow MAX_STREAM_DATA frame in Client cleartext and Server >> cleartext. So if credit is exhausted, peer cannot send more STREAM frame, >> and opposite peer also cannot extend the offset, which creates deadlock. >> Is it just an editorial issue that MAX_STREAM_DATA is missing in Client >> cleartext or Server cleartext? Or are there any other way to handle this >> situation? Should we assume that initial max offset is sufficient for TLS >> handshake? >> >> Best regards, >> Tatsuhiro Tsujikawa >> >> >> > From nobody Thu Aug 10 22:40:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2C132487 for ; Thu, 10 Aug 2017 22:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EshufBTTxIA for ; Thu, 10 Aug 2017 22:40:10 -0700 (PDT) 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 059421324AA for ; Thu, 10 Aug 2017 22:40:10 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id c74so16671417iod.4 for ; Thu, 10 Aug 2017 22:40:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eLHuLUsWDHy6Tuk3yHWpwsg0QwhDeq+muSXlPoch3gI=; b=Tpy+P+mH0eySqEsUKJHunQdKlHBEaxRaqZ5/eZFa7GItCh2hje4K6qyhtdsTFdHmcG N67idd0I4M2BCimeh1RD9UMokqnmjZrJquPaN6Z+dj0CAbxFZNrcf5DnCUgFC6I9nHDD A3oOEAlus5+mcivm2mUpOW6itI9k1DlEpFAWpwS+wy3duqDp5a+GpV1+yj1gA2PPebKO 180Kzvig0fkarzytDJdqMEpR6BsQuJ2u3BfWDSTXOG+CXfs0X3j+ZtPggKEvAdwemQe2 Y8WgCARu7JIHNFSsUSIjzyaLL3pQPjJYn/QZaC151p7vulSy5cOBaGeZKAuvettuaNK1 fjvQ== 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=eLHuLUsWDHy6Tuk3yHWpwsg0QwhDeq+muSXlPoch3gI=; b=pSnAFpcCYwJ11vy36T7hfmbhLkKbB1xJNKdHkw/NAnIQGVFHSj4AtwHBTjMPJwj1+B hdusHAkuswkS/CMvJEph0a1QQOQm/fKhtq8mg/FG3P6R71rfD1+dVbc82bVq6fduUy5J 0U/5GkVAzVhXRJfClA882uk1YvEQkbqu23LJj8NP8SFTckN5j9FQuv6DJmZX85U68eD7 v7SoELb/G/VTy8XYAaMFtg3/E505u4ffHmwBi0RmEcAMnnrlb16XX1bBmYDzpUhFUgsC npR8TXCn8nR+uM3hm01Gl/1+tjD5I0MA4yIG3CiIu1tONYsrYrKJgvg/XMoy6hvAMvGC 1IQQ== X-Gm-Message-State: AHYfb5jxYta5uLW0uOx1uYI4wPsfyE6eArpPCeJKOYrtiMi2Mho7nymW lxjZTBmwJpOhnifRqFTqiBmvemJtP9CnGB8= X-Received: by 10.107.137.30 with SMTP id l30mr13068649iod.279.1502430009203; Thu, 10 Aug 2017 22:40:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 10 Aug 2017 22:40:08 -0700 (PDT) From: Martin Thomson Date: Fri, 11 Aug 2017 15:40:08 +1000 Message-ID: Subject: Splitting transport and application error code spaces 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: Fri, 11 Aug 2017 05:40:12 -0000 A while back we decided to use a single error code space. But in https://github.com/quicwg/base-drafts/issues/485, I noticed that we have an implicit requirement in the protocol not to have the transport close streams. If the transport resets streams, it could destroy critical application state. The neatest way to enforce the separation of application and transport is to create an application error space: https://github.com/quicwg/base-drafts/pull/722 This splits the error codes for application protocols from the transport codes. To do this, it splits CONNECTION_CLOSE into TRANSPORT_CLOSE and APPLICATION_CLOSE. These two frames have identical format and semantics, but use different error code spaces. RST_STREAM and STOP_SENDING now only carry application error codes, making it clear that resetting streams is the domain of the application protocol. In doing this, I noticed that the error code space is ludicrously large. So I have a companion PR that shrinks it to a much more manageable 16 bits: https://github.com/quicwg/base-drafts/pull/723 From nobody Fri Aug 11 03:00:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1142713253E for ; Fri, 11 Aug 2017 03:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpM350adqu8L for ; Fri, 11 Aug 2017 03:00:32 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BFE132565 for ; Fri, 11 Aug 2017 03:00:31 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id 16so18311470qtz.4 for ; Fri, 11 Aug 2017 03:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cHIRL7XGl6KStE/9H6/d8GzmegGhuyJt3oQ4rJJxUMo=; b=sGOHSVGanp/eBcp37ipjX7KeLWQKD7A1EDGYn4wnDX/v5Pev+BKN1qHrcmTbVLQqea ecLvBLTm2MdWvbRuUecLZI1kDn4sHyOhYZNMwRYiKfrXhMFLYW8+dD85npAjtglrYtsR sJvLwSarbgUBDl+gNst5f6PPq37i6vvkv5yemy73uJ+SqwCJHL4mW3aJN6rBimLCqMsG 4+NbWlBlDYrUXMCXvasFvRi8lMF2g9e7H2SQZNC4M8aBnpL+GGsEWhaPg3Tq1VezUlcB LgpoZe7qo9sDT5WpQTN+srxA7gEbkWY1bcjUcRQNXhJ9zFwDGBd6jyZP/rber6VVWuac dflg== 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=cHIRL7XGl6KStE/9H6/d8GzmegGhuyJt3oQ4rJJxUMo=; b=SW9lqfsm3z72l8KVnv3wZ63hsLiKwtCF+DK7A5GvGN4UwFdpL9DpF0vB7lhvdkRIb+ oMOwO59KnIrBrfQ5sXDprBXjZjR11dEsTZC3IjnxiS7Elvw9BXn/oDrOP4+A60LcxLfz TXX0QyFG85JXI8sa8Sg87KKp17ou4BzMjeQu84mjIiBysbXcwgv+x6UtFI5M5mkRp4Pu g/JRitgfs6K6M0pxcuXBZ92O0ORL1JVXaFaIkKYzCLFBk5/IAgpX9OX9wqBqAPe3mlig T3kqhkmWMOQENOA7ahgy8bcmRMIhGje/2tY7CXLNf4NS6umR0cPOgs4jAbJdChiQZFQe lMGg== X-Gm-Message-State: AHYfb5jrGw7IhNrmrXs+4F+u5v6VEtMISnyNxr3VaT5W60r69WHpgY4r F3esGMg0SjNKoSQLGZuC8Rs5oGu3oDjT X-Received: by 10.200.46.195 with SMTP id i3mr19065699qta.219.1502445630769; Fri, 11 Aug 2017 03:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.52.150 with HTTP; Fri, 11 Aug 2017 03:00:30 -0700 (PDT) Received: by 10.200.52.150 with HTTP; Fri, 11 Aug 2017 03:00:30 -0700 (PDT) In-Reply-To: References: From: Tatsuhiro Tsujikawa Date: Fri, 11 Aug 2017 19:00:30 +0900 Message-ID: Subject: Re: stream 0 and flow control To: Martin Thomson Cc: IETF QUIC WG , Ian Swett Content-Type: multipart/alternative; boundary="001a113f494e1dcd550556776220" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Aug 2017 10:00:34 -0000 --001a113f494e1dcd550556776220 Content-Type: text/plain; charset="UTF-8" 2017/08/11 11:09 "Martin Thomson" : s/initial/default, but yes. On 11 August 2017 at 02:46, Ian Swett wrote: > I believe the assumption is that the initial max offsets are sufficient for > the TLS handshake. > Thank you. What should implementation do when that assumption fails? As for default max stream data, I failed to find it anywhere in the docs. I thought that max stream data in transport parameters is applied to stream 0 as well, but do you mean that stream 0 always gets the default max stream data, unaffected by transport parameters? Best regards, Tatsuhiro Tsujikawa > On Thu, Aug 10, 2017 at 8:24 AM, Tatsuhiro Tsujikawa < tatsuhiro.t@gmail.com> > wrote: >> >> Hi, >> >> The current spec says that stream 0 is exempt from connection level flow >> control. It is still subject to stream-level flow control. But the spec >> does not allow MAX_STREAM_DATA frame in Client cleartext and Server >> cleartext. So if credit is exhausted, peer cannot send more STREAM frame, >> and opposite peer also cannot extend the offset, which creates deadlock. >> Is it just an editorial issue that MAX_STREAM_DATA is missing in Client >> cleartext or Server cleartext? Or are there any other way to handle this >> situation? Should we assume that initial max offset is sufficient for TLS >> handshake? >> >> Best regards, >> Tatsuhiro Tsujikawa >> >> >> > --001a113f494e1dcd550556776220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017/08/11 11:09 "Martin Thomson" <martin.thomson@gmail.com>:
s/initial/default, but yes.

On 11 August 2017 at 02:46, Ian Swett <ianswett@google.com> wrote:
> I believe the assumption is that the initial max offsets are sufficien= t for
> the TLS handshake.
>

Thank you.=C2=A0 What should implementation do when that as= sumption fails?
As for default max stream data, I fa= iled to find it anywhere in the docs.
I thought that= max stream data in transport parameters is applied to stream 0 as well, bu= t do you mean that stream 0 always gets the default max stream data, unaffe= cted by transport parameters?

Best regards,
Tatsuhiro Tsujikawa

> On Thu, Aug 10, 2017 at 8:24 AM, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
> wrote:
>>
>> Hi,
>>
>> The current spec says that stream 0 is exempt from connection leve= l flow
>> control.=C2=A0 It is still subject to stream-level flow control.= =C2=A0 But the spec
>> does not allow MAX_STREAM_DATA frame in Client cleartext and Serve= r
>> cleartext.=C2=A0 So if credit is exhausted, peer cannot send more = STREAM frame,
>> and opposite peer also cannot extend the offset, which creates dea= dlock.
>> Is it just an editorial issue that MAX_STREAM_DATA is missing in C= lient
>> cleartext or Server cleartext?=C2=A0 Or are there any other way to= handle this
>> situation?=C2=A0 Should we assume that initial max offset is suffi= cient for TLS
>> handshake?
>>
>> Best regards,
>> Tatsuhiro Tsujikawa
>>
>>
>>
>

--001a113f494e1dcd550556776220-- From nobody Fri Aug 11 03:32:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F031613213D for ; Fri, 11 Aug 2017 03:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 VoWyB2nyBxEW for ; Fri, 11 Aug 2017 03:32:13 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5C0129B30 for ; Fri, 11 Aug 2017 03:32:13 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id 76so25837249ith.0 for ; Fri, 11 Aug 2017 03:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yMxnfkPtD5tX4gImnPRYIt44I0c9K8KYSA7xgMYUg18=; b=Nz2WjJ29Tc3wjPK4VDPQIpiD3S6qUMlBBuM3zyn7jCbymKlDfetJfshlxprJwh0uVP y0j/UdHk7Q8X+k8VrVtnNrGRsgAfa8l9+gtNV37+q46PYe9q1JFwPMYP3qR2fu6bl1Vd PZkBTt0v+mayBtMxHMKgNyONhOFUxxsjxyxkuwUxS4l+7gdf+sgegGPqxxRVHBeoHlwa 0+Zxm7HW6OsiDmN3WXQXgDPzreGxIioMqCV5Cgw3Cw4T5xglvaMY7neV6IW0KjEIc9kz hQTQIJ4WvMFlpkGjFfUlKFgoQse8m1hQvEq5U90vch2sDOP07z71kAxq/zTWnfbGdMM5 9OOw== 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=yMxnfkPtD5tX4gImnPRYIt44I0c9K8KYSA7xgMYUg18=; b=mI7MnhEabSkxl6LbYtzU4XDANjQrAhYq0HdlItw5CbKyBDbgmz7IcGS4UkTCj2v1Sw VAH9aSvVtZHtzfzpEzDb/q79RVOuGBNfUf+BDET5rPN8eK6XDeiur4NabmGNvODieCRU rvSkty9U/qlYESPx264yvky98siFqWKdWOohMZ32zqL7f3TxX+xNkmZXcFAymrVFga+Y 8F04bZ5Jctjo2bFikm3aujNRQ6KTj1+2wXA5sMSWS1yd0UopiWOCs7Qzx/IKzUWYN5EX Q+8H52J2BGOGGtxEr8VVaJuulaxe8iwkPXqc/db2k2fB0FZDbT1ElPQEZbYbl/s5iL5H K7jA== X-Gm-Message-State: AIVw111S/gcfgjXE9Jhvg6XGlH/Ha9KAz/GrolmAwLBp2DFKnV2jgcz+ H87a2rPujKfqSKLTchfq3NjR9Rc4TQ== X-Received: by 10.36.87.5 with SMTP id u5mr11980800ita.151.1502447532351; Fri, 11 Aug 2017 03:32:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Fri, 11 Aug 2017 03:32:11 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 11 Aug 2017 20:32:11 +1000 Message-ID: Subject: Re: stream 0 and flow control To: Tatsuhiro Tsujikawa Cc: IETF QUIC WG , Ian Swett 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, 11 Aug 2017 10:32:15 -0000 On 11 August 2017 at 20:00, Tatsuhiro Tsujikawa wrote: > Thank you. What should implementation do when that assumption fails? The client has to start over if it receives HelloRetryRequest (we should write that down), so it only has one ClientHello to send before it receives transport parameters from the server. That means that it has whatever the initial value is, less up to just near 1200 octets in its second flight. If the server asks for a client certificate, then it is possible to blow out the handshake, but you'd have to try. 63k is a very bloated certificate. If you did somehow manage to get one of those, then the server can send MAX_[STREAM_]DATA in its "0.5 RTT data", so it's not fatal even if you did blow the limit (it just delays the completion of the handshake). The server could genuinely be a problem, because it can't receive anything but the transport parameters that set MAX_STREAM_DATA from the client before the handshake is complete. It also has a larger handshake more often. It still largely comes down to certificate size, and if it can't fit a certificate in the space that the client gives it, then that's a big problem with the certificate. If the server has too large a certificate and the client sets too low an initial MAX_STREAM_DATA, I think that we have a choice: https://github.com/quicwg/base-drafts/issues/725 > As for default max stream data, I failed to find it anywhere in the docs. Yeah, I spoke to hastily before. We don't need defaults or initial values because no peer other than the client sends a packet in ignorance of the limits of the other side. The only packet that the client sends is the ClientHello, which is size-limited (at least by the MTU - I guess in theory it could take up a whole 64k jumbogram). From nobody Fri Aug 11 07:28:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70A5D1276AF for ; Fri, 11 Aug 2017 07:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 GgriHszXKITp for ; Fri, 11 Aug 2017 07:28:07 -0700 (PDT) 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 3A485131CE8 for ; Fri, 11 Aug 2017 07:28:07 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id v29so21876253qtv.3 for ; Fri, 11 Aug 2017 07:28:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JNDlI4VW1BZFNTEBuIKo8Ns804YRuzrjHZ9mG10cyBM=; b=rFjrzeVlWpg4h8uDGeST8jpAxiN1pU6DVufKsvXR72p4SO1JJ+cZxy1OAo4ixWy8iN LKyVRE6xd58S7AKKj6U3muwH1rXIHniZRbqKizMJtSdwrIsYtlyy3vHQr7EVzx8t616K 6bEHh5nt/rRIEXkksTWP308MNEaheosX23KEnB/DofPKwD213Pw8cxqDFFZq1RhVZ+He /pNheHw2057Yqp4vxROqTIAjl/Cctx9LWzeZxRHxT9BMm1T0Wm0UVN7vm4ODjIoWzonB gcnxommfDh6bjSyZOHu4VOEl7sWN+HEFFEKc+aLuiktJdEPXl6YHFKvETmyIdG9ns5mX U9KQ== 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=JNDlI4VW1BZFNTEBuIKo8Ns804YRuzrjHZ9mG10cyBM=; b=KOPuQMCQIYHa4AbaLU0qrdSoyIH8rjSgHW5Bp7gURDjX4a4w9wQlCmG7sz5usJQAPI FybpBKtW9FIWO7wpwgDJyKDoR1KLnzMNf1XnNc1YbLs013VQ47SX6ZDOQDsQ6dYBmqi7 PhulcNFNGMIUZ5bpvxTgx/Eu4A7zLGqjb7dTl7xxzLHTGE1Kk8AL/JAzc6QddnTMpmd8 89LSs4gilNhTD4ZIEn16p6tqdj5nlIJ4LaJzSRXf/CX9y1eILRgN5EgBSqZJuejGM4t+ pbMPsWi4VKc8+WS4WkUDAHIWsn+5Ps2464tPQpUJFlYz2E/+h/++Q3d4jG8fk9+YrePG mqvw== X-Gm-Message-State: AHYfb5jGrT4hCR94W0vSVShoezib072HKYdc8TevMdyBn946K0rOgqHv 2f8je0nUCzyjzkpA8Q1YY0hL+H4uEw== X-Received: by 10.237.38.132 with SMTP id q4mr20552756qtd.321.1502461686369; Fri, 11 Aug 2017 07:28:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.52.150 with HTTP; Fri, 11 Aug 2017 07:28:05 -0700 (PDT) Received: by 10.200.52.150 with HTTP; Fri, 11 Aug 2017 07:28:05 -0700 (PDT) In-Reply-To: References: From: Tatsuhiro Tsujikawa Date: Fri, 11 Aug 2017 23:28:05 +0900 Message-ID: Subject: Re: stream 0 and flow control To: Martin Thomson Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0672da1ad63a05567b1f94" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Aug 2017 14:28:09 -0000 --94eb2c0672da1ad63a05567b1f94 Content-Type: text/plain; charset="UTF-8" 2017/08/11 19:32 "Martin Thomson" : On 11 August 2017 at 20:00, Tatsuhiro Tsujikawa wrote: > Thank you. What should implementation do when that assumption fails? The client has to start over if it receives HelloRetryRequest (we should write that down), so it only has one ClientHello to send before it receives transport parameters from the server. That means that it has whatever the initial value is, less up to just near 1200 octets in its second flight. If the server asks for a client certificate, then it is possible to blow out the handshake, but you'd have to try. 63k is a very bloated certificate. If you did somehow manage to get one of those, then the server can send MAX_[STREAM_]DATA in its "0.5 RTT data", so it's not fatal even if you did blow the limit (it just delays the completion of the handshake). The server could genuinely be a problem, because it can't receive anything but the transport parameters that set MAX_STREAM_DATA from the client before the handshake is complete. It also has a larger handshake more often. It still largely comes down to certificate size, and if it can't fit a certificate in the space that the client gives it, then that's a big problem with the certificate. If the server has too large a certificate and the client sets too low an initial MAX_STREAM_DATA, I think that we have a choice: https://github.com/quicwg/base-drafts/issues/725 > As for default max stream data, I failed to find it anywhere in the docs. Yeah, I spoke to hastily before. We don't need defaults or initial values because no peer other than the client sends a packet in ignorance of the limits of the other side. The only packet that the client sends is the ClientHello, which is size-limited (at least by the MTU - I guess in theory it could take up a whole 64k jumbogram). Thank you for detailed explanation. I have not noticed .5 rtt data, it's clever idea. Best regards, Tatsuhiro Tsujikawa --94eb2c0672da1ad63a05567b1f94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2017/08/11 19:32 "Martin Thomson" <martin.thomson@gmail.com>:
On 11 August = 2017 at 20:00, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> Thank you.=C2=A0 What should implementation do when that assumption fa= ils?

The client has to start over if it receives HelloRetryRequest (we
should write that down), so it only has one ClientHello to send before
it receives transport parameters from the server.=C2=A0 That means that it<= br> has whatever the initial value is, less up to just near 1200 octets in
its second flight.=C2=A0 If the server asks for a client certificate, then<= br> it is possible to blow out the handshake, but you'd have to try.=C2=A0 = 63k
is a very bloated certificate.=C2=A0 If you did somehow manage to get one of those, then the server can send MAX_[STREAM_]DATA in its "0.5 RTT data", so it's not fatal even if you did blow the limit (it just delays the completion of the handshake).

The server could genuinely be a problem, because it can't receive
anything but the transport parameters that set MAX_STREAM_DATA from
the client before the handshake is complete.=C2=A0 It also has a larger
handshake more often.=C2=A0 It still largely comes down to certificate
size, and if it can't fit a certificate in the space that the client gives it, then that's a big problem with the certificate.

If the server has too large a certificate and the client sets too low
an initial MAX_STREAM_DATA, I think that we have a choice:

=C2=A0 https://github.com/quicwg/base-drafts/is= sues/725

> As for default max stream data, I failed to find it anywhere in the do= cs.

Yeah, I spoke to hastily before.=C2=A0 We don't need defaults or = initial
values because no peer other than the client sends a packet in
ignorance of the limits of the other side.=C2=A0 The only packet that the client sends is the ClientHello, which is size-limited (at least by
the MTU - I guess in theory it could take up a whole 64k jumbogram).

T= hank you for detailed explanation.=C2=A0 I have not noticed .5 rtt data, it= 's clever idea.

Best= regards,
Tatsuhiro Tsujikawa


--94eb2c0672da1ad63a05567b1f94-- From nobody Fri Aug 11 07:42:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759301321AA for ; Fri, 11 Aug 2017 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtAMb8bfVnMd for ; Fri, 11 Aug 2017 07:42:22 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F349129AD3 for ; Fri, 11 Aug 2017 07:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v3FpMN54mZHyA3X9X9bJ6o+z2R3YD8RfEFaqLSlHog8=; b=SgrALSYbvdgSZ03JbTOxktisudL6GAp665k3njSBYurxifqQCS+Z5NkXYylp3esfLwOE2N7rWWlVVUOzivXu4Y6L4R6aJREzm2gq5sD1OFedQLzO+8b/MVwd6bhobW46nxT0nhz2mbIV7XHfBMycafzEtoXCE+WsZE+mRQzcQvo= Received: from CY4PR21MB0136.namprd21.prod.outlook.com (10.173.189.18) by CY4PR21MB0118.namprd21.prod.outlook.com (10.173.189.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.5; Fri, 11 Aug 2017 14:42:21 +0000 Received: from CY4PR21MB0136.namprd21.prod.outlook.com ([10.173.189.18]) by CY4PR21MB0136.namprd21.prod.outlook.com ([10.173.189.18]) with mapi id 15.01.1362.011; Fri, 11 Aug 2017 14:42:21 +0000 From: Mike Bishop To: Martin Thomson , QUIC WG Subject: RE: Splitting transport and application error code spaces Thread-Topic: Splitting transport and application error code spaces Thread-Index: AQHTEmRSPsl9gZnFJ0aVX2eLrEQ0JKJ/O0rX Date: Fri, 11 Aug 2017 14:42:21 +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: [2601:600:8080:5a28:8092:506c:dad1:8720] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0118; 6:tsOPGbY9g1i29vTjIe7G7frNVjmom9fQjpct2beXG3c6qLKq9DNpgHQRaRuPxxbHFBBXs/d/QtAKBqFsqvYsg5u9GlyogF0kWSeCpKv1qzAK1uO3ed2EDmzYmC9RZR+F4UlUpUxMLj8DxCoJI6t/DZpKtqQc1EAd1u9b2pG1UVrD4+vyVdkB0y6ZiYOcDE3oC7pO3xqOUBORyP9Sk/eCCTn7xfCdXwkaBPxwwOOTh3900cDFZ5vYzKhrAO2imC9v9iSNdpwFh7QNyWg3lJRGfnB7uNKZobXBXFV+1hFewBUELigToalz+vuMCIFXUbqWAL9DQAR/TCPlAk5EguPN/A==; 5:/ZJKrXa+ciq32uUyqe2vLtHwcd0eleRvlV4V8xxNncPpgvL0uRekFvSuz9Xx9HR4+IyC1Xy4CqXBa9oK1Lvp/7n4zoId+1izFjLfY9iQanDOYEdLHkVOTOsmlxsAB2ltse527qKyver4I0d63mKV6w==; 24:5qEJcsXlvmoS5yQt4eAh+upPNopwcQSF2D/rgCxKjBt2REjXuaCqvMj1HSysjv7MTg0FrG7aO9BasTgZ5nSkDoshVW/xMN4uOg46NEp3zX4=; 7:ih/SqhNylLShEx6Fk1qXFFdZkmidhtAvRsFfeYB8NlwGY1HDSvYKM5cwg3I/HM0N1iLTMJ4HGue5IeW7BvQq52+mpwKz8dY/HyaL0cVNRiWEr8DNoPDqZI32j4ce2rqK09ShCBhBVlDgTnrD3GzC0GVm1EPkx6+c+a8dGLOXhfmyrX8Y9b/LcYMoovns5irte1YWuzuUm1J3phYUHHUaaiOl/iWYD8Rw0B809u1L5o0= x-ms-office365-filtering-correlation-id: 48b32838-a346-47d2-2bcf-08d4e0c72c4e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603135)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY4PR21MB0118; x-ms-traffictypediagnostic: CY4PR21MB0118: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0118; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0118; x-forefront-prvs: 03965EFC76 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(189002)(377454003)(199003)(14454004)(10090500001)(478600001)(6506006)(189998001)(53546010)(74316002)(77096006)(55016002)(6436002)(3660700001)(10290500003)(606006)(5660300001)(229853002)(2950100002)(97736004)(86612001)(72206003)(86362001)(53936002)(33656002)(6246003)(236005)(9686003)(101416001)(54896002)(6306002)(39060400002)(575784001)(7696004)(966005)(105586002)(7736002)(106356001)(54356999)(76176999)(99286003)(50986999)(8936002)(2900100001)(25786009)(2906002)(102836003)(81156014)(81166006)(5005710100001)(8990500004)(6116002)(3280700002)(8676002)(68736007)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0118; H:CY4PR21MB0136.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0136EE9B4C91C296860A38F687890CY4PR21MB0136namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2017 14:42:21.0329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0118 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 11 Aug 2017 14:42:29 -0000 --_000_CY4PR21MB0136EE9B4C91C296860A38F687890CY4PR21MB0136namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Okay with the general direction, but not wild about the frame split. In ge= neral, nearly-identical frames make me question. Given that the assigned 0x2 and 0x3 differ by one bit, might it be clearer = to have an embedded flag in CONNECTION_CLOSE indicating the source? That a= voids having two frames with identical semantics except the registry in whi= ch you look up the value of a field. Sent from my Windows 10 phone From: Martin Thomson Sent: Thursday, August 10, 2017 10:40 PM To: QUIC WG Subject: Splitting transport and application error code spaces A while back we decided to use a single error code space. But in https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.c= om%2Fquicwg%2Fbase-drafts%2Fissues%2F485&data=3D02%7C01%7Cmichael.bishop%40= microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636380268206522856&sdata=3DLo0K3hCLYeiVHx9WIZu3zDU1qp43n= 4Xc31RirijGbnU%3D&reserved=3D0, I noticed that we have an implicit requirement in the protocol not to have the transport close streams. If the transport resets streams, it could destroy critical application state. The neatest way to enforce the separation of application and transport is to create an application error space: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fquicwg%2Fbase-drafts%2Fpull%2F722&data=3D02%7C01%7Cmichael.bishop%40= microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636380268206522856&sdata=3DFko06fKB9DbI0S58mUz%2BFyVLZ4k= cxNt9e5dKRQ1XH5A%3D&reserved=3D0 This splits the error codes for application protocols from the transport codes. To do this, it splits CONNECTION_CLOSE into TRANSPORT_CLOSE and APPLICATION_CLOSE. These two frames have identical format and semantics, but use different error code spaces. RST_STREAM and STOP_SENDING now only carry application error codes, making it clear that resetting streams is the domain of the application protocol. In doing this, I noticed that the error code space is ludicrously large. So I have a companion PR that shrinks it to a much more manageable 16 bits: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub= .com%2Fquicwg%2Fbase-drafts%2Fpull%2F723&data=3D02%7C01%7Cmichael.bishop%40= microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7c= d011db47%7C1%7C0%7C636380268206522856&sdata=3DqkeITvAPa%2BeAPEB%2FCz7wtmujG= cqQnzExH7R01fxCKJc%3D&reserved=3D0 --_000_CY4PR21MB0136EE9B4C91C296860A38F687890CY4PR21MB0136namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Okay with the general direction, but not wild abou= t the frame split.  In general, nearly-identical frames make me questi= on.

 

Given that the assigned 0x2 and 0x3 differ by one = bit, might it be clearer to have an embedded flag in CONNECTION_CLOSE indic= ating the source?  That avoids having two frames with identical semant= ics except the registry in which you look up the value of a field.

 

Sent from my Windows 10 phone

 

From: Martin Thomson
Sent: Thursday, August 10, 2017 10:40 PM
To: QUIC WG
Subject: Splitting transport and application error code spaces

 

A while back we decided to use a single error code= space.  But in
https://na01.safelin= ks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-d= rafts%2Fissues%2F485&data=3D02%7C01%7Cmichael.bishop%40microsoft.com%7C= e667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0= %7C636380268206522856&sdata=3DLo0K3hCLYeiVHx9WIZu3zDU1qp43n4Xc31RirijGb= nU%3D&reserved=3D0, I noticed that we
have an implicit requirement in the protocol not to have the transport
close streams.  If the transport resets streams, it could destroy
critical application state.

The neatest way to enforce the separation of application and transport
is to create an application error space:

  https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.c= om%2Fquicwg%2Fbase-drafts%2Fpull%2F722&data=3D02%7C01%7Cmichael.bishop%= 40microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d= 7cd011db47%7C1%7C0%7C636380268206522856&sdata=3DFko06fKB9DbI0S58mUz%2BF= yVLZ4kcxNt9e5dKRQ1XH5A%3D&reserved=3D0

This splits the error codes for application protocols from the
transport codes.  To do this, it splits CONNECTION_CLOSE into
TRANSPORT_CLOSE and APPLICATION_CLOSE.  These two frames have
identical format and semantics, but use different error code spaces.
RST_STREAM and STOP_SENDING now only carry application error codes,
making it clear that resetting streams is the domain of the
application protocol.

In doing this, I noticed that the error code space is ludicrously
large.  So I have a companion PR that shrinks it to a much more
manageable 16 bits:

  https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fgithub.c= om%2Fquicwg%2Fbase-drafts%2Fpull%2F723&data=3D02%7C01%7Cmichael.bishop%= 40microsoft.com%7Ce667a5b2f79c451b47f208d4e07b7337%7C72f988bf86f141af91ab2d= 7cd011db47%7C1%7C0%7C636380268206522856&sdata=3DqkeITvAPa%2BeAPEB%2FCz7= wtmujGcqQnzExH7R01fxCKJc%3D&reserved=3D0

 --_000_CY4PR21MB0136EE9B4C91C296860A38F687890CY4PR21MB0136namp_-- From nobody Fri Aug 11 12:39:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0674A132350 for ; Fri, 11 Aug 2017 12:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=q/uXJJdw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EesZgZt4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apEadsXdHHVe for ; Fri, 11 Aug 2017 12:39:24 -0700 (PDT) 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 C49181320B5 for ; Fri, 11 Aug 2017 12:39:23 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7D47D20B7F; Fri, 11 Aug 2017 15:39:22 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 11 Aug 2017 15:39:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=sgd7hpKqOiEsyLwevT INzli8Df/LYqlWCdKQjOwRFBU=; b=q/uXJJdwwgXhDixFOowsveX5DIafkCdI4j uj6P/iMCrCGPa2skMd97VDhIIqumCZdHG0M4CYdrWXfBTHCsAgmbCAKBQCInzzae i9sSqOWHi4Gi7OJLZmhW+hkSQZY92EiC7TVmGwM5jk/m6SRLQxpLZDdzj3UZfPWq pcCsk4L2bIh9K/iQAUvOlZN+6NnTDlZsFR2Q3mB5+BiBKxeNzDf/TcIV1MCGQt99 zRyAOJM8BJM1HSWCtxCgoVrX3Xg51CKUdxQkVfFKP/QIhOFIMH6zJ36H2rA+jNvR F4S0VJLDegt8Mf3WwHs0fdo0O10j6/ddclWAL+0NB6JvQj4w7zVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=sgd7hpKqOiEsyLwevTINzli8Df/LYqlWCdKQjOwRFBU=; b=EesZgZt4 HTyD0PlQPUaBHyZDzxeUo0oezH7RW8ysefK5YP8G6vCzozgGr4biD+iPTc6FTQ8c ifq2gNQdDuPFrvdT89KdUuCb4BYRMkSIu+jxAfCzNW9JTsEWfD9vkt847WYO4Cql bIlon69COXPnTl09UJYg0NwJmoncrJv20TmsmIzjRQWKN5XBf3q7kc1bVlM3A8VC JxLcoPH+OV+qxwRaRSfikdyB5Ilzi0EnxayR+XRqMxKIp8JfJuXTZ7ut/6dTc7++ bUQ2RU0fMDApTMvF1k8hcshWCBkS4S7WXr/Xbyok/9Fe55AIXXRpwgo/yZNFTslo SLLCUKz50VbCyA== X-ME-Sender: X-Sasl-enc: fdB6zV5DGSk4RhDI50gMteBOtzvjw/WiaQYx17c6d1Ah 1502480362 Received: from [10.100.20.227] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id 045727F9A9; Fri, 11 Aug 2017 15:39:21 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Splitting transport and application error code spaces From: Mark Nottingham In-Reply-To: Date: Fri, 11 Aug 2017 12:39:21 -0700 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 19:39:27 -0000 Personally -- I'm +1 on this. Having a clear distinction is best. > On 10 Aug 2017, at 10:40 pm, Martin Thomson = wrote: >=20 > A while back we decided to use a single error code space. But in > https://github.com/quicwg/base-drafts/issues/485, I noticed that we > have an implicit requirement in the protocol not to have the transport > close streams. If the transport resets streams, it could destroy > critical application state. >=20 > The neatest way to enforce the separation of application and transport > is to create an application error space: >=20 > https://github.com/quicwg/base-drafts/pull/722 >=20 > This splits the error codes for application protocols from the > transport codes. To do this, it splits CONNECTION_CLOSE into > TRANSPORT_CLOSE and APPLICATION_CLOSE. These two frames have > identical format and semantics, but use different error code spaces. > RST_STREAM and STOP_SENDING now only carry application error codes, > making it clear that resetting streams is the domain of the > application protocol. >=20 > In doing this, I noticed that the error code space is ludicrously > large. So I have a companion PR that shrinks it to a much more > manageable 16 bits: >=20 > https://github.com/quicwg/base-drafts/pull/723 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Sat Aug 12 03:04:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F441324D5 for ; Sat, 12 Aug 2017 03:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3jCuLuoiQjq for ; Sat, 12 Aug 2017 03:04:15 -0700 (PDT) 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 178251324CF for ; Sat, 12 Aug 2017 03:04:15 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id 77so4689443itj.1 for ; Sat, 12 Aug 2017 03:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q+ex6CMl2iWO0T4jIj6Ml8x5UPm+pVwHONC2mOMN5xo=; b=KsTKyDHD/obAKgpMsr680JdSwkVAZUlLCPL7xtz92x3KLzRTSb7QawCHl+Iqi89Url H8eb5bwFaG/l//yv0ieNeADcb+MbTV1y/B5fpU9MZdg4+WnAzBmiy1iTr2AOAsDZQr/H UeOfHZrqjiTJdEMptSx3bIZltJmfmf1PkAPVQHbgTT+riUDB3HwqEPjYgE0X6speNCDe ePCT7iC5lvIC8ZjCjDRRnNp4QBoq1jvws1qpaNsAK5M07pEt64JeTsZdRTjp85l16DYo k29Oz0vtVKxWnYLgddhkZ7XMnExxdIiMFua84+zixdas+xKe2jJsn4MGj1RLuIPDlT3E ERyA== 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=q+ex6CMl2iWO0T4jIj6Ml8x5UPm+pVwHONC2mOMN5xo=; b=H7Z9NVVV/UvG++JXqh6gHqXlCmsEMpj2sQ1st9vqqGtS7icMPw/YlWZ3rBoNojEnoe LmJaUKMX+K+xIqw9jjqRTf1raGfD5Um5Delh3KMlCs4lYRgiMmFlyGut79n96sZrjqWe 4azgydQLtkAcaQW1X1t7UCKyCyGrC1ls0GU4J+UWIoW7uiQo1Jm4hOKuVAzJpyu2ZAIJ GHYCuX4Hwbh4YVOdDm18HHm4ZHQjJ+gNIMme8zyNS2hNh1OeppmM8RPHOWHu4nO7Ey/Y x4/2GmeQTAa2FmuEAwiabfSa4hpnfqkd+LwSE/39DKeHUwNaviiDQw1Ij0EdJA5KTgV8 DGHQ== X-Gm-Message-State: AHYfb5gmu9sg2GV3rksGLLTW9sQ15+0Tq82aKRVKPIzDW37GacbGwm3y 6t6L1dIEjlgROUelijW8vtfeoQ/m4g== X-Received: by 10.36.107.68 with SMTP id v65mr1390572itc.129.1502532254470; Sat, 12 Aug 2017 03:04:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Sat, 12 Aug 2017 03:04:13 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 12 Aug 2017 20:04:13 +1000 Message-ID: Subject: Re: Splitting transport and application error code spaces To: Mike Bishop 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: Sat, 12 Aug 2017 10:04:16 -0000 On 12 August 2017 at 00:42, Mike Bishop wrote: > Given that the assigned 0x2 and 0x3 differ by one bit, might it be clearer > to have an embedded flag in CONNECTION_CLOSE indicating the source? That > avoids having two frames with identical semantics except the registry in > which you look up the value of a field. It all amounts to the same thing, and I think that separate types is a better trend generally. I'm not a huge fan of the mix of discrete types and bit patterns, preferring the former for the sake of clarity. From nobody Sat Aug 12 22:15:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2950132849 for ; Sat, 12 Aug 2017 22:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham 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 jqqL2h7KUuCi for ; Sat, 12 Aug 2017 22:15:01 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91C49132469 for ; Sat, 12 Aug 2017 22:15:01 -0700 (PDT) Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v7D5EuMM013869 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 13 Aug 2017 05:14:57 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local Subject: Re: 5-tuple uniquess To: Ian Swett , "Lubashev, Igor" Cc: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , IETF QUIC WG , Ryan Hamilton References: From: joel jaeggli Message-ID: <814e9ca6-4c2d-a277-0fd3-08c856bf0af6@bogus.com> Date: Sat, 12 Aug 2017 22:14:53 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2017 05:15:05 -0000 On 8/9/17 20:33, Ian Swett wrote: > In Prague, we decided that the 5-tuple couldn't change during the > handshake, but we didn't say that a 5-tuple indicated a single QUIC > connection. > > For IPv6, a flow label can be used to spread load.  From my perspective, > the goal here is to allow multiple QUIC connections to share a 5-tuple, > not to recommend it for all use cases.  For example, it may make sense > to preclude it for HTTP over QUIC clients? Flow labels are known to change during handshakes... Source / dest and flow label is not at lot of entropy , esp if the latter happens to be zero. > On Wed, Aug 9, 2017 at 11:09 PM, Lubashev, Igor > wrote: > > I see “port reuse” as an instance of a generic “NAT rebinding” that > QUIC is built for.  We’ve maintained previously, however, that QUIC > tolerance to “connection migration / NAT rebinding” during > connection establishment is out of scope.  This proposal would seem > to revisit that scope.____ > > __ __ > > You may indeed want to open multiple concurrent connections from S > to B, hoping to spread your connections among multiple servers > behind B.  But it may actually be counter-productive to use a single > 5-tuple, if B is behind an ECMP router acting as a load balancer.  > Moreover, this will also defeat RSS/RPS/RFS > > load balancing mechanisms within servers.  Be aware.____ > > __ __ > > * Igor____ > > __ __ > > __ __ > > __ __ > > *From:*Mikkel Fahnøe Jørgensen [mailto:mikkelfj@gmail.com > ] > *Sent:* Wednesday, August 09, 2017 1:33 PM > *To:* Lubashev, Igor >; Ian Swett > > *Cc:* Ryan Hamilton >; IETF > QUIC WG > > *Subject:* RE: 5-tuple uniquess____ > > __ __ > > This may not address all your concerns, but I think perhaps you are > looking at the problem from the wrong end with respect to ephemeral > port exhaustion:____ > > __ __ > > In a typical NAT scenario you have many clients reaching for one > server, each client likely passing a different NAT.____ > > Hence each connection will be a unique 5-tuple, even if QUIC itself > is not making any effort to achieve this.____ > > __ __ > > Now, if one of these clients creates two connections to the same > server and chooses to reuse the outbound UDP port number, say > reaching for two different images, then the NAT might think that the > two connections are the same connection. And in some sense it is - > not the same QUIC connection, but the same operational context. > Thus, the two connections helps reduce NAT overhead and also > cooperates in keeping the NAT hole open.____ > > __ __ > > On the other end, at the server, there is a separate problem: The > server (S) does not have the requested images. It reaches to one of > a few possible backend servers (B1, B2). Since the server S is not > attempting to be clever, it creates a new QUIC connection from S to > B1 or B2 for each inbound client connection. There may or may not be > any NAT involved here, but the server S is only assigned a single IP > address for outbound requests and cannot create more concurrent > connections that the number of ephemeral ports + safety margin > permits, that is, unless it chooses to reuse outbound port numbers > which solves the problem of port exhaustion.____ > > __ __ > > If, on the other hand, a QUIC client were co-located with other > services, it might not be able to receive the correct packets when > these different services compete for port numbers. But here it > suffice that they either agree to use different ports (like PING vs. > DNS), or each service allocate a single ephemeral port for its > service via UDP socket creation. In either case the NAT would route > packets to the correct service by relying on 5-tuples even if QUIC > itself does not.____ > > __ __ > > So, going further - what if several hosts use the same IP address, > as is the case with load balancers? Again, 5-tuples are used to bind > connections to each unique host, only with fewer UDP ports there is > much less state to maintain. The middleware only need to route > traffic to the correct endpoint, not distinguish between logical > QUIC connections that happen between the same two entities.____ > > __ __ > > Kind Regards,____ > > Mikkel Fahnøe Jørgensen____ > > __ __ > > On 9 August 2017 at 19.03.35, Lubashev, Igor (ilubashe@akamai.com > ) wrote:____ > > Can someone elaborate on “Possibly it should specify the > client's connection ID in the packet header and then the new > server connection ID in the transport parameters?”____ > >  ____ > > Is that only for “Server Cleartext”? What about connections that > start out with 0RTT packets – how would the NAT know which flow > Server’s 1RTT reply belongs to (if Server changes the > ConenctionID)?____ > >  ____ > > Maybe relying on a 5-tuple is not such a bad idea after all?  A > NAT does not need a different ephemeral port for every outgoing > connection.  It only needs a different ephemeral port for > outgoing connections to the same IP.____ > >  ____ > > Even then, if the NAT is willing to do something special for > QUIC, it can be a much simpler thing than examine QUIC transport > params.  The NAT can simply reserve a single ephemeral port for > all 1RTT QUIC packets.  That is, all outgoing cleartext and 0rtt > QUIC packets would require a distinct 5-tuple, but once the > connection migrates to 1RTT, the ephemeral port it used can be > freed, and all 1RTT packets sourced from the reserved QIUC > port.  That would work, since all 1RTT packets (both from client > and server) would be using Server-selection ConnectionID.____ > >  ____ > > * Igor____ > >  ____ > >  ____ > >  ____ > > *From:*Ian Swett [mailto:ianswett@google.com > ] > *Sent:* Tuesday, August 08, 2017 7:01 PM > *To:* Mikkel Fahnøe Jørgensen > > *Cc:* IETF QUIC WG >; Ryan > Hamilton > > *Subject:* Re: 5-tuple uniquess____ > >  ____ > > You're right, ephemeral port exhaustion is a very real potential > issue, and I think we should ensure multiple QUIC connections > can run over the same 5-tuple and we don't specify QUIC in a way > that precludes that.____ > >  ____ > > I believe you're correct that the current Server Cleartext makes > this impossible if the server changes the connection ID.  > Possibly it should specify the client's connection ID in the > packet header and then the new server connection ID in the > transport parameters?  > https://github.com/quicwg/base-drafts/issues/714 > ____ > >  ____ > > The text is also missing some details on how changing the > connection ID should work for Stateless Retry, > see https://github.com/quicwg/base-drafts/issues/713 > , > so I'd expect some improvements in the near future.____ > >  ____ > > On Sun, Aug 6, 2017 at 10:43 AM, Mikkel Fahnøe Jørgensen > > wrote:____ > >  ____ > > Hi Ryan,____ > >  ____ > > I can dig down in more detail if there is interest. > Meanwhile, some examples where the transport document is not > compatible with my request is:____ > >  ____ > > The version negotiation packet is ok - it reflects the > client version____ > > https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-version > ____ > >  ____ > > But ____ > > https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#packet-server-cleartext > ____ > > "The connection ID field in a Server Cleartext packet > contains a connection ID that is chosen by the server > (see Section 5.6 > )."____ > > This breaks linkage to the original client connection id so > the client cannot tell which connection the response belongs > to unless looking into 5-tuple, or testing all recent > connections against AEAD signature (depending on where this > lands).____ > >  ____ > > I have not covered all other possible server responses, but > similar concerns apply.____ > > It is not a major change, but currently it is not possible.____ > >  ____ > > Another issue is hostile response to initial connection > setup, and plain errors - how to you reply with an error. > Having the connection id from the client makes it reasonably > easy to deal with - similar to version negotiation. > Alternatively you have to rely on 5-tuples. This requires > careful analysis of both the transport doc and possibly TLS > and thins are not fully settled. Stateless reset is related > to this. I will not argue strongly on this because since I > last looked at it, new AEAD encryption is being discussed, > and I have not analysed this in detail.____ > >  ____ > > Then there is connection migration. This also requires > careful analysis. I’m not sure if it currently covers my > request.____ > >  ____ > > I’m sure there are several other places with implicit > assumptions that I am not able to list off memory.____ > >  ____ > > The (my) basic rule is the any change in connection ID > should refer to the previous ID without relying on external > state such as 5-tuples or TLS extension state (which > requires crypto state to access and complicates things). > Also, due concerns of privacy concerns this linkage between > connection ID’s should only be possible by peers, excepts > for the initial client to server connection transition that > is also visible to any party on-path.____ > >  ____ > > In addition to the above encoding concerns, it may also be > helpful to explicitly state that the same UDP port may be > used to initiate multiple independent QUIC connection to the > same server UDP port when connection ID has been negotiated > to be present - or further detail this possibility as > something that can be negotiated.____ > >  ____ > >  ____ > > Some other points I forget to mention regarding benefits of > non-unique tuples:____ > >  ____ > > 5) no interference with OS is necessary in order to > establish a new connection to an existing endpoint because > no new ephemeral port is needed. This may also simplify > clean up and state management, especially server to server.____ > >  ____ > > 6) Netmap and similar high speed interfaces would be simpler > without having to deal with ephemeral port allocation, > especially server to server where both end points can > reference each other, and where it might be random which > endpoint actually initiates to the connection (as in Cord / > Kademlia style overlay networks)____ > >  ____ > > Kind Regards,____ > > Mikkel Fahnøe Jørgensen____ > >  ____ > >  ____ > > From nobody Sat Aug 12 22:49:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C8D1326A6 for ; Sat, 12 Aug 2017 22:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0fT-JzE3hgc for ; Sat, 12 Aug 2017 22:49:49 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC6C132443 for ; Sat, 12 Aug 2017 22:49:49 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx1.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1dglmQ-0005B6-0F for quic@ietf.org; Sun, 13 Aug 2017 07:49:47 +0200 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 1dglmM-0004VT-Ru for quic@ietf.org; Sun, 13 Aug 2017 01:49:39 -0400 Received: (qmail 6097 invoked from network); 13 Aug 2017 05:49:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.186]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 Aug 2017 05:49:36 -0000 To: quic@ietf.org References: <814e9ca6-4c2d-a277-0fd3-08c856bf0af6@bogus.com> From: Christian Huitema Message-ID: Date: Sat, 12 Aug 2017 22:49:35 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <814e9ca6-4c2d-a277-0fd3-08c856bf0af6@bogus.com> Content-Type: multipart/alternative; boundary="------------40645E993AB6B0D3370E252C" Subject: Re: 5-tuple uniquess X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23djQtkAj0kftwCytoBb2EZySY6X0AymshMdNr qf24jQ+coLO6uY07SvASWDUDZ2QvYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyc+lx9FvpaaNw+6/5L9JLpjeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237p0djsrZ/k7aFJneAV66i3WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6sJqelmxqtloshGkSoDyZkT9+DGUWcLTBDsB1igut167pK4Js0Kdf02/v QK/uylRaBdGp37fImJCD1L5r1UyutXBZ7pmcPPET1gsbqYqsHO2B1AyhUYt13ZFWiMbSDOe6Tsut 9Ntwqm/jmjsUXZwk2AT7Y9cRih4Det7+7EbH8nOrv5Mi7W1Fe3H2lzs3Ph6Br8hUVhe7ugL65f2h l2QLng== 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, 13 Aug 2017 05:49:52 -0000 This is a multi-part message in MIME format. --------------40645E993AB6B0D3370E252C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/12/2017 10:14 PM, joel jaeggli wrote: > On 8/9/17 20:33, Ian Swett wrote: >> In Prague, we decided that the 5-tuple couldn't change during the >> handshake, but we didn't say that a 5-tuple indicated a single QUIC >> connection. >> >> For IPv6, a flow label can be used to spread load. From my perspectiv= e, >> the goal here is to allow multiple QUIC connections to share a 5-tuple= , >> not to recommend it for all use cases. For example, it may make sense= >> to preclude it for HTTP over QUIC clients? > Flow labels are known to change during handshakes... > > Source / dest and flow label is not at lot of entropy , esp if the > latter happens to be zero. > Not to mention that there is hardly any cross-platform API to set or view flow labels on IPv6/UDP packets, and that we may also want a solution for IPv6. I would personally prefer a symmetric solution, in which the Server Clear Text packets are labelled with the initial Connection ID chosen by the client. If the server wants to change that, it could include a proposed connection ID as a parameter -- maybe as a transport parameter in the TLS extension. One of the really neat features of Quic is that a server can listen for multiple connections on a single UDP socket. This reduce the overhead of select or poll calls, because there is just one system interface to manage. I would like to be able to do exactly the same for clients. Maybe not a huge deal in HTTP/Web scenarios, but rather useful in proxy scenarios, such as for example DNS resolvers. Also, I would like to be able to support server mobility in the same manner as client mobility, and with adequate server privacy. --=20 Christian Huitema --------------40645E993AB6B0D3370E252C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 8/12/2017 10:14 PM, joel jaeggli wrote:

On 8/9/17 20:33, Ian Swett wrote:

In Prague, we decided that the 5-tuple couldn't change during the
handshake, but we didn't say that a 5-tuple indicated a single QUIC
connection.

For IPv6, a flow label can be used to spread load.  From my perspective,
the goal here is to allow multiple QUIC connections to share a 5-tuple,
not to recommend it for all use cases.  For example, it may make sense
to preclude it for HTTP over QUIC clients?

Flow labels are known to change during handshakes...

Source / dest and flow label is not at lot of entropy , esp if the
latter happens to be zero.
Not to mention that there is hardly any cross-platform API to set or view flow labels on IPv6/UDP packets, and that we may also want a solution for IPv6.

I would personally prefer a symmetric solution, in which the Server Clear Text packets are labelled with the initial Connection ID chosen by the client. If the server wants to change that, it could include a proposed connection ID as a parameter -- maybe as a transport parameter in the TLS extension.

One of the really neat features of Quic is that a server can listen for multiple connections on a single UDP socket. This reduce the overhead of select or poll calls, because there is just one system interface to manage. I would like to be able to do exactly the same for clients. Maybe not a huge deal in HTTP/Web scenarios, but rather useful in proxy scenarios, such as for example DNS resolvers.

Also, I would like to be able to support server mobility in the same manner as client mobility, and with adequate server privacy.
-- 
Christian Huitema
--------------40645E993AB6B0D3370E252C-- From nobody Mon Aug 14 09:43:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6691323AE for ; Mon, 14 Aug 2017 09:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=j6gaWQY+; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HtttpFYH Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xleE4dg35YKi for ; Mon, 14 Aug 2017 09:43:39 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDB1F120713 for ; Mon, 14 Aug 2017 09:43:38 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7EGh3bv005030; Mon, 14 Aug 2017 09:43:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=TdRd5AFF3gdrXGi00kbFrfnx8t5+TdMpV97XU98VyXc=; b=j6gaWQY+nFfgwMEfNrJ7z7QSEVBkO8Quvr/1eDCGMU9x61VdJh8GqVXiq9kiiK7+mCem qi1VbMq5gh1q0IWhltkEoIljUWtOk7LRnzaBUv6KX1u0Tls1fEt2e5zWYUDkEknrcRJq 2HJozP0b/OF2oKHmWqn7FgGyf5LuvyFtb+I= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cbe1yrcqf-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Aug 2017 09:43:38 -0700 Received: from NAM01-SN1-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.319.2; Mon, 14 Aug 2017 09:43:36 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TdRd5AFF3gdrXGi00kbFrfnx8t5+TdMpV97XU98VyXc=; b=HtttpFYHVl+oNcjIz9G2CP6HIdbR7bK7lf19+q00AanX1SEbcdSTs2yD5Loql/WU07CdXe71oqIuxf8r5OcxJZy99ZUKlYy+Rj6FIk2TQbaxjDHwbiHQ5o7zU7D3FopRAoYA0Guu02iEN0bOjsJitsnpkQ7p0iy3Ua9NvE7tAs0= 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.1.1341.21; Mon, 14 Aug 2017 16:43:35 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1341.020; Mon, 14 Aug 2017 16:43:35 +0000 From: Subodh Iyengar To: Ian Swett CC: "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK4= Date: Mon, 14 Aug 2017 16:43:34 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::1:e8da] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 20:hP2cWcklbGkjUfTToiTK/WBy1WDnaoQC6SVL/Xxv+fGbKahH4k6YpYBZW6KGgzyjJ7CzYGX/GwchuyOHzg6vy3DMoBpgXBwHujs6u9XqAiKr9jExKUm2og8rDAX2W/fJeCsvHQ6UhxwqmbyutOshW1yZ6Txmk3HNT2DxFtpNhK8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 686a37ef-13b1-4840-03be-08d4e3339b0b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1453; x-ms-traffictypediagnostic: MWHPR15MB1453: x-exchange-antispam-report-test: UriScan:(67672495146484)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(920507026)(6041248)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1453; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(51444003)(189002)(377454003)(2900100001)(34040400001)(7736002)(53936002)(6246003)(50986999)(4326008)(76176999)(54356999)(6436002)(8676002)(5660300001)(229853002)(3280700002)(101416001)(2950100002)(3660700001)(33656002)(6116002)(2906002)(8936002)(102836003)(6916009)(77096006)(14454004)(19627405001)(81166006)(81156014)(6506006)(74316002)(106356001)(105586002)(110136004)(68736007)(25786009)(9686003)(99286003)(54896002)(53546010)(478600001)(189998001)(236005)(55016002)(7696004)(86362001)(97736004); 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14556468FF89D60F376CAEBDB68C0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 16:43:34.8860 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1453 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_15:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 16:43:41 -0000 --_000_MWHPR15MB14556468FF89D60F376CAEBDB68C0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ya I think the language in the draft could be a bit more clear, will send o= ut a PR soon. However I have a few more questions that came up: 1. Is FIN not subject to flow control? It seems logical to not subject i= t to flow control, but it's a super weird edge case since FIN has it's own = offset :) 2. Is it max data or max offset. For example if I send you maxData =3D 1= 0, can you send until offset 9 or offset 10. I think you mean offset 9. Subodh ________________________________ From: Ian Swett Sent: Friday, July 28, 2017 9:57:23 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar > wrote: The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Yes, that's what the spec means. I thought it was fairly clear, but if you= think it's confusing, a PR to improve the wording would be appreciated. Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR15MB14556468FF89D60F376CAEBDB68C0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ya I think the language in the draft could be a bit more clear, will sen= d out a PR soon.


However I have a few more questions that came up:

  1. Is FIN not subject to flow control? It seems logical to not subject it = to flow control, but it's a super weird edge case since FIN has it's own of= fset :)
  2. Is it max data or max offset. For example if I send yo= u maxData =3D 10, can you send until offset 9 or offset 10. I think you mea= n offset 9.


Subodh

From: Ian Swett <ianswet= t@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: flow control description in draft
 


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

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

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max offset on a stream


Yes, that's what the spec means.  I thought it was fairly clear, = but if you think it's confusing, a PR to improve the wording would be appre= ciated.
 

Let's say the conn flow control limit of the receiver is 50. All units i= n multiples of 1024.

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

stream3 -->  [0, 20]


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]


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


MAX_DATA =3D 10

or

MAX_DATA =3D 60


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


Subodh



--_000_MWHPR15MB14556468FF89D60F376CAEBDB68C0MWHPR15MB1455namp_-- From nobody Mon Aug 14 09:49:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F041323A5 for ; Mon, 14 Aug 2017 09:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zqj19KoC4u1n for ; Mon, 14 Aug 2017 09:49:50 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7DB120713 for ; Mon, 14 Aug 2017 09:49:49 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id p68so58374643ywg.0 for ; Mon, 14 Aug 2017 09:49:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HhPThT93MSJjA6nGgs4XWWHr7mDB6agqqOaxE7Fd9gg=; b=U6Zgsbnj9YYCq+lCb6j6UqpqMs5fBtKMlruDFfe3lFFwt8Ryz2HNoip74dnzhp+aRf grBnzd/BADDmrrATSxwRDf5cdjB43fMytvkpFKFIYqvtEhwq8/wpur+S2nsB8ojiErz7 MP0xZyiuXMkF8QKJ5Z+QD4bGpHlqLu00phax9tkeNui4w/yHbY4jskbwOKYHkBGTiIHa 3zGZxVYnccnRK0pzLbEn65uL3Q3XIWIBg2WrhEsCp6IUwjtYk46DEOXl0c9NJ5bhaxh4 ZF++7ZQmjN23gfH4ODxaAvFJI68Ev4Ko99jtiPlz58QhJYSUSDNQrYGX+RjXn4B/t2ze xkig== 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=HhPThT93MSJjA6nGgs4XWWHr7mDB6agqqOaxE7Fd9gg=; b=W6njyunh2LVRU8xUGU7b9XkVe3SRbwcvNaQ9nAeFinDpzXsdCexzMC79f7XIcxNcYS KpgcdSsOvayMavh9unnUipoOFsMG983I75M+LXphj0Ji6LwY97JG4YzovWxLr51jkEwY njOon0+V+eYgwkWy8qDTidvXQ0wH6Y7qzXn1+Pk9dmoG7btdOiulPtT9LJw5c163+1Ta ZWGa47rzdK3DTDALGsTdisxso0DJgaaglVgCtOy2azpqi8t0sq9ITniWExbk0Cs+xjqE 7f/lG6EpXeoIEuXa15n+WjNPh/tQn8WYv/ZEp1B3HFApkNysNjeKYp02App+HCnet6FO 3wxA== X-Gm-Message-State: AHYfb5hKh6iSRcJwtATkP2LyozB7xCoBsqaG2EUXz8t6GvoNSkoCryUo U/KM9IiaD0pzaiGX2IYAu3e/k/omgNsKJKY= X-Received: by 10.129.128.198 with SMTP id q189mr19891736ywf.298.1502729389014; Mon, 14 Aug 2017 09:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Mon, 14 Aug 2017 09:49:28 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Mon, 14 Aug 2017 12:49:28 -0400 Message-ID: Subject: Re: flow control description in draft To: Subodh Iyengar Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c030c186d9c700556b973b4" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Aug 2017 16:49:52 -0000 --94eb2c030c186d9c700556b973b4 Content-Type: text/plain; charset="UTF-8" On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar wrote: > Ya I think the language in the draft could be a bit more clear, will send > out a PR soon. > > > However I have a few more questions that came up: > > 1. Is FIN not subject to flow control? It seems logical to not subject > it to flow control, but it's a super weird edge case since FIN has it's own > offset :) > > A fin is not subject to flow control. I guess I think of it taking up no space, so it doesn't seem like a problem, but I can see your point. > > 1. Is it max data or max offset. For example if I send you maxData = > 10, can you send until offset 9 or offset 10. I think you mean offset 9. > > > Good point, that seems worth clarifying. > Subodh > > ------------------------------ > *From:* Ian Swett > *Sent:* Friday, July 28, 2017 9:57:23 AM > *To:* Subodh Iyengar > *Cc:* quic@ietf.org > *Subject:* Re: flow control description in draft > > > > On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote: > >> The flow control language in the draft is a bit confusing right now, and >> I could use a bit more clarity on the intention >> >> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as >> >> "A 64-bit unsigned integer indicating the maximum amount of data that can >> be sent on the entire connection, in units of 1024 octets. That is, the >> updated connection-level data limit is determined by multiplying the >> encoded value by 1024." >> >> This seems like it means that flow control is advertised in terms of >> number of bytes that you can send from that moment. >> > >> However from the Flow control section: >> >> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to >> advertise additional credit by sending the absolute byte offset in the >> connection or stream which it is willing to receive." >> >> I think that we definitely mean offset here in both cases, i.e. >> >> MAX_DATA = sum of max offset of all streams that are allowed >> >> MAX_STREAM_DATA = max offset on a stream >> >> >> Yes, that's what the spec means. I thought it was fairly clear, but if > you think it's confusing, a PR to improve the wording would be appreciated. > > >> Let's say the conn flow control limit of the receiver is 50. All units in >> multiples of 1024. >> >> initial state of receiver >> stream1 --> [0, 10] >> stream2 --> [0, 20] >> >> stream3 --> [0, 20] >> >> >> So the sender has consumed his entire flow control window. Then the >> receiver consumes 10 (*1024) bytes from stream1: >> >> stream1 ---> (10, 10) >> >> stream2 ---> [0, 20] >> >> stream3 ---> [0, 20] >> >> >> so now the conn window has 10 (*1024) bytes remaining, what does the >> receiver send in their update: >> >> >> MAX_DATA = 10 >> >> or >> >> MAX_DATA = 60 >> >> >> I think we mean 60 here. It makes it much easier to maintain the flow >> control in that case. >> >> >> Subodh >> >> >> > --94eb2c030c186d9c700556b973b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <subodh@fb.com> wr= ote:

Ya I think the language in the draft could be a bit more clear, will sen= d out a PR soon.


However I have a few more questions that came up:

  1. Is FIN not subject to flow control? It seems logical to not subject it = to flow control, but it's a super weird edge case since FIN has it'= s own offset :)

A fin= is not subject to flow control.=C2=A0 I guess I think of it taking up no s= pace, so it doesn't seem like a problem, but I can see your point.
=C2=A0
  1. Is=C2=A0it max data or max offset. For exampl= e if I send you maxData =3D 10, can you send until offset 9 or offset 10. I= think you mean offset 9.


Good point, that seems worth clari= fying.=C2=A0

Subodh

From: = Ian Swett <ians= wett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft
=C2=A0


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

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

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max offset on a stream


Yes, that's what the spec means.=C2=A0 I thought it was fairly cle= ar, but if you think it's confusing, a PR to improve the wording would = be appreciated.
=C2=A0

Let's say the conn flow control limit of the receiver is 50. All uni= ts in multiples of 1024.

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

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


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]


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


MAX_DATA =3D 10

or

MAX_DATA =3D 60


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


Subodh




--94eb2c030c186d9c700556b973b4-- From nobody Mon Aug 14 11:25:11 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 32BB81200F3; Mon, 14 Aug 2017 11:25:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mnot@mnot.net, quic@ietf.org, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Meeting Session Request for IETF 100 X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150273510916.379.6865838393410848052.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 11:25:09 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 18:25:09 -0000 A new meeting session request has just been submitted by Mark Nottingham, a Chair of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 175 Conflicts to Avoid: First Priority: tsvarea tsvwg httpbis tls dispatch Second Priority: iccrg irtfopen mptcp saag maprg Third Priority: hrpc People who must be present: Mark Nottingham Patrick R. McManus Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days if possible; 2 hour slot(s) fine too, if that makes it easier. --------------------------------------------------------- From nobody Mon Aug 14 12:18:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D6513240F for ; Mon, 14 Aug 2017 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=ETXuvpNI; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=MLNCmdNX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwzWKqir7hIk for ; Mon, 14 Aug 2017 12:18:18 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2EC8132413 for ; Mon, 14 Aug 2017 12:18:18 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7EJEACQ032495; Mon, 14 Aug 2017 12:18:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=lTjMX/oYVdLAl6Cskt4dTVqbW7IRtP3NtlejsYn7cQ0=; b=ETXuvpNIIUKxjn2tJyOKmAtuE7V59m00zWJBeVOp5sBb2YrFCCn9zWrIim85YvkkiB0B HNI+IqTgSUJbnsiv0kKOVYe0gJ0ZQCFEI0zTH+OP78nI+BWxcsKkL5+5MEBck8tlp8m6 QNpeLW8p4QaW1Cnpv5/VoBzCaAnLi/TTXC0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cbg6a8e2s-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Aug 2017 12:18:15 -0700 Received: from NAM01-BY2-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.319.2; Mon, 14 Aug 2017 12:18:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lTjMX/oYVdLAl6Cskt4dTVqbW7IRtP3NtlejsYn7cQ0=; b=MLNCmdNXBxqT0nw797RX2CGHtbfA1kFwz+Nn8RKUTFP01oG3DuD9bVS9nGal43ixqam6SA7dRaz9rnLxlmWyuMxRCbe+JW22sjICG46DFl+o1lVkhQBbzS4gZaX0gQD7zXkXJW4qYN3qUMqKzaaxxMN8XNQCQTIVHE1ZJ/v4eII= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.21; Mon, 14 Aug 2017 19:18:00 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1341.020; Mon, 14 Aug 2017 19:18:00 +0000 From: Subodh Iyengar To: Ian Swett CC: "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgL Date: Mon, 14 Aug 2017 19:17:59 +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::7:81a4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 20:nNvtnk88klwErl/O8lfKo1hEv2WXAKJIKjeafSsjMUiRbBaLfAOZLYcdM45Yr5JNMVUTCT0ulfovoa68OtH+jLnTuPiYLwXPj5A5xIgGb0UyUpGTzhJU+PM0vEmLS7Hs4qLEV9GA5b0cQXNR51ZtBubUYG2n+0uQqwXg2mf2L40= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ec9b96ad-09e7-4b44-dbb1-08d4e3492d6b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-exchange-antispam-report-test: UriScan:(166708455590820)(67672495146484)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(920507026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1455; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(199003)(24454002)(51444003)(189002)(5660300001)(229853002)(2906002)(2900100001)(4326008)(189998001)(81156014)(6116002)(3660700001)(7696004)(102836003)(7736002)(8676002)(77096006)(97736004)(81166006)(8936002)(3280700002)(2950100002)(6506006)(6916009)(6436002)(50986999)(54356999)(76176999)(53546010)(606006)(106356001)(478600001)(966005)(14454004)(25786009)(33656002)(105586002)(101416001)(74316002)(34040400001)(55016002)(99286003)(93886004)(236005)(86362001)(110136004)(19627405001)(6246003)(9686003)(54896002)(68736007)(53936002)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455CB491602B34D35AD17E2B68C0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 19:17:59.8212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_17:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:18:21 -0000 --_000_MWHPR15MB1455CB491602B34D35AD17E2B68C0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ya the complexity of not having FIN as subject to flow control is that the = stream frame scheduler would have special logic for processing FINs while c= hecking whether it has flow control. This wouldn't be an editorial issue th= ough and is more of a design issue. I've put up a PR for the design change,= if people don't like the change I can put up a PR for only the editorial c= hange instead keeping the current semantics: https://github.com/quicwg/base-drafts/pull/730 Subodh ________________________________ From: QUIC on behalf of Ian Swett Sent: Monday, August 14, 2017 9:49:28 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar > wrote: Ya I think the language in the draft could be a bit more clear, will send o= ut a PR soon. However I have a few more questions that came up: 1. Is FIN not subject to flow control? It seems logical to not subject i= t to flow control, but it's a super weird edge case since FIN has it's own = offset :) A fin is not subject to flow control. I guess I think of it taking up no s= pace, so it doesn't seem like a problem, but I can see your point. 1. Is it max data or max offset. For example if I send you maxData =3D 1= 0, can you send until offset 9 or offset 10. I think you mean offset 9. Good point, that seems worth clarifying. Subodh ________________________________ From: Ian Swett > Sent: Friday, July 28, 2017 9:57:23 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar > wrote: The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Yes, that's what the spec means. I thought it was fairly clear, but if you= think it's confusing, a PR to improve the wording would be appreciated. Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR15MB1455CB491602B34D35AD17E2B68C0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ya the complexity of not having FIN as subject to flow control is that t= he stream frame scheduler would have special logic for processing FINs whil= e checking whether it has flow control. This wouldn't be an editorial issue= though and is more of a design issue. I've put up a PR for the design change, if people don't like the ch= ange I can put up a PR for only the editorial change instead keeping the cu= rrent semantics:


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


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Ian Swett <ianswett@google.com>
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: flow control description in draft
 
On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar= <subodh@fb.com>= ; wrote:

Ya I think the language in the draft could be a bit more clear, will sen= d out a PR soon.


However I have a few more questions that came up:

  1. Is FIN not subject to flow control? It seems logical to not subject it = to flow control, but it's a super weird edge case since FIN has it's own of= fset :)

A fin is not subject to flow control.  I guess I think of it taki= ng up no space, so it doesn't seem like a problem, but I can see your point= .
 
  1. Is it max data or max offset. For example if I send you maxData = =3D 10, can you send until offset 9 or offset 10. I think you mean offset 9= .


Good point, that seems worth clarifying. 

Subodh

From: = Ian Swett <ians= wett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft
 


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

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

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max offset on a stream


Yes, that's what the spec means.  I thought it was fairly clear, = but if you think it's confusing, a PR to improve the wording would be appre= ciated.
 

Let's say the conn flow control limit of the receiver is 50. All units i= n multiples of 1024.

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

stream3 -->  [0, 20]


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]


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


MAX_DATA =3D 10

or

MAX_DATA =3D 60


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


Subodh




--_000_MWHPR15MB1455CB491602B34D35AD17E2B68C0MWHPR15MB1455namp_-- From nobody Mon Aug 14 12:31:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21EC413240E for ; Mon, 14 Aug 2017 12:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 vmHClPzYyXjL for ; Mon, 14 Aug 2017 12:31:45 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0135.outbound.protection.outlook.com [104.47.38.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C3F813240F for ; Mon, 14 Aug 2017 12:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aiYixbAwk2j7XUdZkxYENehYDbokX0PTOn3xf+/h4MQ=; b=EWpObRceinVNC/WfMhC5Fbp60RhUWAU5048tpiys55ac3an7OA7u6qPJ6r2oMa5muxuplB2Nfk2R7nf5OO9pDqSfzMHYQttoly/4BilIwcZWF+njGw1o1lhA9G22e45ZG5/lnEC6GRkVrR8LT46lMgUnxO4Wi+uCaPTcnc9pY/o= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0703.namprd21.prod.outlook.com (10.175.142.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.0; Mon, 14 Aug 2017 19:31:42 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1385.000; Mon, 14 Aug 2017 19:31:42 +0000 From: Mike Bishop To: Subodh Iyengar , Ian Swett CC: "quic@ietf.org" Subject: RE: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/A= Date: Mon, 14 Aug 2017 19:31:41 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2::263] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0703; 6:sJ7yxlkLIC58J9KktEe24PD5xPHKuhrsL0b/e/MUuCxu9f/YuZqHbvWgkQzqoEgCitVxcOmXDNLjxnaN6dC3/Ywljpcled7LuPDod2agskvipZKrzS5+tGwcU6BfV23GRbtsHHJeFQqRpPYWqJZa6KQQaqihpVPUxl/XXnm4goq2ctCWg6s4O2lD3bV+1qyvvouHbfuqjkTA6XF3bAda7/1ckagCgR89kQuh8yFpojapSu48T8YYZ6ffTfOWVpaYLpkX1CwToDZA9sEuV61gD1efYACiPralYmGVbXS7RekgJsvHXnDANjx/pwgHfcxQrS7FKa0seZUpXfpvcYadWw==; 5:RO9Hs/7I07D31JpCHtqSl+oHrYXgfssfefoqgEFgZpkam60kWf1q1UXO2+ZL6xJ2VGG6mI7vdPNzM8gHxDyE9h7AZ9hTSSrgWWOyfUFnjJCAGwawWeYN9tT3TOEJuoK+VqiuYS2jJz6rEfF0XO62qg==; 24:X3j9ozbGM8WsBXZsovp9rgli95fNIT0XYjBwzqdSLbH17R/jNwg8io6lA5YibgOScOikZR/SxJ290fYC/1W+WNjQLKMD99FZeK/dQ52TaYs=; 7:jP3oqTJTDqYtUB8uyOpSQEZt6QgBIecCfub47O15v21XqnI+eJn+nGbE4CevupUXORkclo4ttC9H5sFxgm0rzLFge+a0sIy4UdyLBr4runPDMcipy3TlrhSK+YS9vO/J4Ac8TJJpoMxxGRYGpvMiE9OMFPR17jDUTLUNA8aX/qgZqIp8jkAD/Jns8qzT44eEj2jNBacjB+G4hBELAESte+lNWY6z6vN7v/uPH75IJRc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: edd67807-6b20-46d7-5cd5-08d4e34b17d0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603142)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0703; x-ms-traffictypediagnostic: MWHPR21MB0703: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(67672495146484)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(920507026)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0703; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0703; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(51444003)(199003)(189002)(24454002)(377454003)(478600001)(101416001)(76176999)(4326008)(5660300001)(236005)(93886004)(54356999)(6506006)(97736004)(25786009)(8676002)(10290500003)(86362001)(77096006)(53546010)(9686003)(606006)(6246003)(7696004)(53936002)(19609705001)(6306002)(74316002)(54896002)(55016002)(34040400001)(2900100001)(50986999)(99286003)(105586002)(86612001)(68736007)(2906002)(14454004)(2950100002)(72206003)(106356001)(8936002)(10090500001)(966005)(8990500004)(5005710100001)(3660700001)(3280700002)(81166006)(229853002)(81156014)(7736002)(790700001)(6116002)(33656002)(102836003)(189998001)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0703; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB014117ADA56FA46D1719E9F0878C0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 19:31:42.4228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0703 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Aug 2017 19:31:49 -0000 --_000_MWHPR21MB014117ADA56FA46D1719E9F0878C0MWHPR21MB0141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Like Ian, I don't see this as an issue - assuming everything is rationalize= d around offsets, the check is always whether (current offset) + (payload l= ength) <=3D (allowed offset). Even if (current offset) =3D=3D (allowed off= set), a STREAM frame that contains only a FIN will have a payload length of= zero, so this will still be true. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar Sent: Monday, August 14, 2017 12:18 PM To: Ian Swett Cc: quic@ietf.org Subject: Re: flow control description in draft Ya the complexity of not having FIN as subject to flow control is that the = stream frame scheduler would have special logic for processing FINs while c= hecking whether it has flow control. This wouldn't be an editorial issue th= ough and is more of a design issue. I've put up a PR for the design change,= if people don't like the change I can put up a PR for only the editorial c= hange instead keeping the current semantics: https://github.com/quicwg/base-drafts/pull/730 Subodh ________________________________ From: QUIC > on behalf = of Ian Swett > Sent: Monday, August 14, 2017 9:49:28 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar > wrote: Ya I think the language in the draft could be a bit more clear, will send o= ut a PR soon. However I have a few more questions that came up: 1. Is FIN not subject to flow control? It seems logical to not subject i= t to flow control, but it's a super weird edge case since FIN has it's own = offset :) A fin is not subject to flow control. I guess I think of it taking up no s= pace, so it doesn't seem like a problem, but I can see your point. 1. Is it max data or max offset. For example if I send you maxData =3D 1= 0, can you send until offset 9 or offset 10. I think you mean offset 9. Good point, that seems worth clarifying. Subodh ________________________________ From: Ian Swett > Sent: Friday, July 28, 2017 9:57:23 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar > wrote: The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Yes, that's what the spec means. I thought it was fairly clear, but if you= think it's confusing, a PR to improve the wording would be appreciated. Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR21MB014117ADA56FA46D1719E9F0878C0MWHPR21MB0141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Like Ian, I don’t see this as an issue –= assuming everything is rationalized around offsets, the check is always wh= ether (current offset) + (payload length) <=3D (allowed offset).&nbs= p; Even if (current offset) =3D=3D (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will = still be true.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <ianswett@google.com>
Cc: quic@ietf.org
Subject: Re: flow control description in draft

 

Ya the complexity of not ha= ving FIN as subject to flow control is that the stream frame scheduler woul= d have special logic for processing FINs while checking whether it has flow= control. This wouldn't be an editorial issue though and is more of a design issue. I've put up a PR for the desig= n change, if people don't like the change I can put up a PR for only the ed= itorial change instead keeping the current semantics:

 

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

 

Subodh

From: QUIC <q= uic-bounces@ietf.org> on behalf of Ian Swett <ianswett@google.com>
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: flow control description in draft

 

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <= ;subodh@fb.com> w= rote:

Ya I think the language in = the draft could be a bit more clear, will send out a PR soon.

 

However I have a few more q= uestions that came up:

  1. Is FIN not subject to flow control? It see= ms logical to not subject it to flow control, but it's a super weird edge c= ase since FIN has it's own offset :)

 

A fin is not subject to flow control.  I guess = I think of it taking up no space, so it doesn't seem like a problem, but I = can see your point.

 

  1. Is it max data or max offset. For exa= mple if I send you maxData =3D 10, can you send until offset 9 or offset 10= . I think you mean offset 9.

 

Good point, that seems worth clarifying. <= /o:p>

Subodh

From: Ian Swett <ianswett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft

 

 

 

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

The flow control language i= n the draft is a bit confusing right now, and I could use a bit more clarit= y on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max off= set on a stream

 

Yes, that's what the spec means.  I thought it = was fairly clear, but if you think it's confusing, a PR to improve the word= ing would be appreciated.

 

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

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

stream3 -->  [0, 20= ]


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

 

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

 

MAX_DATA =3D 10<= /span>

or

MAX_DATA =3D 60<= /span>

 

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

 <= /p>

Subodh

 

 

--_000_MWHPR21MB014117ADA56FA46D1719E9F0878C0MWHPR21MB0141namp_-- From nobody Mon Aug 14 12:50:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A0313241F for ; Mon, 14 Aug 2017 12:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=S/KKzz+D; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=HVAOG6XK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdXlhFFvBXyN for ; Mon, 14 Aug 2017 12:50:02 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B91D1323D4 for ; Mon, 14 Aug 2017 12:50:02 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7EJmmI5028397; Mon, 14 Aug 2017 12:50:00 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=6rMIo0e8WMcHTw2cvAIWDYXpxXwhN+yHEplL72RtNTs=; b=S/KKzz+Dq9GoHWK0ZNeVQjjt5k9R2T0LOBh/hT17uELbzUjJvBpyNOqokEE7IxpWIqVu lRnGCi6DOHTnCWIDJVStt0K+xNPQi+Grcre1jF3UPJwMFQf0mBH2d7dFrjwtY8/gbqEa XhPv55CQeJ2AYhS46eyq370AXYyyfHbHBsk= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cbhngr5j1-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Aug 2017 12:50:00 -0700 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 Aug 2017 12:49:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6rMIo0e8WMcHTw2cvAIWDYXpxXwhN+yHEplL72RtNTs=; b=HVAOG6XKOLObtBNge/q2t5sTh89A4i2VfU44WGNo1wCg9Ya+hg2t5B8GfsMqu3fcZlpgVhwVzU7u8eKbR/XG/65DGwcmh5gDsQOcoV5BCMYvlkERVdU+d6LwWl8a0Ps44RLqEWU93VuniKgZomqbmDFkpxCZhQBKYkjBSoc1yy8= 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.1.1341.21; Mon, 14 Aug 2017 19:49:57 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1341.020; Mon, 14 Aug 2017 19:49:57 +0000 From: Subodh Iyengar To: Mike Bishop , Ian Swett CC: "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/CAAAXE8Q== Date: Mon, 14 Aug 2017 19:49: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::5:78c3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 20:teLq43reilry5HfClxa2NZewAxZp4BKRgRGspmTYBg3rq1/Ip4+wGmpkxi5+pswGnEx+5RHw6qyWf+fgrTemOJTJxtQgt6VuPl+DpHSQVYobS4gCw6ZCXOTNJlaydvuyLlAbEfenk9lI4CTBtPOsdjy97Mx0QW/vOaGGcbrRcS8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8597d342-d3a2-4628-448b-08d4e34da496 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1454; x-ms-traffictypediagnostic: MWHPR15MB1454: x-exchange-antispam-report-test: UriScan:(10436049006162)(89211679590171)(166708455590820)(189930954265078)(67672495146484)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(920507026)(6041248)(20161123560025)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1454; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51444003)(76104003)(189002)(199003)(24454002)(790700001)(966005)(2561002)(93886004)(74316002)(53936002)(4326008)(25786009)(5660300001)(53546010)(606006)(6436002)(102836003)(1511001)(86362001)(6116002)(2906002)(478600001)(3660700001)(6506006)(19627405001)(2950100002)(229853002)(3280700002)(6246003)(2900100001)(7736002)(76176999)(50986999)(33656002)(54356999)(45080400002)(189998001)(2421001)(68736007)(7696004)(8666007)(101416001)(54896002)(8936002)(55016002)(8676002)(584604001)(99286003)(14454004)(9686003)(236005)(77096006)(81166006)(97736004)(6306002)(81156014)(34040400001)(105586002)(106356001); 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB14551AA15C9B617BD95C7999B68C0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 19:49:57.7974 (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-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_17:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 19:50:05 -0000 --_000_MWHPR15MB14551AA15C9B617BD95C7999B68C0MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable @Mike ya another issue I brought up is that it's actually not rationalized = around offsets right now, the current formulation is around maximum data wh= ich is what raised the question of FINs. The PR changes the formulation to = be around offsets. This is discussed in the PR summary. Let me know what yo= u think. Subodh ________________________________ From: Mike Bishop Sent: Monday, August 14, 2017 12:31:41 PM To: Subodh Iyengar; Ian Swett Cc: quic@ietf.org Subject: RE: flow control description in draft Like Ian, I don=92t see this as an issue =96 assuming everything is rationa= lized around offsets, the check is always whether (current offset) + (paylo= ad length) <=3D (allowed offset). Even if (current offset) =3D=3D (allowed= offset), a STREAM frame that contains only a FIN will have a payload lengt= h of zero, so this will still be true. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar Sent: Monday, August 14, 2017 12:18 PM To: Ian Swett Cc: quic@ietf.org Subject: Re: flow control description in draft Ya the complexity of not having FIN as subject to flow control is that the = stream frame scheduler would have special logic for processing FINs while c= hecking whether it has flow control. This wouldn't be an editorial issue th= ough and is more of a design issue. I've put up a PR for the design change,= if people don't like the change I can put up a PR for only the editorial c= hange instead keeping the current semantics: https://github.com/quicwg/base-drafts/pull/730 Subodh ________________________________ From: QUIC > on behalf = of Ian Swett > Sent: Monday, August 14, 2017 9:49:28 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar > wrote: Ya I think the language in the draft could be a bit more clear, will send o= ut a PR soon. However I have a few more questions that came up: 1. Is FIN not subject to flow control? It seems logical to not subject i= t to flow control, but it's a super weird edge case since FIN has it's own = offset :) A fin is not subject to flow control. I guess I think of it taking up no s= pace, so it doesn't seem like a problem, but I can see your point. 1. Is it max data or max offset. For example if I send you maxData =3D 1= 0, can you send until offset 9 or offset 10. I think you mean offset 9. Good point, that seems worth clarifying. Subodh ________________________________ From: Ian Swett > Sent: Friday, July 28, 2017 9:57:23 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar > wrote: The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Yes, that's what the spec means. I thought it was fairly clear, but if you= think it's confusing, a PR to improve the wording would be appreciated. Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR15MB14551AA15C9B617BD95C7999B68C0MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

@Mike ya another issue I brought up is that it's actually not rationaliz= ed around offsets right now, the current formulation is around maximum data= which is what raised the question of FINs. The PR changes the formulation = to be around offsets. This is discussed in the PR summary. Let me know what you think.


Subodh

From: Mike Bishop <Micha= el.Bishop@microsoft.com>
Sent: Monday, August 14, 2017 12:31:41 PM
To: Subodh Iyengar; Ian Swett
Cc: quic@ietf.org
Subject: RE: flow control description in draft
 

Like Ian, I don=92t see this as an issue =96 assumin= g everything is rationalized around offsets, the check is always whether (c= urrent offset) + (payload length) <=3D (allowed offset).  Even = if (current offset) =3D=3D (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will = still be true.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <ianswett@google.com>
Cc: quic@ietf.org
Subject: Re: flow control description in draft

 

Ya the complexity of not ha= ving FIN as subject to flow control is that the stream frame scheduler woul= d have special logic for processing FINs while checking whether it has flow= control. This wouldn't be an editorial issue though and is more of a design issue. I've put up a PR for the desig= n change, if people don't like the change I can put up a PR for only the ed= itorial change instead keeping the current semantics:

 

https:/= /github.com/quicwg/base-drafts/pull/730

 

Subodh

From: QUIC <q= uic-bounces@ietf.org> on behalf of Ian Swett <ianswett@google.com>
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: quic@ietf.org
Subject: Re: flow control description in draft

 

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <= ;subodh@fb.com> w= rote:

Ya I think the language in = the draft could be a bit more clear, will send out a PR soon.

 

However I have a few more q= uestions that came up:

  1. Is FIN not subject to flow control? It see= ms logical to not subject it to flow control, but it's a super weird edge c= ase since FIN has it's own offset :)

 

A fin is not subject to flow control.  I guess = I think of it taking up no space, so it doesn't seem like a problem, but I = can see your point.

 

  1. Is it max data or max offset. For exa= mple if I send you maxData =3D 10, can you send until offset 9 or offset 10= . I think you mean offset 9.

 

Good point, that seems worth clarifying. <= /o:p>

Subodh

From: Ian Swett <ianswett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft

 

 

 

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

The flow control language i= n the draft is a bit confusing right now, and I could use a bit more clarit= y on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max off= set on a stream

 

Yes, that's what the spec means.  I thought it = was fairly clear, but if you think it's confusing, a PR to improve the word= ing would be appreciated.

 

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

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

stream3 -->  [0, 20= ]


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]

stream3 ---> [0, 20]

 

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

 

MAX_DATA =3D 10<= /span>

or

MAX_DATA =3D 60<= /span>

 

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

 <= /p>

Subodh

 

 

--_000_MWHPR15MB14551AA15C9B617BD95C7999B68C0MWHPR15MB1455namp_-- From nobody Mon Aug 14 14:42:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CA113243A for ; Mon, 14 Aug 2017 14:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKrm0CZv_Msz for ; Mon, 14 Aug 2017 14:42:14 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0094.outbound.protection.outlook.com [104.47.32.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B0A132431 for ; Mon, 14 Aug 2017 14:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TGja0Yw8OVz+94/uTVJ5EWvr1NnlFpNK38IYZO1Tinc=; b=IkX8hmtppMba4C5XANf+HqMN6lAeKc6ynnaGKbaQjsqsPe8UqEeYEmrv0Z8/uX6bQ4lyn9HQWYNef9ppIXU/VjUXFApIqicZG88d6f4y21bbwaZ+9RP0I6BaVubvA/0WgErtQjXuxOqkcshuPW+v9cy7lqRzbNZFlsqk78v0tHs= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0173.namprd21.prod.outlook.com (10.173.52.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.2; Mon, 14 Aug 2017 21:42:12 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1385.000; Mon, 14 Aug 2017 21:42:12 +0000 From: Mike Bishop To: "quic@ietf.org" Subject: FW: New Version Notification for draft-bishop-quic-http-and-qpack-03.txt Thread-Topic: New Version Notification for draft-bishop-quic-http-and-qpack-03.txt Thread-Index: AQHTFUV9bFpB2ybUgke+ZL4r8uXroaKEYIDg Date: Mon, 14 Aug 2017 21:42:11 +0000 Message-ID: References: <150274662295.10509.12524384733509854665.idtracker@ietfa.amsl.com> In-Reply-To: <150274662295.10509.12524384733509854665.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2::263] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0173; 6:jkl9Fzha++CtWxgmsB5DTFqr7/RXRHl5hi9kDU/ErzXJRRAE9BVlBi26Ix2fi/8wlbAPE/B60i6oEg1RYUSiVnfsG+o24WEnGD3Qh2trTmiwybFvDvjzvyFW4+D+H76jm5PHfffAJpBgnguSec5bOWIiViR2a8SU5Rh+H8BztdhHkCuf69GUUTehnidZxIZYFrmhrLVsSH6IUBfQNcboYETgGobrgMeJFEJr7hK/g2G9NpyGm3EKUzThtyA5QSEylQEHF9vQwiMmbNVKdZTvz4sMOp4ocLLv2SCaFfRdf09YLrqTZab6mJ07owLdHWZ9Y3XVIcxjMtyfQgue0CDcOA==; 5:QzsJw6Ap0Z43GYuJTeYJ63+RUSq2M1nB6/tFI0pQ1jcfIdSMH47hx5InTjPfjwlgA6k5Ms2f6HBdaCBbpOJ83fe/uDhzPTn/GBbgE0TIick2UX3kobilOfypjSSG5ugJUIsfL59iMfBXPu1EVwk3Fw==; 24:kd3YscMkxkFtquqi6WjN9ZvS6LicT3g5B2j54NYL9PnDUiKOuMX+A6kMLEh2FgFSiO68oPMnZAcKY2gzGj4mpQAxGfMWi/ldlkjqBIQ676E=; 7:u9W5HZN8e0FirOY6IMEXgZgee0DAZPLu/aR/YDeHwNMzUL2RSvNNWjpWHhr7sP/GCMOteT5DIaiIkowgbM9jfC900uV/WgEX9H/B8jvJDwVSR8IaGwSugmVzJgimjkkGjTGsB6gdGRbkRTl3R3Y432OiMQcozlFW8Nh5PIkXbujn23oi5JzhjgtrNnaKojVuQnmfV6LgJY3XcBzFlN/RnsNSx2N1z8tKNdZ60jb5kV8= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 142dff5b-8311-4998-1c21-08d4e35d528e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603142)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0173; x-ms-traffictypediagnostic: MWHPR21MB0173: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0173; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0173; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(377424004)(13464003)(377454003)(189002)(199003)(25786009)(3660700001)(8990500004)(10290500003)(15650500001)(3280700002)(2501003)(5005710100001)(10090500001)(54356999)(72206003)(97736004)(14454004)(76176999)(50986999)(966005)(2906002)(68736007)(53546010)(189998001)(478600001)(230783001)(110136004)(105586002)(305945005)(2351001)(6916009)(2950100002)(7736002)(8936002)(229853002)(106356001)(53936002)(101416001)(99286003)(86362001)(86612001)(561944003)(9686003)(6116002)(6306002)(2473003)(55016002)(102836003)(74316002)(6506006)(5640700003)(33656002)(2900100001)(7696004)(6436002)(77096006)(8676002)(81156014)(1730700003)(81166006)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0173; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 21:42:11.9310 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0173 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 21:42:16 -0000 TGltaXRlZCBjaGFuZ2VzIGluIHRoaXMgdmVyc2lvbiAtLSBtb3N0bHkgc3VibWl0dGVkIGJlY2F1 c2UgdGhlIHByZXZpb3VzIGRyYWZ0IGhhZCB0aW1lZCBvdXQuDQoNCktleSBkaWZmZXJlbmNlczoN CiAgLSBJIGdldCB0aGUgaW1wcmVzc2lvbiB0aGF0IHBlb3BsZSBkb24ndCB1bmRlcnN0YW5kIGhv dyB0aGUgSG9yaXpvbiAvIFN0cmVhbSBJRCBMaXN0IHN0dWZmIHdvcmtzLCBzbyBhZGRlZCBhIGxp dHRsZSB0ZXh0IGFib3V0IGhvdyBlaXRoZXIgc2lkZSBjYW4gc2ltcGxpZnkgdGhpcyBhcyBtdWNo IGFzIHRoZXkgd2FudC4gIEhvd2V2ZXIsIEkgZmVlbCBsaWtlIHRoYXQgZG9lc24ndCBtYWtlIGl0 IHN1YnN0YW50aWFsbHkgY2xlYXJlciwgYW5kIEkgbWF5IG5lZWQgYSB0ZXh0IHByb3Bvc2FsIG9u IHRoYXQuDQogIC0gUmF0aGVyIHRoYW4gYSBzaW5nbGUgc3RyZWFtIGZvciB1cGRhdGVzLCB1c2Vz IHRoZSBzdHJlYW0tYXMtbWVzc2FnZSBhYnN0cmFjdGlvbiBhbmQgZW5hYmxlcyBtdWx0aXBsZSBo ZWFkZXIgdGFibGUgdXBkYXRlIHN0cmVhbXMgdGhhdCBkb24ndCBIT0xCIGVhY2ggb3RoZXIuICBU QkQgZXhhY3RseSBob3cgd2UgaWRlbnRpZnkgdGhvc2UgaW4gSFRUUC9RVUlDLCB0aG91Z2ggYWxt b3N0IGNlcnRhaW5seSB3aXRoIGEgc3RyZWFtIGhlYWRlciBvZiBzb21lIHNvcnQuICBUaGFua3Mg dG8gZGlzY3Vzc2lvbiB3aXRoIEJ1Y2sgYW5kIHJlbGF5ZWQgY29udmVyc2F0aW9ucyB3aXRoIFJ5 YW4gd2hpY2ggc3BhcmtlZCB0aGlzIGNoYW5nZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIEF1Z3VzdCAxNCwgMjAxNyAyOjM3IFBNDQpUbzog TWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNr LTAzLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaXNob3AtcXVpYy1odHRw LWFuZC1xcGFjay0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlr ZSBCaXNob3AgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJh ZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2sNClJldmlzaW9uOgkwMw0KVGl0bGU6CQlIZWFk ZXIgQ29tcHJlc3Npb24gZm9yIEhUVFAvUVVJQw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wOC0xNA0K R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTQNClVSTDogICAgICAgICAg ICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmludGVybmV0LWRyYWZ0cyUyRmRyYWZ0LWJpc2hvcC1x dWljLWh0dHAtYW5kLXFwYWNrLTAzLnR4dCZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0 MG1pY3Jvc29mdC5jb20lN0NjZTMyZWFkY2QzOGI0ZGY0YmU2NDA4ZDRlMzVjOWIxOCU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzYzODM0MzQyNTE5ODMyODkm c2RhdGE9aWdORWRwJTJGQ29xJTJGZ29YcmRjQTMyMzFWZUslMkZzMWQ5RHdjcmNNdEJPSktycyUz RCZyZXNlcnZlZD0wDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9y ZyUyRmRvYyUyRmRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrJTJGJmRhdGE9MDIlN0Mw MSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2NlMzJlYWRjZDM4YjRkZjRiZTY0 MDhkNGUzNWM5YjE4JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3 QzYzNjM4MzQzNDI1MTk4MzI4OSZzZGF0YT1iMCUyQmZFSGVSSnZBVHUxM1BMQWFaekxMbzZxV0I3 alZ5ZFIyQkdUZ2dqbUElM0QmcmVzZXJ2ZWQ9MA0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdG9v bHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDMm ZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDY2UzMmVhZGNk MzhiNGRmNGJlNjQwOGQ0ZTM1YzliMTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2MzgzNDM0MjUxOTgzMjg5JnNkYXRhPUJZckc1WG01TG0lMkJHNVlIU1h2 bkh3OGhqQklKWkt0QlZhRGJkJTJCczV1eExjJTNEJnJlc2VydmVkPTANCkh0bWxpemVkOiAgICAg ICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGaHRtbCUyRmRyYWZ0LWJpc2hv cC1xdWljLWh0dHAtYW5kLXFwYWNrLTAzJmRhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQw bWljcm9zb2Z0LmNvbSU3Q2NlMzJlYWRjZDM4YjRkZjRiZTY0MDhkNGUzNWM5YjE4JTdDNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjM4MzQzNDI1MTk4MzI4OSZz ZGF0YT1YbEc2T056YVdzY01CSmJNcjg0bFg0eENXWk1EVVV0Znh2OFRMaFp0TUJ3JTNEJnJlc2Vy dmVkPTANCkRpZmY6ICAgICAgICAgICBodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24u b3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRnJmY2RpZmYlM0Z1 cmwyJTNEZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2stMDMmZGF0YT0wMiU3QzAxJTdD bWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDY2UzMmVhZGNkMzhiNGRmNGJlNjQwOGQ0 ZTM1YzliMTglN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 MzgzNDM0MjUxOTgzMjg5JnNkYXRhPVNuNW5BRXc4S2I2QkxsVnQ1RVY2SldnVkwlMkJTJTJCQmhD bzNMS3NqQUVpY1lNJTNEJnJlc2VydmVkPTANCg0KQWJzdHJhY3Q6DQogICBIVFRQLzIgW1JGQzc1 NDBdIHVzZXMgSFBBQ0sgW1JGQzc1NDFdIGZvciBoZWFkZXIgY29tcHJlc3Npb24uDQogICBIb3dl dmVyLCBIUEFDSyByZWxpZXMgb24gdGhlIGluLW9yZGVyIG1lc3NhZ2UtYmFzZWQgc2VtYW50aWNz IG9mIHRoZQ0KICAgSFRUUC8yIGZyYW1pbmcgbGF5ZXIgaW4gb3JkZXIgdG8gZnVuY3Rpb24uICBN ZXNzYWdlcyBjYW4gb25seSBiZQ0KICAgc3VjY2Vzc2Z1bGx5IGRlY29kZWQgaWYgcHJvY2Vzc2Vk IGJ5IHRoZSBkZWNvZGVyIGluIHRoZSBzYW1lIG9yZGVyIGFzDQogICBnZW5lcmF0ZWQgYnkgdGhl IGVuY29kZXIuICBUaGlzIGRyYWZ0IHJlZmluZXMgSFBBQ0sgdG8gbG9vc2VuIHRoZQ0KICAgb3Jk ZXJpbmcgcmVxdWlyZW1lbnRzIGZvciB1c2Ugb3ZlciBRVUlDIFtJLUQuaWV0Zi1xdWljLXRyYW5z cG9ydF0uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQg dG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Aug 14 15:23:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F846132447 for ; Mon, 14 Aug 2017 15:23:48 -0700 (PDT) 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=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 izNoiha6dy1Z for ; Mon, 14 Aug 2017 15:23:45 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E429132431 for ; Mon, 14 Aug 2017 15:23:45 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l82so62936977ywc.2 for ; Mon, 14 Aug 2017 15:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1WRdnz3NoFM9lyj65x80nRPgfCIteTgB1Qtr6vEivj0=; b=Gd1sz3VgWzl7dml/ZgTAJPkowbKP9aHgf7KiC5xNd0AwiwSnli47VqQEFtomuYOkU1 gJ1R963lLMUlbxXN+UiQQxJ57lYsc04CRiIkzPgvHSNxd7ts+xMLb6PGPoU4zSbqQT0z BZzIKctWouO+dT033ooeAlaqHbol15aj0JfM1T7CHBINz43d163mK1b0azMkuNa/ZBZX RYw1p4T/QrayCHK50WxHMjMGr1/IIXPBLz8E3FUqzIQgX/+OXY5SCzkjaDJVxEauXZHa FJItJNhqeP6vcaQl+VJyBB7PwJrQQxhHtFYlO697+jHqOuX+mA/2EqVA1BkSCu6ScrQm b8Aw== 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=1WRdnz3NoFM9lyj65x80nRPgfCIteTgB1Qtr6vEivj0=; b=Tm+mBXRQbayDhfJEo6r+tVXTY5G7MAnf4N5zECI9M63AhJcYRron5lF+y6t1t9UV16 nSwsk4ITqBSUIiwsmYBuDIyGirCVh4lAYt9/Fk3mb7q5jJRyfVElhO+km2I0NfK23ycH 7STimOuo4qpqsHmE4i2R6HzyxKfs+0e5nBxU97J7Za5kW5TEgUC0R3oWfboUibLZ7Ciw o5xkV5tJiY7GKnv+nOSxCMcrFSW1Zth1er6vBCleexQQaQCSCNpTwwaOdkkOeAowwNwT i3mCwVmUTMvoIYQ55ydZHC0QSyWdjThK1bNEefzQL1EP9hVYXBCeGWDapfqRCXNkRpRh tEAA== X-Gm-Message-State: AHYfb5g8d+ISRvP5A5iAdRDcg3sYR8l6+XOMxbALjbAT8dgHEmtb77cm nVX+6c0o1nm0oRpsJJpRzJZyrwf07lAq X-Received: by 10.129.175.7 with SMTP id n7mr21536070ywh.279.1502749424225; Mon, 14 Aug 2017 15:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.207 with HTTP; Mon, 14 Aug 2017 15:23:43 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 14 Aug 2017 15:23:43 -0700 Message-ID: Subject: Re: flow control description in draft To: Subodh Iyengar Cc: Mike Bishop , Ian Swett , "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045eb0969ecba90556be1d79" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Aug 2017 22:23:49 -0000 --f403045eb0969ecba90556be1d79 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN does not need be included in flow control accounting. The only reason it consumes an offset is the case where it is sent on an empty STREAM frame. But this does matter for flow control since as Ian pointed out, this byte does not consume any buffer space. I'll look at the PR. On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar wrote: > @Mike ya another issue I brought up is that it's actually not rationalize= d > around offsets right now, the current formulation is around maximum data > which is what raised the question of FINs. The PR changes the formulation > to be around offsets. This is discussed in the PR summary. Let me know wh= at > you think. > > > Subodh > ------------------------------ > *From:* Mike Bishop > *Sent:* Monday, August 14, 2017 12:31:41 PM > *To:* Subodh Iyengar; Ian Swett > *Cc:* quic@ietf.org > *Subject:* RE: flow control description in draft > > > Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming everyth= ing is > rationalized around offsets, the check is always whether (current offset)= + > (payload length) <=3D (allowed offset). Even if (current offset) =3D=3D = (allowed > offset), a STREAM frame that contains only a FIN will have a payload leng= th > of zero, so this will still be true. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Subodh Iyengar > *Sent:* Monday, August 14, 2017 12:18 PM > *To:* Ian Swett > *Cc:* quic@ietf.org > *Subject:* Re: flow control description in draft > > > > Ya the complexity of not having FIN as subject to flow control is that th= e > stream frame scheduler would have special logic for processing FINs while > checking whether it has flow control. This wouldn't be an editorial issue > though and is more of a design issue. I've put up a PR for the design > change, if people don't like the change I can put up a PR for only the > editorial change instead keeping the current semantics: > > > > https://github.com/quicwg/base-drafts/pull/730 > > > > > Subodh > ------------------------------ > > *From:* QUIC on behalf of Ian Swett < > ianswett@google.com> > *Sent:* Monday, August 14, 2017 9:49:28 AM > *To:* Subodh Iyengar > *Cc:* quic@ietf.org > *Subject:* Re: flow control description in draft > > > > On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar wrote: > > Ya I think the language in the draft could be a bit more clear, will send > out a PR soon. > > > > However I have a few more questions that came up: > > 1. Is FIN not subject to flow control? It seems logical to not subject > it to flow control, but it's a super weird edge case since FIN has it'= s own > offset :) > > > > A fin is not subject to flow control. I guess I think of it taking up no > space, so it doesn't seem like a problem, but I can see your point. > > > > > 1. Is it max data or max offset. For example if I send you maxData =3D > 10, can you send until offset 9 or offset 10. I think you mean offset = 9. > > > > Good point, that seems worth clarifying. > > Subodh > ------------------------------ > > *From:* Ian Swett > *Sent:* Friday, July 28, 2017 9:57:23 AM > *To:* Subodh Iyengar > *Cc:* quic@ietf.org > *Subject:* Re: flow control description in draft > > > > > > > > On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote: > > The flow control language in the draft is a bit confusing right now, and = I > could use a bit more clarity on the intention > > For example in MAX_DATA and MAX_STREAM_DATA the data is defined as > > "A 64-bit unsigned integer indicating the maximum amount of data that can > be sent on the entire connection, in units of 1024 octets. That is, the > updated connection-level data limit is determined by multiplying the > encoded value by 1024." > > This seems like it means that flow control is advertised in terms of > number of bytes that you can send from that moment. > > > However from the Flow control section: > > "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to > advertise additional credit by sending the absolute byte offset in the > connection or stream which it is willing to receive." > > I think that we definitely mean offset here in both cases, i.e. > > MAX_DATA =3D sum of max offset of all streams that are allowed > > MAX_STREAM_DATA =3D max offset on a stream > > > > Yes, that's what the spec means. I thought it was fairly clear, but if > you think it's confusing, a PR to improve the wording would be appreciate= d. > > > > Let's say the conn flow control limit of the receiver is 50. All units in > multiples of 1024. > > initial state of receiver > stream1 --> [0, 10] > stream2 --> [0, 20] > > stream3 --> [0, 20] > > > So the sender has consumed his entire flow control window. Then the > receiver consumes 10 (*1024) bytes from stream1: > > stream1 ---> (10, 10) > > stream2 ---> [0, 20] > > stream3 ---> [0, 20] > > > > so now the conn window has 10 (*1024) bytes remaining, what does the > receiver send in their update: > > > > MAX_DATA =3D 10 > > or > > MAX_DATA =3D 60 > > > > I think we mean 60 here. It makes it much easier to maintain the flow > control in that case. > > > > Subodh > > > > > --f403045eb0969ecba90556be1d79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for bringing this up, Subodh. I agree with Ian and = Mike that FIN does not need be included in flow control accounting. The onl= y reason it consumes an offset is the case where it is sent on an empty STR= EAM frame. But this does matter for flow control since as Ian pointed out, = this byte does not consume any buffer space. I'll look at the PR.
=

On Mon, Aug 14, 2= 017 at 12:49 PM, Subodh Iyengar <subodh@fb.com> wrote:

@Mike ya another issue I brought up is that it's actually not ration= alized around offsets right now, the current formulation is around maximum = data which is what raised the question of FINs. The PR changes the formulat= ion to be around offsets. This is discussed in the PR summary. Let me know what you think.


Subodh

From: = Mike Bishop <Michael.Bishop@microsoft.com>
Sent: Monday, August 14, 2017 12:31:41 PM
To: Subodh Iyengar; Ian Swett
Cc: quic@ietf.org=
Subject: RE: flow control description in draft
=C2=A0

Like Ian, I don=E2=80=99t see this as an issue =E2= =80=93 assuming everything is rationalized around offsets, the check is alw= ays whether (current offset) + (payload length) <=3D (allowed offset).= =C2=A0 Even if (current offset) =3D=3D (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will = still be true.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <ianswett@google.com>
Cc: quic@ietf.org=
Subject: Re: flow control description in draft

=C2=A0

Ya the complexity of not ha= ving FIN as subject to flow control is that the stream frame scheduler woul= d have special logic for processing FINs while checking whether it has flow= control. This wouldn't be an editorial issue though and is more of a design issue. I've put up a PR for the d= esign change, if people don't like the change I can put up a PR for onl= y the editorial change instead keeping the current semantics:

=C2=A0=

https://github.com/quicwg/base-drafts/pull/730<= u>

=C2=A0=

Subodh=

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <<= a href=3D"mailto:ianswett@google.com" target=3D"_blank">ianswett@google.com= >
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft =

=C2=A0

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <= ;subodh@fb.com> w= rote:

Ya I think the language in = the draft could be a bit more clear, will send out a PR soon.=

=C2=A0=

However I have a few more q= uestions that came up:

  1. Is FIN not subject to flow control? It see= ms logical to not subject it to flow control, but it's a super weird ed= ge case since FIN has it's own offset :)

=C2=A0

A fin is not subject to flow control.=C2=A0 I guess = I think of it taking up no space, so it doesn't seem like a problem, bu= t I can see your point.

=C2=A0

  1. Is=C2=A0it max data or max offset. For exa= mple if I send you maxData =3D 10, can you send until offset 9 or offset 10= . I think you mean offset 9.

=C2=A0=

Good point, that seems worth clarifying.=C2=A0

Subodh=

From: Ian Swett <ianswett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft =

=C2=A0

=C2=A0

=C2=A0

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

The flow control language i= n the draft is a bit confusing right now, and I could use a bit more clarit= y on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max off= set on a stream

=C2=A0=

Yes, that's what the spec means.=C2=A0 I thought= it was fairly clear, but if you think it's confusing, a PR to improve = the wording would be appreciated.

=C2=A0

Let's say the conn flow control limit of the receiver is 50. All un= its in multiples of 1024.

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

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


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]<= /u>

stream3 ---> [0, 20]<= /u>

=C2=A0=

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

=C2=A0=

MAX_DATA =3D 10

or

MAX_DATA =3D 60

=C2=A0=

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

=C2=A0

Subodh

=C2=A0

=C2=A0


--f403045eb0969ecba90556be1d79-- From nobody Mon Aug 14 16:16:32 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EA213241C for ; Mon, 14 Aug 2017 16:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=jrlYOFOm; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=EGGM2zHy Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2fc7ubJuNlt for ; Mon, 14 Aug 2017 16:16:28 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96FD913239E for ; Mon, 14 Aug 2017 16:16:28 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.21/8.16.0.21) with SMTP id v7ENC0PX032652; Mon, 14 Aug 2017 16:16:24 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=wiz8jiXE/9YgIXImf6dXyeHHwNCCxVysroPBIAhVMZg=; b=jrlYOFOmRjyTZdYq998Xup9qjuBhFjKCLX/BOQTALNOk6FbUmN7Pua5TWmEphE7NVZsK OMk0UwzEpW7Phi7nnRdaMwhVtg/Lm9lupbltu8lsBzowa+hZ8sgqo2SxY1XL8sPYjk4/ q3sNxhnEN/QLZNm1o72Nh9W0sE138LZQtmg= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2ca0g1xnc0-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Aug 2017 16:16:24 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 Aug 2017 16:16:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wiz8jiXE/9YgIXImf6dXyeHHwNCCxVysroPBIAhVMZg=; b=EGGM2zHyg+MVkuAnwKduAL6EQ8Ubr6hFhDREnh4cO13uVsVK/nxVwGH6UaPVb7lDm+h2rvCQyKUsm8omcQmFC8TOPLDGpda9Qan4vSmug1DvmRNbpjYyfBqRhVH7A48kRR5FbOIazB9Ny2MmyMaJBHXqae48EaadmrlQzdnFMcg= 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.1.1341.21; Mon, 14 Aug 2017 23:16:21 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1341.020; Mon, 14 Aug 2017 23:16:21 +0000 From: Subodh Iyengar To: Jana Iyengar CC: Mike Bishop , Ian Swett , "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/CAAAXE8YAAK4CAgAAKKo4= Date: Mon, 14 Aug 2017 23:16:20 +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::4:7f8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1453; 20:5uEPV1OLwe3yjEOgDrEc30uZkAA5MsRiByZvTbFGh0FtUOrQwEmLvppg/xkto/00gfkbARnahuzLIhH4AKAE9ePxMqubnj9vqU1uDDF7OlN0Zb4aBo8QyBoGngnipQc0XhYpRKXKkekCpfN+74S4FW63s7PWP05N42jxv8FRDyg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8955f8d6-e2a5-41fe-3d09-08d4e36a7988 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1453; x-ms-traffictypediagnostic: MWHPR15MB1453: x-exchange-antispam-report-test: UriScan:(10436049006162)(89211679590171)(166708455590820)(189930954265078)(67672495146484)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(920507026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1453; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1453; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(51444003)(189002)(76104003)(377454003)(45080400002)(2900100001)(34040400001)(7736002)(53936002)(6246003)(4326008)(54356999)(93886004)(76176999)(6436002)(50986999)(8676002)(3280700002)(5660300001)(101416001)(2950100002)(229853002)(19627405001)(3660700001)(33656002)(584604001)(8936002)(102836003)(6116002)(77096006)(14454004)(2906002)(81166006)(81156014)(6506006)(106356001)(74316002)(105586002)(68736007)(110136004)(966005)(6916009)(9686003)(25786009)(8666007)(54906002)(99286003)(54896002)(606006)(6306002)(189998001)(478600001)(55016002)(236005)(53546010)(97736004)(7696004)(86362001); 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455FF74F1138529DECA3C7FB68C0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 23:16:20.9373 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1453 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_20:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 23:16:31 -0000 --_000_MWHPR15MB1455FF74F1138529DECA3C7FB68C0MWHPR15MB1455namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ya I think my confusion initially is that in some parts of the document it = says that the max data represents the offset, however in other parts it ref= ers to it as the max data you can send. These have subtly different meaning= s. I chose to interpret the max data as offsets rather than amount of data = to be sent, and that's why I arrived at the conclusion that I would have to= account for the FIN separately and sent out a PR to represent all quantiti= es as offsets. Of course, as Mike and Ian point out, this could also work with the current= formulation of maximum data. We could keep it as it is and have a editoria= l PR to modify the language of the flow control section instead to call thi= s out more. For clarity we should either choose amount of data or offset all throughout= . To me, it seemed more intuitive to send offsets if limits are being sent = on offsets, but I'm happy with either approach. Subodh ________________________________ From: Jana Iyengar Sent: Monday, August 14, 2017 3:23:43 PM To: Subodh Iyengar Cc: Mike Bishop; Ian Swett; quic@ietf.org Subject: Re: flow control description in draft Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN doe= s not need be included in flow control accounting. The only reason it consu= mes an offset is the case where it is sent on an empty STREAM frame. But th= is does matter for flow control since as Ian pointed out, this byte does no= t consume any buffer space. I'll look at the PR. On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar > wrote: @Mike ya another issue I brought up is that it's actually not rationalized = around offsets right now, the current formulation is around maximum data wh= ich is what raised the question of FINs. The PR changes the formulation to = be around offsets. This is discussed in the PR summary. Let me know what yo= u think. Subodh ________________________________ From: Mike Bishop > Sent: Monday, August 14, 2017 12:31:41 PM To: Subodh Iyengar; Ian Swett Cc: quic@ietf.org Subject: RE: flow control description in draft Like Ian, I don=92t see this as an issue =96 assuming everything is rationa= lized around offsets, the check is always whether (current offset) + (paylo= ad length) <=3D (allowed offset). Even if (current offset) =3D=3D (allowed= offset), a STREAM frame that contains only a FIN will have a payload lengt= h of zero, so this will still be true. From: QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Subodh Iyengar Sent: Monday, August 14, 2017 12:18 PM To: Ian Swett > Cc: quic@ietf.org Subject: Re: flow control description in draft Ya the complexity of not having FIN as subject to flow control is that the = stream frame scheduler would have special logic for processing FINs while c= hecking whether it has flow control. This wouldn't be an editorial issue th= ough and is more of a design issue. I've put up a PR for the design change,= if people don't like the change I can put up a PR for only the editorial c= hange instead keeping the current semantics: https://github.com/quicwg/base-drafts/pull/730 Subodh ________________________________ From: QUIC > on behalf = of Ian Swett > Sent: Monday, August 14, 2017 9:49:28 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar > wrote: Ya I think the language in the draft could be a bit more clear, will send o= ut a PR soon. However I have a few more questions that came up: 1. Is FIN not subject to flow control? It seems logical to not subject i= t to flow control, but it's a super weird edge case since FIN has it's own = offset :) A fin is not subject to flow control. I guess I think of it taking up no s= pace, so it doesn't seem like a problem, but I can see your point. 1. Is it max data or max offset. For example if I send you maxData =3D 1= 0, can you send until offset 9 or offset 10. I think you mean offset 9. Good point, that seems worth clarifying. Subodh ________________________________ From: Ian Swett > Sent: Friday, July 28, 2017 9:57:23 AM To: Subodh Iyengar Cc: quic@ietf.org Subject: Re: flow control description in draft On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar > wrote: The flow control language in the draft is a bit confusing right now, and I = could use a bit more clarity on the intention For example in MAX_DATA and MAX_STREAM_DATA the data is defined as "A 64-bit unsigned integer indicating the maximum amount of data that can b= e sent on the entire connection, in units of 1024 octets. That is, the upda= ted connection-level data limit is determined by multiplying the encoded va= lue by 1024." This seems like it means that flow control is advertised in terms of number= of bytes that you can send from that moment. However from the Flow control section: "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to adver= tise additional credit by sending the absolute byte offset in the connectio= n or stream which it is willing to receive." I think that we definitely mean offset here in both cases, i.e. MAX_DATA =3D sum of max offset of all streams that are allowed MAX_STREAM_DATA =3D max offset on a stream Yes, that's what the spec means. I thought it was fairly clear, but if you= think it's confusing, a PR to improve the wording would be appreciated. Let's say the conn flow control limit of the receiver is 50. All units in m= ultiples of 1024. initial state of receiver stream1 --> [0, 10] stream2 --> [0, 20] stream3 --> [0, 20] So the sender has consumed his entire flow control window. Then the receive= r consumes 10 (*1024) bytes from stream1: stream1 ---> (10, 10) stream2 ---> [0, 20] stream3 ---> [0, 20] so now the conn window has 10 (*1024) bytes remaining, what does the receiv= er send in their update: MAX_DATA =3D 10 or MAX_DATA =3D 60 I think we mean 60 here. It makes it much easier to maintain the flow contr= ol in that case. Subodh --_000_MWHPR15MB1455FF74F1138529DECA3C7FB68C0MWHPR15MB1455namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Ya I think my confusion initially is that in some parts of the document = it says that the max data represents the offset, however in other parts it = refers to it as the max data you can send. These have subtly different mean= ings. I chose to interpret the max data as offsets rather than amount of data to be sent, and that's why I ar= rived at the conclusion that I would have to account for the FIN separately= and sent out a PR to represent all quantities as offsets.


Of course, as Mike and Ian point out, this could also work with the curr= ent formulation of maximum data. We could keep it as it is and have a edito= rial PR to modify the language of the flow control section instead to call = this out more.


For clarity we should either choose amount of data or offset all through= out. To me, it seemed more intuitive to send offsets if limits are being se= nt on offsets, but I'm happy with either approach.


Subodh

From: Jana Iyengar <jri@= google.com>
Sent: Monday, August 14, 2017 3:23:43 PM
To: Subodh Iyengar
Cc: Mike Bishop; Ian Swett; quic@ietf.org
Subject: Re: flow control description in draft
 
Thanks for bringing this up, Subodh. I agree with Ian and = Mike that FIN does not need be included in flow control accounting. The onl= y reason it consumes an offset is the case where it is sent on an empty STR= EAM frame. But this does matter for flow control since as Ian pointed out, this byte does not consume any buff= er space. I'll look at the PR.

On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar= <subodh@fb.com>= ; wrote:

@Mike ya another issue I brought up is that it's actually not rationaliz= ed around offsets right now, the current formulation is around maximum data= which is what raised the question of FINs. The PR changes the formulation = to be around offsets. This is discussed in the PR summary. Let me know what you think.


Subodh

From: = Mike Bishop <Michael.Bishop@microsoft.com>
Sent: Monday, August 14, 2017 12:31:41 PM
To: Subodh Iyengar; Ian Swett
Cc: quic@ietf.org=
Subject: RE: flow control description in draft
 

Like Ian, I don=92t see this as an issue =96 assumin= g everything is rationalized around offsets, the check is always whether (c= urrent offset) + (payload length) <=3D (allowed offset).  Even = if (current offset) =3D=3D (allowed offset), a STREAM frame that contains only a FIN will have a payload length of zero, so this will = still be true.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar
Sent: Monday, August 14, 2017 12:18 PM
To: Ian Swett <ianswett@google.com>
Cc: quic@ietf.org=
Subject: Re: flow control description in draft

 

Ya the complexity of not ha= ving FIN as subject to flow control is that the stream frame scheduler woul= d have special logic for processing FINs while checking whether it has flow= control. This wouldn't be an editorial issue though and is more of a design issue. I've put up a PR for the desig= n change, if people don't like the change I can put up a PR for only the ed= itorial change instead keeping the current semantics:

 =

https://github.com/quicwg/base-drafts/pull/730<= u>

 =

Subodh=

From: QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <<= a href=3D"mailto:ianswett@google.com" target=3D"_blank">ianswett@google.com= >
Sent: Monday, August 14, 2017 9:49:28 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft =

 

On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <= ;subodh@fb.com> w= rote:

Ya I think the language in = the draft could be a bit more clear, will send out a PR soon.=

 =

However I have a few more q= uestions that came up:

  1. Is FIN not subject to flow control? It seems logical to not subject it = to flow control, but it's a super weird edge case since FIN has it's own of= fset :)

 

A fin is not subject to flow control.  I guess = I think of it taking up no space, so it doesn't seem like a problem, but I = can see your point.

 

  1. Is it max data or max offset. For example if I send you maxData = =3D 10, can you send until offset 9 or offset 10. I think you mean offset 9= .

 =

Good point, that seems worth clarifying. 

Subodh=

From: Ian Swett <ianswett@google.com>
Sent: Friday, July 28, 2017 9:57:23 AM
To: Subodh Iyengar
Cc: quic@ietf.org=
Subject: Re: flow control description in draft =

 

 

 

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

The flow control language i= n the draft is a bit confusing right now, and I could use a bit more clarit= y on the intention

For example in MAX_DATA and MAX_STREAM_DATA the data is defined as

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

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


However from the Flow control section:

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

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

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

MAX_STREAM_DATA =3D max off= set on a stream

 =

Yes, that's what the spec means.  I thought it = was fairly clear, but if you think it's confusing, a PR to improve the word= ing would be appreciated.

 

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

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

stream3 -->  [0, 20= ]


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

stream1 ---> (10, 10)

stream2 ---> [0, 20]<= /u>

stream3 ---> [0, 20]<= /u>

 =

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

 =

MAX_DATA =3D 10

or

MAX_DATA =3D 60

 =

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

 

Subodh

 

 


--_000_MWHPR15MB1455FF74F1138529DECA3C7FB68C0MWHPR15MB1455namp_-- From nobody Mon Aug 14 16:40:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C70613232D for ; Mon, 14 Aug 2017 16:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMEUf-BmV1HW for ; Mon, 14 Aug 2017 16:40:41 -0700 (PDT) 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 96C011321AA for ; Mon, 14 Aug 2017 16:40:41 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id m34so12897808iti.1 for ; Mon, 14 Aug 2017 16:40:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=hDhHc3cBMVU4dR3GNhUpbCO0La5CDlyv+S1ncE4PJq0=; b=ZypM/I9hN7YrdL6dKlIciS2z5n2Oo1aKEZmpdIOxCBBVB3DVtJ6XvTKg+4TUxhu8yF W3UITrdHaUdgIk+Bma+x53Zxa7qjN+XJ2gKZn0PK6SOpy58BlHqX674g9CnvqreKGq7l IcVMpe8I1IZiMZQgjHBfqpzTzz4S+LYgg0L59hpz8rwd7MRhydKHBo6AWRsYQ0P6/9gG ibBRNQJnt6iJzwO3sEheK0UApTLXfS2LYIaFDDG8F+yubn5e6CooAaTQKJvOgtBz2+ld e2ovTHrT6K3HSky7JT+jgZ6rrvd4LhT6WvNJ81SGICDo0CSTSJnKCQwaGsQPlmoXX/5M djDg== 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=hDhHc3cBMVU4dR3GNhUpbCO0La5CDlyv+S1ncE4PJq0=; b=OIH812/6ZSNrb4acXsftM5oCce5mGixpzgjEcqjAKqjUQYEP6IomMjNRfj2bf1UJLM oE351tuxRLTayBukgza/3odFkA5C9l5V0d7V2P8ZNBqtYC0MW0Hudms2NOQeX0xTeFlf T90H+++NSkYSYimZOU/VvVBVCFB6EoUuMyiAv0fuiM2JHNcG/9YCO50wyv6kTjDhFFep hsZ2fF1r7zqwEzem2v5Qi+n7h1DX2JfIYx1m8rwV8YeCS5iXxUhcsa4a5lnhHjUcBs+4 jIW+ZyjXQ29AZiZOpyxBGRj8itZXAMWAFUZfn69yazMO9rLG2iTMqAmL4XV3uFjp258S AMZg== X-Gm-Message-State: AHYfb5h2GSSoMgy5gaSFjmxIqsYZoVGpck6D4vkF23okD5zAl4yCsu/o CiDpS+HYkQI3upQ7p5ViTruhMV+fqg== X-Received: by 10.36.181.85 with SMTP id j21mr527695iti.165.1502754040661; Mon, 14 Aug 2017 16:40:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 14 Aug 2017 16:40:39 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Aug 2017 09:40:39 +1000 Message-ID: Subject: Re: flow control description in draft To: Jana Iyengar Cc: Subodh Iyengar , Mike Bishop , Ian Swett , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 23:40:44 -0000 I don't think that a characterisation of FIN of "consuming an offset" is correct. The frame includes an offset, which is the point *between* octets on the stream. The first octet in the frame (if present) is immediately after that gap. Think of it like this: Octets: ,_0_,_1_,_2_,_3_,_4_, The offset is at the comma, not the numeral. FIN makes the comma a period. On 15 August 2017 at 08:23, Jana Iyengar wrote: > Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN d= oes > not need be included in flow control accounting. The only reason it consu= mes > an offset is the case where it is sent on an empty STREAM frame. But this > does matter for flow control since as Ian pointed out, this byte does not > consume any buffer space. I'll look at the PR. > > On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar wrote: >> >> @Mike ya another issue I brought up is that it's actually not rationaliz= ed >> around offsets right now, the current formulation is around maximum data >> which is what raised the question of FINs. The PR changes the formulatio= n to >> be around offsets. This is discussed in the PR summary. Let me know what= you >> think. >> >> >> Subodh >> >> ________________________________ >> From: Mike Bishop >> Sent: Monday, August 14, 2017 12:31:41 PM >> To: Subodh Iyengar; Ian Swett >> Cc: quic@ietf.org >> Subject: RE: flow control description in draft >> >> >> Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming everyt= hing is >> rationalized around offsets, the check is always whether (current offset= ) + >> (payload length) <=3D (allowed offset). Even if (current offset) =3D=3D= (allowed >> offset), a STREAM frame that contains only a FIN will have a payload len= gth >> of zero, so this will still be true. >> >> >> >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar >> Sent: Monday, August 14, 2017 12:18 PM >> To: Ian Swett >> Cc: quic@ietf.org >> Subject: Re: flow control description in draft >> >> >> >> Ya the complexity of not having FIN as subject to flow control is that t= he >> stream frame scheduler would have special logic for processing FINs whil= e >> checking whether it has flow control. This wouldn't be an editorial issu= e >> though and is more of a design issue. I've put up a PR for the design >> change, if people don't like the change I can put up a PR for only the >> editorial change instead keeping the current semantics: >> >> >> >> https://github.com/quicwg/base-drafts/pull/730 >> >> >> >> Subodh >> >> ________________________________ >> >> From: QUIC on behalf of Ian Swett >> >> Sent: Monday, August 14, 2017 9:49:28 AM >> To: Subodh Iyengar >> Cc: quic@ietf.org >> Subject: Re: flow control description in draft >> >> >> >> On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar wrote: >> >> Ya I think the language in the draft could be a bit more clear, will sen= d >> out a PR soon. >> >> >> >> However I have a few more questions that came up: >> >> Is FIN not subject to flow control? It seems logical to not subject it t= o >> flow control, but it's a super weird edge case since FIN has it's own of= fset >> :) >> >> >> >> A fin is not subject to flow control. I guess I think of it taking up n= o >> space, so it doesn't seem like a problem, but I can see your point. >> >> >> >> Is it max data or max offset. For example if I send you maxData =3D 10, = can >> you send until offset 9 or offset 10. I think you mean offset 9. >> >> >> >> Good point, that seems worth clarifying. >> >> Subodh >> >> ________________________________ >> >> From: Ian Swett >> Sent: Friday, July 28, 2017 9:57:23 AM >> To: Subodh Iyengar >> Cc: quic@ietf.org >> Subject: Re: flow control description in draft >> >> >> >> >> >> >> >> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote: >> >> The flow control language in the draft is a bit confusing right now, and= I >> could use a bit more clarity on the intention >> >> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as >> >> "A 64-bit unsigned integer indicating the maximum amount of data that ca= n >> be sent on the entire connection, in units of 1024 octets. That is, the >> updated connection-level data limit is determined by multiplying the enc= oded >> value by 1024." >> >> This seems like it means that flow control is advertised in terms of >> number of bytes that you can send from that moment. >> >> >> However from the Flow control section: >> >> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to >> advertise additional credit by sending the absolute byte offset in the >> connection or stream which it is willing to receive." >> >> I think that we definitely mean offset here in both cases, i.e. >> >> MAX_DATA =3D sum of max offset of all streams that are allowed >> >> MAX_STREAM_DATA =3D max offset on a stream >> >> >> >> Yes, that's what the spec means. I thought it was fairly clear, but if >> you think it's confusing, a PR to improve the wording would be appreciat= ed. >> >> >> >> Let's say the conn flow control limit of the receiver is 50. All units i= n >> multiples of 1024. >> >> initial state of receiver >> stream1 --> [0, 10] >> stream2 --> [0, 20] >> >> stream3 --> [0, 20] >> >> >> So the sender has consumed his entire flow control window. Then the >> receiver consumes 10 (*1024) bytes from stream1: >> >> stream1 ---> (10, 10) >> >> stream2 ---> [0, 20] >> >> stream3 ---> [0, 20] >> >> >> >> so now the conn window has 10 (*1024) bytes remaining, what does the >> receiver send in their update: >> >> >> >> MAX_DATA =3D 10 >> >> or >> >> MAX_DATA =3D 60 >> >> >> >> I think we mean 60 here. It makes it much easier to maintain the flow >> control in that case. >> >> >> >> Subodh >> >> >> >> > > From nobody Mon Aug 14 16:46:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68649132453 for ; Mon, 14 Aug 2017 16:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLxFVT6oADyi for ; Mon, 14 Aug 2017 16:46:45 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08BAD13245A for ; Mon, 14 Aug 2017 16:46:44 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id s143so63926563ywg.1 for ; Mon, 14 Aug 2017 16:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4JhSFQl0RZhSDcCL1ISEI8oiiau55MNoS3soCxDOGsg=; b=I6iCI4lV+SGLYrC6iZT/3Co6gdEBgVHNC4PYtefEJgY8P42KHYrmZNzY1RLrOVuNN1 NwoIlXbBvLb6xvhcRjkGnYBK2GWyyu+XAWZD42/p8fNieSQQzMqILNuVbGtzyqTbVMlQ UDdQibmE0fHkNT8DLn7sJBSGcLgYrKLcdqAI0gih/n8Eh8cWHPPlkDC+qGMZLi776u7q CMryrJKrBeo+bkYP27tLO7k2Z8m1JNTwVfO1B9VFiaT/5/ro+/niHDDw4gnHUhD7Xj4R h9ZQXK7tkdYqIIvcNNPQe14wJTF2WgHQ2r/hqA102HUH1xIBah0x2xoFN0U7+uDo5nej NYdg== 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=4JhSFQl0RZhSDcCL1ISEI8oiiau55MNoS3soCxDOGsg=; b=CH1sanlny7abwHRCh7kj6cpcueOHj28umsiB28CJIUSyAY4guhckxFuDgR/14yePY8 fIZnWnRAaZCilKI0pED6Q4yrtm7YkLcuhdrq+hZVFrZwRBCVNS0aoZYbYRix3pTDusPw 8y+tLGh0ffKgZ06OePSGBEhqUHohHG+PIei/0Ik5EtmgZ0A9Cq7ZlsfnECFQEAmCAyQW E5OWTbB9m1DHdgqC1xCC9FHxf2b3zgAGn4imEfKVdFcBXBhbI6V0ETp8TllommXvBj0Q MzZgg2BNEVVdr1K6zlIbNrvSxLAZmVmX/oKHmwhJpS1F3sCxKJVxc5R2FGLd1o2EJY2U 2rAg== X-Gm-Message-State: AHYfb5gUN4v7uZ6wGU6fZjsotFRCfDTceDmRgtFBnqIj1mc9mEbrMbgL V5GVsN8540l/RR6xg2hIkmvndBFVBB+q X-Received: by 10.37.207.82 with SMTP id f79mr21662700ybg.103.1502754403973; Mon, 14 Aug 2017 16:46:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.217.137 with HTTP; Mon, 14 Aug 2017 16:46:23 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Mon, 14 Aug 2017 19:46:23 -0400 Message-ID: Subject: Re: flow control description in draft To: Martin Thomson Cc: Jana Iyengar , Subodh Iyengar , Mike Bishop , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0565c86f7b1f0556bf468c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 14 Aug 2017 23:46:48 -0000 --94eb2c0565c86f7b1f0556bf468c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 14, 2017 at 7:40 PM, Martin Thomson wrote: > I don't think that a characterisation of FIN of "consuming an offset" > is correct. The frame includes an offset, which is the point > *between* octets on the stream. The first octet in the frame (if > present) is immediately after that gap. > > Think of it like this: > > Octets: ,_0_,_1_,_2_,_3_,_4_, > > The offset is at the comma, not the numeral. FIN makes the comma a perio= d. > > Agreed. > > On 15 August 2017 at 08:23, Jana Iyengar wrote: > > Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN > does > > not need be included in flow control accounting. The only reason it > consumes > > an offset is the case where it is sent on an empty STREAM frame. But th= is > > does matter for flow control since as Ian pointed out, this byte does n= ot > > consume any buffer space. I'll look at the PR. > > > > On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar wrote: > >> > >> @Mike ya another issue I brought up is that it's actually not > rationalized > >> around offsets right now, the current formulation is around maximum da= ta > >> which is what raised the question of FINs. The PR changes the > formulation to > >> be around offsets. This is discussed in the PR summary. Let me know > what you > >> think. > >> > >> > >> Subodh > >> > >> ________________________________ > >> From: Mike Bishop > >> Sent: Monday, August 14, 2017 12:31:41 PM > >> To: Subodh Iyengar; Ian Swett > >> Cc: quic@ietf.org > >> Subject: RE: flow control description in draft > >> > >> > >> Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming ever= ything is > >> rationalized around offsets, the check is always whether (current > offset) + > >> (payload length) <=3D (allowed offset). Even if (current offset) =3D= =3D > (allowed > >> offset), a STREAM frame that contains only a FIN will have a payload > length > >> of zero, so this will still be true. > >> > >> > >> > >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar > >> Sent: Monday, August 14, 2017 12:18 PM > >> To: Ian Swett > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> Ya the complexity of not having FIN as subject to flow control is that > the > >> stream frame scheduler would have special logic for processing FINs > while > >> checking whether it has flow control. This wouldn't be an editorial > issue > >> though and is more of a design issue. I've put up a PR for the design > >> change, if people don't like the change I can put up a PR for only the > >> editorial change instead keeping the current semantics: > >> > >> > >> > >> https://github.com/quicwg/base-drafts/pull/730 > >> > >> > >> > >> Subodh > >> > >> ________________________________ > >> > >> From: QUIC on behalf of Ian Swett > >> > >> Sent: Monday, August 14, 2017 9:49:28 AM > >> To: Subodh Iyengar > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar wrote= : > >> > >> Ya I think the language in the draft could be a bit more clear, will > send > >> out a PR soon. > >> > >> > >> > >> However I have a few more questions that came up: > >> > >> Is FIN not subject to flow control? It seems logical to not subject it > to > >> flow control, but it's a super weird edge case since FIN has it's own > offset > >> :) > >> > >> > >> > >> A fin is not subject to flow control. I guess I think of it taking up > no > >> space, so it doesn't seem like a problem, but I can see your point. > >> > >> > >> > >> Is it max data or max offset. For example if I send you maxData =3D 10= , > can > >> you send until offset 9 or offset 10. I think you mean offset 9. > >> > >> > >> > >> Good point, that seems worth clarifying. > >> > >> Subodh > >> > >> ________________________________ > >> > >> From: Ian Swett > >> Sent: Friday, July 28, 2017 9:57:23 AM > >> To: Subodh Iyengar > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> > >> > >> > >> > >> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote= : > >> > >> The flow control language in the draft is a bit confusing right now, > and I > >> could use a bit more clarity on the intention > >> > >> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as > >> > >> "A 64-bit unsigned integer indicating the maximum amount of data that > can > >> be sent on the entire connection, in units of 1024 octets. That is, th= e > >> updated connection-level data limit is determined by multiplying the > encoded > >> value by 1024." > >> > >> This seems like it means that flow control is advertised in terms of > >> number of bytes that you can send from that moment. > >> > >> > >> However from the Flow control section: > >> > >> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to > >> advertise additional credit by sending the absolute byte offset in the > >> connection or stream which it is willing to receive." > >> > >> I think that we definitely mean offset here in both cases, i.e. > >> > >> MAX_DATA =3D sum of max offset of all streams that are allowed > >> > >> MAX_STREAM_DATA =3D max offset on a stream > >> > >> > >> > >> Yes, that's what the spec means. I thought it was fairly clear, but i= f > >> you think it's confusing, a PR to improve the wording would be > appreciated. > >> > >> > >> > >> Let's say the conn flow control limit of the receiver is 50. All units > in > >> multiples of 1024. > >> > >> initial state of receiver > >> stream1 --> [0, 10] > >> stream2 --> [0, 20] > >> > >> stream3 --> [0, 20] > >> > >> > >> So the sender has consumed his entire flow control window. Then the > >> receiver consumes 10 (*1024) bytes from stream1: > >> > >> stream1 ---> (10, 10) > >> > >> stream2 ---> [0, 20] > >> > >> stream3 ---> [0, 20] > >> > >> > >> > >> so now the conn window has 10 (*1024) bytes remaining, what does the > >> receiver send in their update: > >> > >> > >> > >> MAX_DATA =3D 10 > >> > >> or > >> > >> MAX_DATA =3D 60 > >> > >> > >> > >> I think we mean 60 here. It makes it much easier to maintain the flow > >> control in that case. > >> > >> > >> > >> Subodh > >> > >> > >> > >> > > > > > --94eb2c0565c86f7b1f0556bf468c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Aug 14, 2017 at 7:40 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
I don= 9;t think that a characterisation of FIN of "consuming an offset"=
is correct.=C2=A0 The frame includes an offset, which is the point
*between* octets on the stream.=C2=A0 The first octet in the frame (if
present) is immediately after that gap.

Think of it like this:

Octets:=C2=A0 =C2=A0,_0_,_1_,_2_,_3_,_4_,

The offset is at the comma, not the numeral.=C2=A0 FIN makes the comma a pe= riod.

<= br>
Agreed.
=C2=A0
=

On 15 August 2017 at 08:23, Jana Iyengar <jri@google.com> wrote:
> Thanks for bringing this up, Subodh. I agree with Ian and Mike that FI= N does
> not need be included in flow control accounting. The only reason it co= nsumes
> an offset is the case where it is sent on an empty STREAM frame. But t= his
> does matter for flow control since as Ian pointed out, this byte does = not
> consume any buffer space. I'll look at the PR.
>
> On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> @Mike ya another issue I brought up is that it's actually not = rationalized
>> around offsets right now, the current formulation is around maximu= m data
>> which is what raised the question of FINs. The PR changes the form= ulation to
>> be around offsets. This is discussed in the PR summary. Let me kno= w what you
>> think.
>>
>>
>> Subodh
>>
>> ________________________________
>> From: Mike Bishop <Michael.Bishop@microsoft.com>
>> Sent: Monday, August 14, 2017 12:31:41 PM
>> To: Subodh Iyengar; Ian Swett
>> Cc: quic@ietf.org
>> Subject: RE: flow control description in draft
>>
>>
>> Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming = everything is
>> rationalized around offsets, the check is always whether (current = offset) +
>> (payload length) <=3D (allowed offset).=C2=A0 Even if (current = offset) =3D=3D (allowed
>> offset), a STREAM frame that contains only a FIN will have a paylo= ad length
>> of zero, so this will still be true.
>>
>>
>>
>> From: QUIC [mailto:quic-b= ounces@ietf.org] On Behalf Of Subodh Iyengar
>> Sent: Monday, August 14, 2017 12:18 PM
>> To: Ian Swett <ianswett@= google.com>
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>> Ya the complexity of not having FIN as subject to flow control is = that the
>> stream frame scheduler would have special logic for processing FIN= s while
>> checking whether it has flow control. This wouldn't be an edit= orial issue
>> though and is more of a design issue. I've put up a PR for the= design
>> change, if people don't like the change I can put up a PR for = only the
>> editorial change instead keeping the current semantics:
>>
>>
>>
>> https://github.com/quicwg/base-drafts/pu= ll/730
>>
>>
>>
>> Subodh
>>
>> ________________________________
>>
>> From: QUIC <quic-bounc= es@ietf.org> on behalf of Ian Swett
>> <ianswett@google.com= >
>> Sent: Monday, August 14, 2017 9:49:28 AM
>> To: Subodh Iyengar
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>> On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> Ya I think the language in the draft could be a bit more clear, wi= ll send
>> out a PR soon.
>>
>>
>>
>> However I have a few more questions that came up:
>>
>> Is FIN not subject to flow control? It seems logical to not subjec= t it to
>> flow control, but it's a super weird edge case since FIN has i= t's own offset
>> :)
>>
>>
>>
>> A fin is not subject to flow control.=C2=A0 I guess I think of it = taking up no
>> space, so it doesn't seem like a problem, but I can see your p= oint.
>>
>>
>>
>> Is it max data or max offset. For example if I send you maxData = =3D 10, can
>> you send until offset 9 or offset 10. I think you mean offset 9. >>
>>
>>
>> Good point, that seems worth clarifying.
>>
>> Subodh
>>
>> ________________________________
>>
>> From: Ian Swett <ianswet= t@google.com>
>> Sent: Friday, July 28, 2017 9:57:23 AM
>> To: Subodh Iyengar
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> The flow control language in the draft is a bit confusing right no= w, and I
>> could use a bit more clarity on the intention
>>
>> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as=
>>
>> "A 64-bit unsigned integer indicating the maximum amount of d= ata that can
>> be sent on the entire connection, in units of 1024 octets. That is= , the
>> updated connection-level data limit is determined by multiplying t= he encoded
>> value by 1024."
>>
>> This seems like it means that flow control is advertised in terms = of
>> number of bytes that you can send from that moment.
>>
>>
>> However from the Flow control section:
>>
>> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the s= ender to
>> advertise additional credit by sending the absolute byte offset in= the
>> connection or stream which it is willing to receive."
>>
>> I think that we definitely mean offset here in both cases, i.e. >>
>> MAX_DATA =3D sum of max offset of all streams that are allowed
>>
>> MAX_STREAM_DATA =3D max offset on a stream
>>
>>
>>
>> Yes, that's what the spec means.=C2=A0 I thought it was fairly= clear, but if
>> you think it's confusing, a PR to improve the wording would be= appreciated.
>>
>>
>>
>> Let's say the conn flow control limit of the receiver is 50. A= ll units in
>> multiples of 1024.
>>
>> initial state of receiver
>> stream1 -->=C2=A0 [0, 10]
>> stream2 -->=C2=A0 [0, 20]
>>
>> stream3 -->=C2=A0 [0, 20]
>>
>>
>> So the sender has consumed his entire flow control window. Then th= e
>> receiver consumes 10 (*1024) bytes from stream1:
>>
>> stream1 ---> (10, 10)
>>
>> stream2 ---> [0, 20]
>>
>> stream3 ---> [0, 20]
>>
>>
>>
>> so now the conn window has 10 (*1024) bytes remaining, what does t= he
>> receiver send in their update:
>>
>>
>>
>> MAX_DATA =3D 10
>>
>> or
>>
>> MAX_DATA =3D 60
>>
>>
>>
>> I think we mean 60 here. It makes it much easier to maintain the f= low
>> control in that case.
>>
>>
>>
>> Subodh
>>
>>
>>
>>
>
>

--94eb2c0565c86f7b1f0556bf468c-- From nobody Mon Aug 14 17:00:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8517132455 for ; Mon, 14 Aug 2017 17:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utGHRA9Tygqz for ; Mon, 14 Aug 2017 17:00:21 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D09B132453 for ; Mon, 14 Aug 2017 17:00:21 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id s143so64038797ywg.1 for ; Mon, 14 Aug 2017 17:00:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jjcjzaiMZb7ji9voSuL7cgFYeqdvov0f8D7MI8hsqTU=; b=JXxIaQlCXcvnxPAo/7HWD8mIWjhS0/nmICrLCSuXEMLoJEie1qtZITfMgCyxMm8TEw tk0JKoBJXp9vgNdFFQT4nUmlSLhN+AnUgX25An2RlRvYY2nm9dg3N+B6+M9o4fYLF8lI vJEqolC7bIn6e6gw1STOVpdiRrSsG/o/MZm4VMGDG93tmdhkQRBncZVXTK4oKVDw2ZR9 OhV0fbBEjdmWcelJKAAPEJzmQ88P5Km280EQOaziItiigdqtrjAIqIGyEJXj/FPG+Cv1 GXEvQww7veCq1kIpjgoMkNWtYEvRIGD25mo0viBC2ud8e/W0DZJSBkRLCO0jHieRk/WC Ai5A== 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=jjcjzaiMZb7ji9voSuL7cgFYeqdvov0f8D7MI8hsqTU=; b=GWh+Du0Z3OUpc0i8x8zNOqoSWv1gAtQ8kBqywT74zXmwTrrk3EaqPS38l3qr+XXNeq MhtwNLYfgcExc54uXOKAy2FODAXbReaewyatGiB5/Yjd3/c0F1NiSGGak7acx3b4b6m0 fmb1kacGAlvtULPUGOlGl5Kz0b9CSGIrtrcmgtLJbaxFBgtX8ZPMTK/gcHUp30zHUVCK Q/1OBsQccSi0i0TewPJ2UxoN+O52HmETliIVDsi24vh3DXvsyZWJmTD+j0aATOslg0dn ao0KToNQkPmhZPHn6g79zx1JO4qbkTyyRXdjZMlmZsoUAU/ZfLDLBTnKq2gQC+SoWiRG fejA== X-Gm-Message-State: AHYfb5htUvAmdDFhkuolQkalq/7EKUZLr2DG5bj/zSZLkXqoEArGbbMk 9JvzIv5eJuoJ7zXj/esCza6sTmVgvmSV X-Received: by 10.129.82.146 with SMTP id g140mr20986578ywb.466.1502755219555; Mon, 14 Aug 2017 17:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.207 with HTTP; Mon, 14 Aug 2017 17:00:18 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 14 Aug 2017 17:00:18 -0700 Message-ID: Subject: Re: Splitting transport and application error code spaces To: Martin Thomson Cc: Mike Bishop , QUIC WG Content-Type: multipart/alternative; boundary="001a114dceac0c642a0556bf77a2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 00:00:23 -0000 --001a114dceac0c642a0556bf77a2 Content-Type: text/plain; charset="UTF-8" There's awkwardness in this enforcement. QUIC generates RST_STREAM when it receives a STOP_SENDING frame, and this PR changes that function quite a bit. Specifically, it requires that QUIC send RST_STREAM with an app error code, where this RST_STREAM is in fact triggered by receipt of a STOP_SENDING frame. I'm not sure exactly what this split buys us... and it changes behavior on receiving STOP_SENDING. On Sat, Aug 12, 2017 at 3:04 AM, Martin Thomson wrote: > On 12 August 2017 at 00:42, Mike Bishop > wrote: > > Given that the assigned 0x2 and 0x3 differ by one bit, might it be > clearer > > to have an embedded flag in CONNECTION_CLOSE indicating the source? That > > avoids having two frames with identical semantics except the registry in > > which you look up the value of a field. > > It all amounts to the same thing, and I think that separate types is a > better trend generally. I'm not a huge fan of the mix of discrete > types and bit patterns, preferring the former for the sake of clarity. > > --001a114dceac0c642a0556bf77a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There's awkwardness in this enforcement. QUIC generate= s RST_STREAM when it receives a STOP_SENDING frame, and this PR changes tha= t function quite a bit. Specifically, it requires that QUIC send RST_STREAM= with an app error code, where this RST_STREAM is in fact triggered by rece= ipt of a STOP_SENDING frame.

I'm not sure exactly wh= at this split buys us... and it changes behavior on receiving STOP_SENDING.=


On Sat, Aug 12, 2017 at 3:04 AM, Martin Tho= mson <martin.thomson@gmail.com> wrote:
On 12 August 2017 at 00:42, Mike Bisho= p <Michael.Bishop@micros= oft.com> wrote:
> Given that the assigned 0x2 and 0x3 differ by one bit, might it be cle= arer
> to have an embedded flag in CONNECTION_CLOSE indicating the source?=C2= =A0 That
> avoids having two frames with identical semantics except the registry = in
> which you look up the value of a field.

It all amounts to the same thing, and I think that separate types is= a
better trend generally.=C2=A0 I'm not a huge fan of the mix of discrete=
types and bit patterns, preferring the former for the sake of clarity.


--001a114dceac0c642a0556bf77a2-- From nobody Mon Aug 14 17:11:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4773813245F for ; Mon, 14 Aug 2017 17:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 068zZajAmAis for ; Mon, 14 Aug 2017 17:11:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D4D132463 for ; Mon, 14 Aug 2017 17:11:22 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id s143so64140258ywg.1 for ; Mon, 14 Aug 2017 17:11:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u4Gfz16xQyDSQJ9i2+T1ATKlN2WSHoQT2gK5yzw4yIw=; b=sdGUyUdaPBjypW1KQffEYdKfI8IOXd0dKW/CBX0efH3RQwx3VjR7JQaTaWUNw/hvNp yoySEKbyjE98tyVgOhR4nLxOTVP4VjK/uHwUq3+JqefAkflyjQvMoP57fBAotN8OK2FJ CIJ6t3G996MvWCoYinj1cdqsi3vByMhEy94Xg3PTn4jMkN2eAc1yzE1AlFrlx0cky8BW /JGHd5kTc+b96+5aO28kmIjVxVsbiFeLrYsEJ4lVCI7sg+eP8fxk3NcO8QAfBA9dv9vz LK4RAh6U5TjdsxMwndOR9Ol5w6uyw8rkYxWEERrAbSKopO1IqXQW+M83satyKiHH+F9c 5wiQ== 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=u4Gfz16xQyDSQJ9i2+T1ATKlN2WSHoQT2gK5yzw4yIw=; b=WzRIrxIxIU0rI5DjJ4xvLadryzBx3gRJvdc5Dc+tF01VuHl4KSIsswgDhXhT3kaWjj fM17lkqQk77qV1owtGeO5G/XuW+o5iSFBRAKt5z58IT8YjFh+KWSiyJn5M4MHjPo//6T X/grpvf5GMx738KUbesX6ZKVTytMUl6oJdhgC5M77aDkuygM2Hfm/c45o4ac2DrcGLhK u7mnuuhlYRZW4gi63bkMLc2Vu6hyMD6RgC36ybuL1fAcQuUkDlxkIrtsF3ugPIsgu6UM SW+i5fhI04zme1oTUl6B/Ba6H6OHLlc1M/oU0jl0z7XLilsHCg8SFazepRZV2/sQO5wu zLcg== X-Gm-Message-State: AHYfb5jt9ZL9LhgQG1VXsmszFs5NviLsHW6VZHz/1bprKpKsB8Zfwl38 5PYkaiKFseBLTcksh6hCC4EFSqguPg3n6EA= X-Received: by 10.129.78.146 with SMTP id c140mr21013116ywb.162.1502755881348; Mon, 14 Aug 2017 17:11:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.207 with HTTP; Mon, 14 Aug 2017 17:11:20 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Mon, 14 Aug 2017 17:11:20 -0700 Message-ID: Subject: Re: flow control description in draft To: Martin Thomson Cc: Subodh Iyengar , Mike Bishop , Ian Swett , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114dac8c7e83300556bf9e33" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 00:11:25 -0000 --001a114dac8c7e83300556bf9e33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Aug 14, 2017 at 4:40 PM, Martin Thomson wrote: > I don't think that a characterisation of FIN of "consuming an offset" > is correct. The frame includes an offset, which is the point > *between* octets on the stream. The first octet in the frame (if > present) is immediately after that gap. > > Think of it like this: > > Octets: ,_0_,_1_,_2_,_3_,_4_, > > The offset is at the comma, not the numeral. FIN makes the comma a perio= d. I'm not sure I am following. An offset is on a STREAM frame, and it indicates the offset of the data in the frame. In a pure FIN frame, it still indicates something. Whether you consider this to be an offset consumed or not, it still indicates something. The offset indicated on the STREAM frame is processed per flow-control. The question that the draft is unclear on is whether the offset received on a pure FIN frame is to be considered per flow control or not. I don't think it needs to, but that needs to be articulated in the draft. In your example, a pure FIN frame sent at the end of 5 bytes of data will carry the offset 6. That is now an offset that cannot be used for anything else but that FIN. Which, in my understanding, means that the offset is "consumed" by the FIN. > On 15 August 2017 at 08:23, Jana Iyengar wrote: > > Thanks for bringing this up, Subodh. I agree with Ian and Mike that FIN > does > > not need be included in flow control accounting. The only reason it > consumes > > an offset is the case where it is sent on an empty STREAM frame. But th= is > > does matter for flow control since as Ian pointed out, this byte does n= ot > > consume any buffer space. I'll look at the PR. > > > > On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar wrote: > >> > >> @Mike ya another issue I brought up is that it's actually not > rationalized > >> around offsets right now, the current formulation is around maximum da= ta > >> which is what raised the question of FINs. The PR changes the > formulation to > >> be around offsets. This is discussed in the PR summary. Let me know > what you > >> think. > >> > >> > >> Subodh > >> > >> ________________________________ > >> From: Mike Bishop > >> Sent: Monday, August 14, 2017 12:31:41 PM > >> To: Subodh Iyengar; Ian Swett > >> Cc: quic@ietf.org > >> Subject: RE: flow control description in draft > >> > >> > >> Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming ever= ything is > >> rationalized around offsets, the check is always whether (current > offset) + > >> (payload length) <=3D (allowed offset). Even if (current offset) =3D= =3D > (allowed > >> offset), a STREAM frame that contains only a FIN will have a payload > length > >> of zero, so this will still be true. > >> > >> > >> > >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Subodh Iyengar > >> Sent: Monday, August 14, 2017 12:18 PM > >> To: Ian Swett > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> Ya the complexity of not having FIN as subject to flow control is that > the > >> stream frame scheduler would have special logic for processing FINs > while > >> checking whether it has flow control. This wouldn't be an editorial > issue > >> though and is more of a design issue. I've put up a PR for the design > >> change, if people don't like the change I can put up a PR for only the > >> editorial change instead keeping the current semantics: > >> > >> > >> > >> https://github.com/quicwg/base-drafts/pull/730 > >> > >> > >> > >> Subodh > >> > >> ________________________________ > >> > >> From: QUIC on behalf of Ian Swett > >> > >> Sent: Monday, August 14, 2017 9:49:28 AM > >> To: Subodh Iyengar > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar wrote= : > >> > >> Ya I think the language in the draft could be a bit more clear, will > send > >> out a PR soon. > >> > >> > >> > >> However I have a few more questions that came up: > >> > >> Is FIN not subject to flow control? It seems logical to not subject it > to > >> flow control, but it's a super weird edge case since FIN has it's own > offset > >> :) > >> > >> > >> > >> A fin is not subject to flow control. I guess I think of it taking up > no > >> space, so it doesn't seem like a problem, but I can see your point. > >> > >> > >> > >> Is it max data or max offset. For example if I send you maxData =3D 10= , > can > >> you send until offset 9 or offset 10. I think you mean offset 9. > >> > >> > >> > >> Good point, that seems worth clarifying. > >> > >> Subodh > >> > >> ________________________________ > >> > >> From: Ian Swett > >> Sent: Friday, July 28, 2017 9:57:23 AM > >> To: Subodh Iyengar > >> Cc: quic@ietf.org > >> Subject: Re: flow control description in draft > >> > >> > >> > >> > >> > >> > >> > >> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar wrote= : > >> > >> The flow control language in the draft is a bit confusing right now, > and I > >> could use a bit more clarity on the intention > >> > >> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as > >> > >> "A 64-bit unsigned integer indicating the maximum amount of data that > can > >> be sent on the entire connection, in units of 1024 octets. That is, th= e > >> updated connection-level data limit is determined by multiplying the > encoded > >> value by 1024." > >> > >> This seems like it means that flow control is advertised in terms of > >> number of bytes that you can send from that moment. > >> > >> > >> However from the Flow control section: > >> > >> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the sender to > >> advertise additional credit by sending the absolute byte offset in the > >> connection or stream which it is willing to receive." > >> > >> I think that we definitely mean offset here in both cases, i.e. > >> > >> MAX_DATA =3D sum of max offset of all streams that are allowed > >> > >> MAX_STREAM_DATA =3D max offset on a stream > >> > >> > >> > >> Yes, that's what the spec means. I thought it was fairly clear, but i= f > >> you think it's confusing, a PR to improve the wording would be > appreciated. > >> > >> > >> > >> Let's say the conn flow control limit of the receiver is 50. All units > in > >> multiples of 1024. > >> > >> initial state of receiver > >> stream1 --> [0, 10] > >> stream2 --> [0, 20] > >> > >> stream3 --> [0, 20] > >> > >> > >> So the sender has consumed his entire flow control window. Then the > >> receiver consumes 10 (*1024) bytes from stream1: > >> > >> stream1 ---> (10, 10) > >> > >> stream2 ---> [0, 20] > >> > >> stream3 ---> [0, 20] > >> > >> > >> > >> so now the conn window has 10 (*1024) bytes remaining, what does the > >> receiver send in their update: > >> > >> > >> > >> MAX_DATA =3D 10 > >> > >> or > >> > >> MAX_DATA =3D 60 > >> > >> > >> > >> I think we mean 60 here. It makes it much easier to maintain the flow > >> control in that case. > >> > >> > >> > >> Subodh > >> > >> > >> > >> > > > > > --001a114dac8c7e83300556bf9e33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Aug 14, 2017 at 4:40 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
I don't th= ink that a characterisation of FIN of "consuming an offset"
is correct.=C2=A0 The frame includes an offset, which is the point
*between* octets on the stream.=C2=A0 The first octet in the frame (if
present) is immediately after that gap.

Think of it like this:

Octets:=C2=A0 =C2=A0,_0_,_1_,_2_,_3_,_4_,

The offset is at the comma, not the numeral.=C2=A0 FIN makes the comma a pe= riod.

I'm not sure I am following. An o= ffset is on a STREAM frame, and it indicates the offset of the data in the = frame. In a pure FIN frame, it still indicates something. Whether you consi= der this to be an offset consumed or not, it still indicates something. The= offset indicated on the STREAM frame is processed per flow-control. The qu= estion that the draft is unclear on is whether the offset received on a pur= e FIN frame is to be considered per flow control or not. I don't think = it needs to, but that needs to be articulated in the draft.

<= /div>
In your example, a pure FIN frame sent at the end of 5 bytes of d= ata will carry the offset 6. That is now an offset that cannot be used for = anything else but that FIN. Which, in my understanding, means that the offs= et is "consumed" by the FIN.


On 15 August 2017 at 08:23, Jana Iyengar <jri@google.com> wrote:
> Thanks for bringing this up, Subodh. I agree with Ian and Mike that FI= N does
> not need be included in flow control accounting. The only reason it co= nsumes
> an offset is the case where it is sent on an empty STREAM frame. But t= his
> does matter for flow control since as Ian pointed out, this byte does = not
> consume any buffer space. I'll look at the PR.
>
> On Mon, Aug 14, 2017 at 12:49 PM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> @Mike ya another issue I brought up is that it's actually not = rationalized
>> around offsets right now, the current formulation is around maximu= m data
>> which is what raised the question of FINs. The PR changes the form= ulation to
>> be around offsets. This is discussed in the PR summary. Let me kno= w what you
>> think.
>>
>>
>> Subodh
>>
>> ________________________________
>> From: Mike Bishop <Michael.Bishop@microsoft.com>
>> Sent: Monday, August 14, 2017 12:31:41 PM
>> To: Subodh Iyengar; Ian Swett
>> Cc: quic@ietf.org
>> Subject: RE: flow control description in draft
>>
>>
>> Like Ian, I don=E2=80=99t see this as an issue =E2=80=93 assuming = everything is
>> rationalized around offsets, the check is always whether (current = offset) +
>> (payload length) <=3D (allowed offset).=C2=A0 Even if (current = offset) =3D=3D (allowed
>> offset), a STREAM frame that contains only a FIN will have a paylo= ad length
>> of zero, so this will still be true.
>>
>>
>>
>> From: QUIC [mailto:quic-b= ounces@ietf.org] On Behalf Of Subodh Iyengar
>> Sent: Monday, August 14, 2017 12:18 PM
>> To: Ian Swett <ianswett@= google.com>
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>> Ya the complexity of not having FIN as subject to flow control is = that the
>> stream frame scheduler would have special logic for processing FIN= s while
>> checking whether it has flow control. This wouldn't be an edit= orial issue
>> though and is more of a design issue. I've put up a PR for the= design
>> change, if people don't like the change I can put up a PR for = only the
>> editorial change instead keeping the current semantics:
>>
>>
>>
>> https://github.com/quicwg/base-drafts/pu= ll/730
>>
>>
>>
>> Subodh
>>
>> ________________________________
>>
>> From: QUIC <quic-bounc= es@ietf.org> on behalf of Ian Swett
>> <ianswett@google.com= >
>> Sent: Monday, August 14, 2017 9:49:28 AM
>> To: Subodh Iyengar
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>> On Mon, Aug 14, 2017 at 12:43 PM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> Ya I think the language in the draft could be a bit more clear, wi= ll send
>> out a PR soon.
>>
>>
>>
>> However I have a few more questions that came up:
>>
>> Is FIN not subject to flow control? It seems logical to not subjec= t it to
>> flow control, but it's a super weird edge case since FIN has i= t's own offset
>> :)
>>
>>
>>
>> A fin is not subject to flow control.=C2=A0 I guess I think of it = taking up no
>> space, so it doesn't seem like a problem, but I can see your p= oint.
>>
>>
>>
>> Is it max data or max offset. For example if I send you maxData = =3D 10, can
>> you send until offset 9 or offset 10. I think you mean offset 9. >>
>>
>>
>> Good point, that seems worth clarifying.
>>
>> Subodh
>>
>> ________________________________
>>
>> From: Ian Swett <ianswet= t@google.com>
>> Sent: Friday, July 28, 2017 9:57:23 AM
>> To: Subodh Iyengar
>> Cc: quic@ietf.org
>> Subject: Re: flow control description in draft
>>
>>
>>
>>
>>
>>
>>
>> On Fri, Jul 28, 2017 at 11:18 AM, Subodh Iyengar <subodh@fb.com> wrote:
>>
>> The flow control language in the draft is a bit confusing right no= w, and I
>> could use a bit more clarity on the intention
>>
>> For example in MAX_DATA and MAX_STREAM_DATA the data is defined as=
>>
>> "A 64-bit unsigned integer indicating the maximum amount of d= ata that can
>> be sent on the entire connection, in units of 1024 octets. That is= , the
>> updated connection-level data limit is determined by multiplying t= he encoded
>> value by 1024."
>>
>> This seems like it means that flow control is advertised in terms = of
>> number of bytes that you can send from that moment.
>>
>>
>> However from the Flow control section:
>>
>> "A receiver sends MAX_DATA or MAX_STREAM_DATA frames to the s= ender to
>> advertise additional credit by sending the absolute byte offset in= the
>> connection or stream which it is willing to receive."
>>
>> I think that we definitely mean offset here in both cases, i.e. >>
>> MAX_DATA =3D sum of max offset of all streams that are allowed
>>
>> MAX_STREAM_DATA =3D max offset on a stream
>>
>>
>>
>> Yes, that's what the spec means.=C2=A0 I thought it was fairly= clear, but if
>> you think it's confusing, a PR to improve the wording would be= appreciated.
>>
>>
>>
>> Let's say the conn flow control limit of the receiver is 50. A= ll units in
>> multiples of 1024.
>>
>> initial state of receiver
>> stream1 -->=C2=A0 [0, 10]
>> stream2 -->=C2=A0 [0, 20]
>>
>> stream3 -->=C2=A0 [0, 20]
>>
>>
>> So the sender has consumed his entire flow control window. Then th= e
>> receiver consumes 10 (*1024) bytes from stream1:
>>
>> stream1 ---> (10, 10)
>>
>> stream2 ---> [0, 20]
>>
>> stream3 ---> [0, 20]
>>
>>
>>
>> so now the conn window has 10 (*1024) bytes remaining, what does t= he
>> receiver send in their update:
>>
>>
>>
>> MAX_DATA =3D 10
>>
>> or
>>
>> MAX_DATA =3D 60
>>
>>
>>
>> I think we mean 60 here. It makes it much easier to maintain the f= low
>> control in that case.
>>
>>
>>
>> Subodh
>>
>>
>>
>>
>
>

--001a114dac8c7e83300556bf9e33-- From nobody Mon Aug 14 17:48:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9591E13247C for ; Mon, 14 Aug 2017 17:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzSnw665ZNOm for ; Mon, 14 Aug 2017 17:48:52 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21108132476 for ; Mon, 14 Aug 2017 17:48:52 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id 76so3300494ith.0 for ; Mon, 14 Aug 2017 17:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jv6GRL1+rkovvHs0C3aViBUrh3ldW8r/ZNYatOk4KFI=; b=IzgXrzxZzBEab4R3A6wEzUbX+OEWvUq1OQXFlRioDyRVYGrzvne8IOaUOIeNh5DKCF /j7bO7M2Gesf0BASNgWEAtNOdbWFOw1djBxuUxCB20ziKp011P4KxnwDLWJtR1IwTaCe 0ukziFLfXApISRw0AY7JI6cn8Bt6xAsmfu+o4LZJtFFDY1uhD4tsdjg4EROgDwTxpcCL DGGNybXCsve6O+0j3EXYQiIi7Amo0CzEIKBOwRvjYtOQD7UBm8Pwslv/hrro/qryY1+V jCwct00dQx7HA91grs8LwnQgsPAPtlVdudG8w9wy39TchuA2qnuuK4VmHqtmwDEOXYin y2HQ== 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=Jv6GRL1+rkovvHs0C3aViBUrh3ldW8r/ZNYatOk4KFI=; b=pTbGgIgbkh7ofSwaLbHU70XOrqr0cJodYqunmosDsbj3MGq5hOIJ5+BiCBcEQqcg9S ygUbK/WRjhQy/On9rRMoTYuFo2CpLAAxUOOWBJzCk28d8bQKfjCR9swyMbntrQnsb+4U 7VfzYT2dWGBhCkLgdnpgcck7vou9IikrplJLvmXIvfBAPBPcB8py7HffG4RG2qs/AqFR pW7OfyYWATDZVN1vvknaedegwQ9Xvc5HcA/RCaKpzO70wIy1Dod4A/CIEl93IkDIUXkN lJ2V71f2pDLlVY4qFHEroQGPviyMIkoGEyxCYzAoEV7GB/m/9VajD5vW8cSvPlUSNhAP zGwQ== X-Gm-Message-State: AHYfb5gM00ACXhhUpQOHmH3tmwQ3DqltEqjMYNN6megsxseuXWma2+6c 55Y0UOz9DdwKrzKuHgF13GuT0bN5uw== X-Received: by 10.36.13.10 with SMTP id 10mr738413itx.51.1502758131467; Mon, 14 Aug 2017 17:48:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 14 Aug 2017 17:48:50 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Aug 2017 10:48:50 +1000 Message-ID: Subject: Re: Splitting transport and application error code spaces To: Jana Iyengar Cc: Mike Bishop , 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, 15 Aug 2017 00:48:54 -0000 On 15 August 2017 at 10:00, Jana Iyengar wrote: > I'm not sure exactly what this split buys us... and it changes behavior on > receiving STOP_SENDING. So, what the split buys us is certainty: an application is responsible for the lifetime of streams. In return the application can be certain that the transport won't destroy any state that it puts on streams at a whim. The split enforces this separation. This issue with STOP_SENDING is a good one. I have a solution to that as well: move STOP_SENDING to HTTP. If the required reaction (RST_STREAM), is an application-layer action, then we should make the trigger application-layer as well. From nobody Mon Aug 14 17:54:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7742132476 for ; Mon, 14 Aug 2017 17:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLaOhJaf5IbR for ; Mon, 14 Aug 2017 17:54:01 -0700 (PDT) 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 97E2313246F for ; Mon, 14 Aug 2017 17:54:01 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m88so43563294iod.2 for ; Mon, 14 Aug 2017 17:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+f3OfjjJVYYl1x2s4AKmRfaMx12z7tP0r6+dCvrNEmg=; b=C7Ns8hg3ZLcdxbQ5P695vNhJmFWkaijT6Wz9WhjwBRfXGVglmvWqnElX9k65/polLT CQgYvP1+dUaLhAD85vDnoWl6vlID2jGxDEFioh1G/ToaxGsIvrJxM8BgYc30FN8Cr6Ci LwrXqNLM93HkMbxWsOq/q2cGNpu3xHZbbIwdUYeAiNfigfYAHabyaCjf2vGkeT2w52Tr s03wJ/SxoCAhswU3jy98xTzdeTOhwAhgQI96HSBq4Cq1qD06xz5mCw3cNjFzpUeMMzWl h/A0dp2t+5+thydcWnSKL1rpeB/k4VJeN/GhCNcYEjb4o/WBywPyUeGgRYxwocTueuXz KmAw== 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=+f3OfjjJVYYl1x2s4AKmRfaMx12z7tP0r6+dCvrNEmg=; b=VAidOnfvMUNc4mzPlSe76z4pJHZ/Cphn71mPaYGM78ofh2W+1xVt4+BBbcrDdHlOVb a5wJETBOBCKwIjc3OFC3+hmmQi7enBkcwFDG5J/exxlEXBLzSCzfM+WpPB1NZDZW3lQa 7HYDvt5ztSjdivYJwwoQDW2W7lQbIolsjKJZpk6AYF7ljZF+CkOUlJJAsoi0edFAt3S2 caGceOHtBCKFQwxGnDGrVd2Dp12eoyV/QmIqSCGG3R13aOwSEMFIcqSmaBg/gpf3MbVC tpKIyevJz1XDJxP0dn0a+VF/YAXmFZasHpyrJ5xC5zTqYi5Wf6vbSc2OPcfIcjlhym+o DL2A== X-Gm-Message-State: AHYfb5jinyAo00H830cN5Fmr8n+X8WOvnaLx9l8bfWOPO5oKGtIiYd9R 6Q82sUEUiOlo4jOTBiKlUNoSCzng2w== X-Received: by 10.107.201.65 with SMTP id z62mr23632668iof.74.1502758440944; Mon, 14 Aug 2017 17:54:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Mon, 14 Aug 2017 17:54:00 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Aug 2017 10:54:00 +1000 Message-ID: Subject: Re: flow control description in draft To: Jana Iyengar Cc: Subodh Iyengar , Mike Bishop , Ian Swett , "quic@ietf.org" 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, 15 Aug 2017 00:54:04 -0000 On 15 August 2017 at 10:11, Jana Iyengar wrote: > On Mon, Aug 14, 2017 at 4:40 PM, Martin Thomson > wrote: >> >> I don't think that a characterisation of FIN of "consuming an offset" >> is correct. The frame includes an offset, which is the point >> *between* octets on the stream. The first octet in the frame (if >> present) is immediately after that gap. >> >> Think of it like this: >> >> Octets: ,_0_,_1_,_2_,_3_,_4_, >> >> The offset is at the comma, not the numeral. FIN makes the comma a >> period. > > > I'm not sure I am following. An offset is on a STREAM frame, and it > indicates the offset of the data in the frame. In a pure FIN frame, it still > indicates something. Whether you consider this to be an offset consumed or > not, it still indicates something. The offset indicated on the STREAM frame > is processed per flow-control. The question that the draft is unclear on is > whether the offset received on a pure FIN frame is to be considered per flow > control or not. I don't think it needs to, but that needs to be articulated > in the draft. I thought that conclusion was already implicit in the draft. I'm happy to have it made explicit. > In your example, a pure FIN frame sent at the end of 5 bytes of data will > carry the offset 6. That is now an offset that cannot be used for anything > else but that FIN. Which, in my understanding, means that the offset is > "consumed" by the FIN. The FIN has an offset of 5. 5 octets of data each start at offsets 0, 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame has an offset of 5. I have no idea why an offset would be consumed by declaring the stream complete. What has changed is that you now know how long the stream/message is. Ben Kaduk mentioned C arrays. This is a perfect analogy. If you haven't read up on these before, here's a primer: http://www.cplusplus.com/doc/tutorial/arrays/ From nobody Mon Aug 14 18:06:40 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EEC41321B6 for ; Mon, 14 Aug 2017 18:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZg4aOf7Xhaz for ; Mon, 14 Aug 2017 18:06:36 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AF513246F for ; Mon, 14 Aug 2017 18:06:36 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7F16T9m027924; Tue, 15 Aug 2017 02:06:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=Hzgnjc+X+L+skEwoJarnAGfwZ/Pi2r6aDmdL/xblVzw=; b=Jjuk0HNrsyloWdWuvIqSgzbZ4du/XhEqn+5Z1uQMyrHYRiSbqgpEK1vBW8cAuyZlah0U qFUJ7RcJsLA+gxqs0t+WI3aPqJjRF3sUV+1R4lSH/Sea4UT0LJoZS6ELfpq3kbZvVzA7 suoFuiq9JAWSzF0pu9T+UYwzifZbhpj6avipReJYDEsjgi+9yHlfbUKW3Af0MK4GBxSE 11sMWpUmHWj3n1ZWw/hv5xWF9HXnjnii004MEvrvdH2cLw3JolSQlfom7/Ss3ip+UOik sh+rxFaIgXEEy5YgGJo8CQBE2cqBb5SKbcZ1E6xeG0kQlKNLHztIzjITNL/n2UnJ+7z3 Pg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2cbm8p0e0a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Aug 2017 02:06:29 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7F15Spp026204; Mon, 14 Aug 2017 21:06:28 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2c9w0urwek-1; Mon, 14 Aug 2017 21:06:28 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 5FB461FC71; Tue, 15 Aug 2017 01:06:28 +0000 (GMT) Subject: Re: flow control description in draft To: Martin Thomson , Jana Iyengar Cc: Mike Bishop , Ian Swett , Subodh Iyengar , "quic@ietf.org" References: From: Benjamin Kaduk Message-ID: Date: Mon, 14 Aug 2017 20:06:28 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A39488133D0236BFB93FC014" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708150015 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-14_21:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708150016 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 01:06:39 -0000 This is a multi-part message in MIME format. --------------A39488133D0236BFB93FC014 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/14/2017 07:54 PM, Martin Thomson wrote: > The FIN has an offset of 5. 5 octets of data each start at offsets 0, > 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame > has an offset of 5. > > I have no idea why an offset would be consumed by declaring the stream > complete. What has changed is that you now know how long the > stream/message is. > > Ben Kaduk mentioned C arrays. This is a perfect analogy. If you > haven't read up on these before, here's a primer: > http://www.cplusplus.com/doc/tutorial/arrays/ I had mentioned it offlist, but since summoned, I will note that I was thinking of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/ , which has some advantages in reintroducing symmetry as to which pointer values are defined to compute/dereference, forward/reverse iteration, etc. -Ben --------------A39488133D0236BFB93FC014 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 08/14/2017 07:54 PM, Martin Thomson wrote:
The FIN has an offset of 5.  5 octets of data each start at offsets 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM frame
has an offset of 5.

I have no idea why an offset would be consumed by declaring the stream
complete.  What has changed is that you now know how long the
stream/message is.

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.cplusplus.com/doc/tutorial/arrays/

I had mentioned it offlist, but since summoned, I will note that I was thinking of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/ , which has some advantages in reintroducing symmetry as to which pointer values are defined to compute/dereference, forward/reverse iteration, etc.

-Ben
--------------A39488133D0236BFB93FC014-- From nobody Mon Aug 14 19:56:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698A11324AB for ; Mon, 14 Aug 2017 19:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 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, 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=CARjk0Mo; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=N1NAAhjh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCpyAlQdXyy9 for ; Mon, 14 Aug 2017 19:56:36 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614081324A1 for ; Mon, 14 Aug 2017 19:56:36 -0700 (PDT) Received: from pps.filterd (m0109334.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7F2qWb7019378; Mon, 14 Aug 2017 19:56:32 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=wNyVLWrQO02i8tH+wTxgsdakXUMlDxFbI9ygWOI1wQc=; b=CARjk0MoOTpYMHhv3s5AC4HZxmC1aAPVvCuEDm+7uShCuirMxcC+0h1E8taDXn8zAQ6T 3uze/xUKMIstIfiRRFRW1kyeAapkdHYRpXpnoMNagD4hAeuN3e2FUAahQ9PTChJUw5lh Hu/UCcn6inZ4rJta77Zs+bZR0+aScSZmy4o= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cbkca0ugn-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 14 Aug 2017 19:56:32 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 14 Aug 2017 22:56:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wNyVLWrQO02i8tH+wTxgsdakXUMlDxFbI9ygWOI1wQc=; b=N1NAAhjh56nPJ24U5x/q80pHbcaGpaBpGnkbJcUxdGRdcK+nmn2wash0fOP60HLIKOVLUYn2GjHUqge24qiL9dxrv6DTQzDoPBwaHVhHchaQUImuHrGhhNltLVXaKlXUod9+vHk2L7X/HgZUdhHYDIyu+iIZ8e7Sya7pX2ec1MY= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1456.namprd15.prod.outlook.com (10.173.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.21; Tue, 15 Aug 2017 02:56:27 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.01.1341.020; Tue, 15 Aug 2017 02:56:27 +0000 From: Subodh Iyengar To: Benjamin Kaduk , Martin Thomson , Jana Iyengar CC: Mike Bishop , Ian Swett , "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/CAAAXE8YAAK4CAgAAVf4CAAAiTAIAAC+wAgAADewCAABjwQA== Date: Tue, 15 Aug 2017 02:56:27 +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::1:da76] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1456; 20:2JMTFNS8qeCEjBvroUaqeONUpF8JtILt3SC1bEDN2J9NU/VGn7hX1noZiFpWEK71EX3/iJj0PjRXyMqCcXSqdPdYe5OJAkCtfYsFHsIih8iUshqcuJm4LIf6AijYzSOYLNPNvpgqKfJEnzejUi2UA6eKi24RnYIZ4JK5EmUFpCs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d31e1910-3f25-4630-34e8-08d4e3893923 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1456; x-ms-traffictypediagnostic: MWHPR15MB1456: x-exchange-antispam-report-test: UriScan:(10436049006162); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1456; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1456; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(377454003)(24454002)(199003)(8936002)(68736007)(966005)(105586002)(77096006)(189998001)(19627405001)(101416001)(6506006)(76176999)(6436002)(50986999)(54356999)(14454004)(106356001)(229853002)(4326008)(8676002)(33656002)(93886004)(39060400002)(81156014)(81166006)(7736002)(99286003)(236005)(97736004)(53936002)(53546010)(9686003)(54896002)(6306002)(54906002)(2950100002)(606006)(478600001)(8666007)(6246003)(55016002)(86362001)(3660700001)(102836003)(5660300001)(6116002)(25786009)(3280700002)(2906002)(7696004)(74316002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1456; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455E9EEA228A8BC7920C636B68D0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 02:56:27.3465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1456 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-15_01:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 02:56:38 -0000 --_000_MWHPR15MB1455E9EEA228A8BC7920C636B68D0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ya I think Jana probably just made a typo in saying 6, it would clearly be = 5. I see your point here though, that is only data has offsets, FIN just commu= nicates how much data was sent. Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with some sort of editorial change which changes the name of final Offset to be = called Written Bytes. I've updated the PR to reflect some of this discussion. The PR should now b= e editorial. Subodh ________________________________ From: Benjamin Kaduk Sent: Monday, August 14, 2017 6:06:28 PM To: Martin Thomson; Jana Iyengar Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org Subject: Re: flow control description in draft On 08/14/2017 07:54 PM, Martin Thomson wrote: The FIN has an offset of 5. 5 octets of data each start at offsets 0, 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame has an offset of 5. I have no idea why an offset would be consumed by declaring the stream complete. What has changed is that you now know how long the stream/message is. Ben Kaduk mentioned C arrays. This is a perfect analogy. If you haven't read up on these before, here's a primer: http://www.cplusplus.com/doc/tutorial/arrays/ I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-b= etween-elements/ , which has some advantages in reintroducing symmetry as to which pointer= values are defined to compute/dereference, forward/reverse iteration, etc. -Ben --_000_MWHPR15MB1455E9EEA228A8BC7920C636B68D0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ya I think Jana probably just made a typo in saying 6, it would clearly = be 5.


I see your point here though, that is only data has offsets, FIN just co= mmunicates how much data was sent.
Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with

some sort of editorial change which changes the name of final Offset to = be called Written Bytes.

I've updated the PR to reflect some of this discussion. The PR should now b= e editorial.


Subodh 

From: Benjamin Kaduk <bk= aduk@akamai.com>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org
Subject: Re: flow control description in draft
 
On 08/14/2017 07:54 PM, Martin Thomson wrote:
The FIN has an offset of 5.  5 octets of data each start at =
offsets 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM frame
has an offset of 5.

I have no idea why an offset would be consumed by declaring the stream
complete.  What has changed is that you now know how long the
stream/message is.

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.cplusplus.co=
m/doc/tutorial/arrays/

I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/ , whic= h has some advantages in reintroducing symmetry as to which pointer values = are defined to compute/dereference, forward/reverse iteration, etc.

-Ben
--_000_MWHPR15MB1455E9EEA228A8BC7920C636B68D0MWHPR15MB1455namp_-- From nobody Mon Aug 14 23:52:57 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5DC41324AC for ; Mon, 14 Aug 2017 23:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ZTf-1FLkrT6f for ; Mon, 14 Aug 2017 23:52:53 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0137.outbound.protection.outlook.com [104.47.42.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4F0124234 for ; Mon, 14 Aug 2017 23:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=syKnQMe4OTOVfEveQXbRSEmKCuSoLtfDKtd3twRYXZ4=; b=k28Abb0B0DWe4RlQ8HnUBz337S3EdUpPgYDBybBD5xA0pCFd52deTJ962UCoA+Xxuy1VC/FPMBgSlk49A0PxmKCeQn5uLtD1jiuKIfzUfu9sNRPhMA3UviA6ePnwVw3DCeqyimddnE1Vn/huxReIV+ANnMqIbaiPholAFhYNuN4= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0510.namprd21.prod.outlook.com (10.172.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.8; Tue, 15 Aug 2017 06:52:51 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1385.000; Tue, 15 Aug 2017 06:52:51 +0000 From: Mike Bishop To: Martin Thomson , Jana Iyengar CC: QUIC WG Subject: RE: Splitting transport and application error code spaces Thread-Topic: Splitting transport and application error code spaces Thread-Index: AQHTEmRSPsl9gZnFJ0aVX2eLrEQ0JKJ/O0rXgAFEn4CABA5DAIAADZAAgABk9xA= Date: Tue, 15 Aug 2017 06:52: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: [2601:600:8080:5a28:39b2:9ce8:c7eb:c810] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0510; 6:c/S1vGH63RHJNC0qz77EVfNUxLkSWyjSsC3GZEcra4tBoof5vmOBytF5/U/a+au8P7Rap3KVNoAcHW6Sxrk5X9I6FYcbtpYnZ/dnc3mIo2YkOF1+jnEPoiybOcBGHBwhDcYyamjMrBATElNoSMohfDcuhucB87FjKiKnaMSr9jW0h12ePJKUfikd7X//5xKdZtkCYA+rGM7LPj8+34vnra5bpvOs2r0xKIrz2iMv7DBzfQfq/xgrTJnO8AXZedeurhXPgw/FaDBP0OMH5c/20agtfgkup6X5+eZaXTLQuHNPlrsB9Kw7Jbdkjlg0hRYXc9YPpLgzrBD6izwUcVwZvA==; 5:u5HtT2jOwPz2kuPIi3FyNmxvy1ETjUHcB3/u83YOpryjXNLzktjmjfIRfzOItO3FjCA4dbT5a0g7u8crC5i3rSIJ02369HvDGC8tiNjhdGQGa6FlKCffROihzqLiH4jKa4zQ9yAUhQ9fLxEH7Ce+wg==; 24:uvtnP+oylPAFDCNP/lt9XL4MxkT2bHaIUbO5PtOlM9h8cshvmjJYZ9TrKYFTF1irE2tJPfP14cEFlGfB00yyucw+eGyl+bbkwQV+zPnjO8U=; 7:drwnjIz4Bf2Uh1Q1BlmxHLScZtkrt/lvPWpVY6NMjmFB/iqiN9zTcnxna5rLweCZ6c0hdCPc1FS0QQVYE4/ZYcmWyiTr7rGVFUB0Nku48NRT9pBMVfK6eqLKx/DIKhmioDOqItVoTmel0Yslpb1Ake2CvwQ5NbWWzB5pwb/wnAwyG5uQ3HOKgBcGUNeKDmey64ooGfcX+P+XFN/r02mU0Lx2jtHMgf8aNiB/U1njmDo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 78c456dc-ea05-4dd7-7e64-08d4e3aa3fa7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603144)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0510; x-ms-traffictypediagnostic: MWHPR21MB0510: x-exchange-antispam-report-test: UriScan:(89211679590171)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0510; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0510; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(199003)(377454003)(13464003)(189002)(24454002)(97736004)(50986999)(76176999)(5005710100001)(189998001)(34040400001)(229853002)(7736002)(74316002)(8990500004)(101416001)(2900100001)(54356999)(86362001)(86612001)(10290500003)(2906002)(68736007)(39060400002)(478600001)(6506006)(305945005)(4326008)(3280700002)(77096006)(25786009)(53546010)(3660700001)(10090500001)(6246003)(7696004)(53936002)(72206003)(5660300001)(106356001)(105586002)(6116002)(102836003)(6436002)(93886004)(2950100002)(99286003)(81166006)(81156014)(8936002)(8676002)(55016002)(14454004)(9686003)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0510; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 06:52:51.5782 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0510 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 06:52:56 -0000 SSdtIGEgbGl0dGxlIHVuaGFwcHkgYWJvdXQgdGhhdCBvbmUuICBJIHNlZSB0aGUgbG9naWMsIGJ1 dCB0aGF0IHdvdWxkIGxlYXZlIGVhY2ggZGlyZWN0aW9uIG9mIGEgc3RyZWFtIHNvbGVseSBpbiB0 aGUgaGFuZHMgb2YgdGhlIHNlbmRlciBhbmQgdGhlIHJlY2VpdmVyIGhhcyBubyB3YXkgdG8gY29t bXVuaWNhdGUgKGF0IHRoZSB0cmFuc3BvcnQgbGF5ZXIpIGlmIGl0IHdpc2hlcyB0aGF0IHN0cmVh bSB0byBjZWFzZS4gIChPdGhlciwgcGVyaGFwcywgdGhhbiBzdGFydmluZyBpdCB2aWEgZmxvdyBj b250cm9sLikgIFRob3VnaCBJIGFncmVlLCBpdCBpcyBjb25zaXN0ZW50IHdpdGggdGhlIHByaW5j aXBsZSB0aGF0IHN0cmVhbSBsaWZldGltZSBpcyBlbnRpcmVseSBpbiB0aGUgaGFuZHMgb2YgdGhl IGFwcGxpY2F0aW9uLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGlu IFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogTW9uZGF5 LCBBdWd1c3QgMTQsIDIwMTcgNTo0OSBQTQ0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5j b20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBRVUlD IFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFNwbGl0dGluZyB0cmFuc3BvcnQgYW5k IGFwcGxpY2F0aW9uIGVycm9yIGNvZGUgc3BhY2VzDQoNCk9uIDE1IEF1Z3VzdCAyMDE3IGF0IDEw OjAwLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPiB3cm90ZToNCj4gSSdtIG5vdCBzdXJl IGV4YWN0bHkgd2hhdCB0aGlzIHNwbGl0IGJ1eXMgdXMuLi4gYW5kIGl0IGNoYW5nZXMgDQo+IGJl aGF2aW9yIG9uIHJlY2VpdmluZyBTVE9QX1NFTkRJTkcuDQoNClNvLCB3aGF0IHRoZSBzcGxpdCBi dXlzIHVzIGlzIGNlcnRhaW50eTogYW4gYXBwbGljYXRpb24gaXMgcmVzcG9uc2libGUgZm9yIHRo ZSBsaWZldGltZSBvZiBzdHJlYW1zLiAgSW4gcmV0dXJuIHRoZSBhcHBsaWNhdGlvbiBjYW4gYmUg Y2VydGFpbiB0aGF0IHRoZSB0cmFuc3BvcnQgd29uJ3QgZGVzdHJveSBhbnkgc3RhdGUgdGhhdCBp dCBwdXRzIG9uIHN0cmVhbXMgYXQgYSB3aGltLiAgVGhlIHNwbGl0IGVuZm9yY2VzIHRoaXMgc2Vw YXJhdGlvbi4NCg0KVGhpcyBpc3N1ZSB3aXRoIFNUT1BfU0VORElORyBpcyBhIGdvb2Qgb25lLiAg SSBoYXZlIGEgc29sdXRpb24gdG8gdGhhdCBhcyB3ZWxsOiBtb3ZlIFNUT1BfU0VORElORyB0byBI VFRQLiAgSWYgdGhlIHJlcXVpcmVkIHJlYWN0aW9uIChSU1RfU1RSRUFNKSwgaXMgYW4gYXBwbGlj YXRpb24tbGF5ZXIgYWN0aW9uLCB0aGVuIHdlIHNob3VsZCBtYWtlIHRoZSB0cmlnZ2VyIGFwcGxp Y2F0aW9uLWxheWVyIGFzIHdlbGwuDQo= From nobody Tue Aug 15 16:08:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B551D132439 for ; Tue, 15 Aug 2017 16:08:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ftot5L_SZ-zW for ; Tue, 15 Aug 2017 16:08:22 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0117.outbound.protection.outlook.com [104.47.40.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3FB1132441 for ; Tue, 15 Aug 2017 16:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aJX5s9Utf8e8XzSq82TSUK2mP6YocdvhYCP0JvAHcXI=; b=SGPM/w6Uu6aCTyfTG73kR0TMFEiF6OBtCzYn0HRa0n/d32Aa+D3OPnlownoTHhjEjfzPht8p24W0NqQYjcRPWstRNClmHJClps6yfMXZG+0qXUewn9rjK3du0IO7AzPsGL1E1Q3NnmAABaMJccBGVjZWkcQ2ZMJankwUY/FgqTs= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0287.namprd21.prod.outlook.com (10.173.53.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.6; Tue, 15 Aug 2017 23:08:20 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.01.1385.000; Tue, 15 Aug 2017 23:08:20 +0000 From: Mike Bishop To: Subodh Iyengar , Benjamin Kaduk , "Martin Thomson" , Jana Iyengar CC: Ian Swett , "quic@ietf.org" Subject: RE: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/CAAAXE8YAAK4CAgAAVf4CAAAiTAIAAC+wAgAADewCAABjwQIABVxhw Date: Tue, 15 Aug 2017 23:08:20 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:b::35c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0287; 6:3fPJY2iaZQN83+dhQqc9fUQliAQo2MCXeyJHbg1XIfKJ/O4IpGyiwZNGs7ed1CiMG67b6n+duMquQW//9mTkUx7CqsrR4i9rJSYSTMZt5znnw0NEfJ49pE5ik0VGyOmRKkxlKnCQOB3jP4pEfUuY+iCvBn8pSkEgh7OoLpMsvGBlwFW5kGczDhBeBwmbI9hRcdpu4mv5gYGOXuINsEnMyLK6J2J29qEZ829asGgnR4WJMz3qBMiv6+E7fCTJ6ZyLXNbfbtFUmPdzZgxKfo87wx6oPpH8ZVMaD6Po8vKGg942yhU4h/y97n1HlF8Ja7bdcr6tP+9F3Yte+2/YRq9g/g==; 5:bXOMmwfUbw7L3pgjyzkzYPqaB7M/x1oP/QnvVHkv0XOX+uUNQW1Fq+yBYwq5n45GIEQ/+IDPUb35k6r6QxMglKlOGhbuF4Wxyh9pCTXmHzfQbxyK4yQhjNVf81zz65Qfc3//nf/FD9BOKAFCR7uEmA==; 24:XQgZ40N3+Rbp4JImRYc6Y1gCsCTWwQc+wD4kkAWfmbf2fYS4eMHLU6ai1rng7UYS7wA5P3wXQ6r3BgUzkQCGEGJgrdUamc3VXkYeXVPJgbU=; 7:iA1aaCpbn9lyCZDkgs0CfuIdCAWl34j9ldUtjy+eU5Log7dkcaR+K0EhORIudGD2EKVpQGdiovxuTVpquj2q4KOjg3gzIuKuu2S0/8QZXpkqQxhTu+feTiTL9ErUIK3jRktzGjOox2KbA+uG8+H2g5OCITc0XF3gXEZvQ9z1T3WQfkZB892b8IafEf0JDocZp/eeV73WAxl50Zg3Jy5MniMZW3ZHMCWoyFFm4A082LQ= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8f9bede4-0515-4117-4bb4-08d4e43285b6 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603149)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0287; x-ms-traffictypediagnostic: MWHPR21MB0287: x-exchange-antispam-report-test: UriScan:(89211679590171)(189930954265078)(67672495146484)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(920507026)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0287; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0287; x-forefront-prvs: 04004D94E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(47760400005)(24454002)(377454003)(189002)(199003)(2906002)(54356999)(76176999)(6246003)(50986999)(14454004)(7696004)(39060400002)(53376002)(93886004)(72206003)(53366004)(102836003)(790700001)(6116002)(99286003)(55016002)(606006)(478600001)(9686003)(6306002)(54896002)(54906002)(5005710100001)(966005)(74316002)(5660300001)(34040400001)(53936002)(101416001)(2900100001)(8990500004)(33656002)(7066003)(236005)(53546010)(10290500003)(106356001)(105586002)(3660700001)(7736002)(81156014)(3280700002)(81166006)(8676002)(8936002)(97736004)(68736007)(2950100002)(189998001)(25786009)(86612001)(10090500001)(77096006)(6436002)(6506006)(86362001)(4326008)(229853002)(10090945008); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0287; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01417E91753955E96BA576CA878D0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2017 23:08:20.7803 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0287 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 23:08:26 -0000 --_000_MWHPR21MB01417E91753955E96BA576CA878D0MWHPR21MB0141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per discussion on the editor's call today: If I say you're allowed to send= up to 10, that means you MUST NOT send anything in position 10. Otherwise= stated, both FINs and flow control limits reference the line between posit= ions and are [0,N), as in Ben's excellent link below. As a result, we need to update the text to talk not so much about offsets i= n flow control as total amount of data, since that appears to be clearer. Ben, thanks for clarifying our thinking here. From: Subodh Iyengar [mailto:subodh@fb.com] Sent: Monday, August 14, 2017 7:56 PM To: Benjamin Kaduk ; Martin Thomson ; Jana Iyengar Cc: Mike Bishop ; Ian Swett ; quic@ietf.org Subject: Re: flow control description in draft You don't often get email from SUBODH@FB.COM. Learn w= hy this is important Feedback Ya I think Jana probably just made a typo in saying 6, it would clearly be = 5. I see your point here though, that is only data has offsets, FIN just commu= nicates how much data was sent. Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with some sort of editorial change which changes the name of final Offset to be = called Written Bytes. I've updated the PR to reflect some of this discussion. The PR should now b= e editorial. Subodh ________________________________ From: Benjamin Kaduk > Sent: Monday, August 14, 2017 6:06:28 PM To: Martin Thomson; Jana Iyengar Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org Subject: Re: flow control description in draft On 08/14/2017 07:54 PM, Martin Thomson wrote: The FIN has an offset of 5. 5 octets of data each start at offsets 0, 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame has an offset of 5. I have no idea why an offset would be consumed by declaring the stream complete. What has changed is that you now know how long the stream/message is. Ben Kaduk mentioned C arrays. This is a perfect analogy. If you haven't read up on these before, here's a primer: http://www.cplusplus.com/doc/tutorial/arrays/ I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-b= etween-elements/ , = which has some advantages in reintroducing symmetry as to which pointer val= ues are defined to compute/dereference, forward/reverse iteration, etc. -Ben --_000_MWHPR21MB01417E91753955E96BA576CA878D0MWHPR21MB0141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per discussion on t= he editor’s call today:  If I say you’re allowed to send u= p to 10, that means you MUST NOT send anything in position 10.  Otherw= ise stated, both FINs and flow control limits reference the line between positions and are [0,N), as in Ben’s excellent link bel= ow.

 

As a result, we nee= d to update the text to talk not so much about offsets in flow control as t= otal amount of data, since that appears to be clearer.

 

Ben, thanks for cla= rifying our thinking here.

 

From:= Subodh Iyengar [mailto:subodh@fb.com]
Sent: Monday, August 14, 2017 7:56 PM
To: Benjamin Kaduk <bkaduk@akamai.com>; Martin Thomson <mar= tin.thomson@gmail.com>; Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ian Swett <= ianswett@google.com>; quic@ietf.org
Subject: Re: flow control description in draft

 

You don't often get email from SUBODH@FB.COM. Learn why this is important

Feedback

Ya I think Jana probably just made a ty= po in saying 6, it would clearly be 5.

 

I see your point here though, that is o= nly data has offsets, FIN just communicates how much data was sent.
Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with=

some sort of editorial change which cha= nges the name of final Offset to be called Written Bytes.

I've updated the PR to reflect some of this discussion. The PR should now b= e editorial.

 

Subodh 

From: Benjamin Kaduk <bkaduk@akamai.com>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org
Subject: Re: flow control description in draft

 

On 08/14/2017 07:54 PM, Martin Thomson wrote:

The FIN has an offset of 5.  5 octets of data each start at offse=
ts 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM fra=
me
has an offset of 5.
 
I have no idea why an offset would be consumed by declaring the stream=

complete.  What has changed is that you now know how long the
stream/message is.
 
Ben Kaduk mentioned C arrays.  This is a perfect analogy.  I=
f you
haven't read up on these before, here's a primer:
http://www.cpl=
usplus.com/doc/tutorial/arrays/


I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/ , whic= h has some advantages in reintroducing symmetry as to which pointer values = are defined to compute/dereference, forward/reverse iteration, etc.

-Ben

--_000_MWHPR21MB01417E91753955E96BA576CA878D0MWHPR21MB0141namp_-- From nobody Tue Aug 15 16:13:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55155132444 for ; Tue, 15 Aug 2017 16:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZJ2blL1AgCn for ; Tue, 15 Aug 2017 16:13:48 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD968132441 for ; Tue, 15 Aug 2017 16:13:48 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id l82so13331700ywc.2 for ; Tue, 15 Aug 2017 16:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iwM5EbjR9nGXOVO2RyjSx6Rk5mtaq7cClqWIXIOA7Lc=; b=aSoHcAYq2zUOBP+tk7G01oOUI3rpalgBO4Y1U8npC5PkHQyxpgaiDDum6aUy08WLWd 9PAGj7J2kZe/X/qsBPh+CApPLjCXWdoa/s7bzRiPRpU8uO7Mj/Hy60uD/d6Lm/4KFvKh S1X4OJb2xY7EvQW4iYQbDl+6W2qsKovUpNDbrGvMy09ujhgf8FmPLYi1s7gEHdB+g3Ge syAp+n/FRaQFpIi8BjDEaY1pnlfd6BV9rV9XkkE3D6jjSb6Byb1y1e4OowHpIVSk1Ti5 20bSgZxAQl1MYcCBTyUNQEaxumaTQKQpx/LccdFRsahqu3U+e/UJrG7Hhwg0eNE7aV+m j5OQ== 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=iwM5EbjR9nGXOVO2RyjSx6Rk5mtaq7cClqWIXIOA7Lc=; b=i5G1WrKzHZJYTBuq1rt9DmTissbp6S7a+YssMEd9acVZbjmUXQJUNP1hq44Es1ycnx xT5x3Jy7EfVzS6Xvhfqnr/e+Vq8t+agWCkcDL0b09sYyf/1xP+AOLvwPA1tqQihG/UMr LewpPu8gwkP06CGMdKaWMvdVcLepE6r93GfOFGu4tQ9Alv4UmHFthFGcdi2mB4TSJOd4 jKSjWjLg7VNK/XYCvRIGHj3qviW33b2yJN2H1Vv722btXpbWmjg9fE9Od1AststTrYuK 2skgCXu/sMgl17Mv3gtQIYNLz/FWRLkQGO0jK0mvdNQId1aMpso8xGVGG39A/jbclACp XGwQ== X-Gm-Message-State: AHYfb5jEUK93vqt+cCzpn+by3KYN6Q+ONFiaOrd40oaGRTRok68RdqZb rWhdo3F0XZdalxhyX3yS/znK8R5agEJm X-Received: by 10.37.214.214 with SMTP id n205mr25237767ybg.233.1502838827639; Tue, 15 Aug 2017 16:13:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.207 with HTTP; Tue, 15 Aug 2017 16:13:46 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 15 Aug 2017 16:13:46 -0700 Message-ID: Subject: Re: flow control description in draft To: Subodh Iyengar Cc: Benjamin Kaduk , Martin Thomson , Mike Bishop , Ian Swett , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c065a407a9de90556d2ee06" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 23:13:51 -0000 --94eb2c065a407a9de90556d2ee06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, Martin I know what arrays are. BTW, the reference you sent for C arrays is incorrect, here's a better one :-) Thanks, Ben, for the blog post: I like that articulation. My apologies: I was legitimately confused because TCP consumes a sequence number for both the SYN and the FIN, and I keep reverting to old behavior. TCP consumes a number for reliability purposes (so that a receiver can ACK these bits), but QUIC does not need to do this on stream FINs and stream offsets, since these aren't about reliability, they're about receive-ordering. I agree that FIN does not need to consume an offset, so there needs to be no provision in flow control for it. Given that, I'll look at the PR to see if it helps clarify this point further. On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar wrote: > Ya I think Jana probably just made a typo in saying 6, it would clearly b= e > 5. > > I see your point here though, that is only data has offsets, FIN just > communicates how much data was sent. > Even though this value is encoded in an offset field, it's not really an > offset. I think this point could be better illustrated with > > some sort of editorial change which changes the name of final Offset to b= e > called Written Bytes. > > I've updated the PR to reflect some of this discussion. The PR should now > be editorial. > > > Subodh > ------------------------------ > *From:* Benjamin Kaduk > *Sent:* Monday, August 14, 2017 6:06:28 PM > *To:* Martin Thomson; Jana Iyengar > *Cc:* Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org > *Subject:* Re: flow control description in draft > > On 08/14/2017 07:54 PM, Martin Thomson wrote: > > The FIN has an offset of 5. 5 octets of data each start at offsets 0, > 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame > has an offset of 5. > > I have no idea why an offset would be consumed by declaring the stream > complete. What has changed is that you now know how long the > stream/message is. > > Ben Kaduk mentioned C arrays. This is a perfect analogy. If you > haven't read up on these before, here's a primer:http://www.cplusplus.com= /doc/tutorial/arrays/ > > > I had mentioned it offlist, but since summoned, I will note that I was > thinking of a description like https://blog.nelhage.com/2015/ > 08/indices-point-between-elements/ > > , which has some advantages in reintroducing symmetry as to which pointer > values are defined to compute/dereference, forward/reverse iteration, etc= . > > -Ben > --94eb2c065a407a9de90556d2ee06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, Martin I know what arrays are. BTW, the reference you= sent for C arrays is incorrect, here's a better one :-)=C2=A0
Thank= s, Ben, for the blog post: I like that articulation.

My = apologies: I was legitimately confused because TCP consumes a sequence numb= er for both the SYN and the FIN, and I keep reverting to old behavior. TCP = consumes a number for reliability purposes (so that a receiver can ACK thes= e bits), but QUIC does not need to do this on stream FINs and stream offset= s, since these aren't about reliability, they're about receive-orde= ring.

I agree that FIN does not need to consume an= offset, so there needs to be no provision in flow control for it. Given th= at, I'll look at the PR to see if it helps clarify this point further.<= /div>


On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar <subodh@fb.c= om> wrote:

Ya I think Jana probably just made a typo in saying 6, it would clearly = be 5.


I see your point here though, that is only data has offsets, FIN just co= mmunicates how much data was sent.
Even though this value is encoded in an offset field, it's not really a= n offset. I think this point could be better illustrated with

some sort of editorial change which changes the name of final Offset to = be called Written Bytes.

I've updated the PR to reflect some of this discussion. The PR should n= ow be editorial.


Subodh=C2=A0

From: Be= njamin Kaduk <bka= duk@akamai.com>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org
Subject: Re: flow control description in draft
=C2=A0
On 08/14/2017 07:54 PM, Martin Thomson wrote:
The FIN has an offset of 5.  5 octets of data each start at offsets 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM frame
has an offset of 5.

I have no idea why an offset would be consumed by declaring the stream
complete.  What has changed is that you now know how long the
stream/message is.

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.=
cplusplus.com/doc/tutorial/arrays/

I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/<= /a> , which has some advantages in reintroducing symmetry as to which point= er values are defined to compute/dereference, forward/reverse iteration, et= c.

-Ben

--94eb2c065a407a9de90556d2ee06-- From nobody Tue Aug 15 16:57:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A0A1323AC for ; Tue, 15 Aug 2017 16:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mYD7DqFjEgR for ; Tue, 15 Aug 2017 16:57:06 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A6213232D for ; Tue, 15 Aug 2017 16:57:05 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s143so13744287ywg.1 for ; Tue, 15 Aug 2017 16:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTRG+QawkU851YqAGyhCtMcHqKpAq3kOsaz4l1OYh1g=; b=cYulcYjcU9HQ/zphQXn/HHHjD1wr/A/nBumKPeUW5zmvZ920MHqIX38EJ9b51z7Iwd C+cU6KmTsW4CyBS6rvkNqnf1iESlZaQ15w/GdNqnIRCaUGS6Xea6TeWSRBScW0cmsJkk JBj02TxVZypkTGricvLx15QkRQ8obkxZG/F3c9AgBrKfFOR8ZFUOVB/bTqnegNINIUfR IwQr1XPBC46+wGQPMAm8ojkj7U6aFbKzJZV1vnNeE2lsAVK0K28gkVnkHTCExgFz9YgC gRroLS4qm9jsSYVG0IosX9lqwjORg1niyuyAMVJ2gZHL6q9gv4K7ErVwqHZy4K0dtGIn 62Bw== 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=nTRG+QawkU851YqAGyhCtMcHqKpAq3kOsaz4l1OYh1g=; b=KzNAejitCZEIVeP0HKcVeb4UJNbF3dIPQDYK5ADIv0e+Yoj8tERmq1XqKVoEjkwkM7 vjeTYbvTJ3D1DmSsUJSgqeGNJFyTUZpV2c8nwqrAKNqFHpMh4pmJs7QfDIS9XKQWUJ1v /ec/eFPNpXpwUhjIe9T6zNAjFIFA8xp5HFQknEL4sChuLEeo3lCDGWcS/aruhaYYDXWq n2Nt8/7vI8RU0A+Uh0sBWF+glAksC2fzBqNnO29yZ33gULkeX0SlSBXiYRLVH7Sbj+sa OuO2bdzVFZgUsdNRZtXR3XwjE4GVSE0wgcrEZOvyzv2v7JPQglgvjjb2/XRFhRvEAgz2 Jliw== X-Gm-Message-State: AHYfb5g6WyPTn/LGYbF5uApLoTr4Vf6Gfou/Yzv+tMXoOKem+A0kQCpl l+WI58ZLLKVQjEpeycu/F3NN4eDzES9S X-Received: by 10.129.68.25 with SMTP id r25mr24073831ywa.275.1502841424871; Tue, 15 Aug 2017 16:57:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.170.207 with HTTP; Tue, 15 Aug 2017 16:57:04 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Tue, 15 Aug 2017 16:57:04 -0700 Message-ID: Subject: Re: Splitting transport and application error code spaces To: Mike Bishop Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="f403045eb7f44925a00556d3891a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 15 Aug 2017 23:57:08 -0000 --f403045eb7f44925a00556d3891a Content-Type: text/plain; charset="UTF-8" I like the idea of moving STOP_SENDING to the application entirely. It's basically an HTTP/2 thing anyway, so that seems like an excellent clean-up. Mike: QUIC currently does not use RST_STREAM without the application asking for it outside of responding to STOP_SENDING; do you think there are conditions under which it may be useful for the transport to issue one? STOP_SENDING was the only thing I could think of, but moving it up to HTTP makes that moot. On Mon, Aug 14, 2017 at 11:52 PM, Mike Bishop wrote: > I'm a little unhappy about that one. I see the logic, but that would > leave each direction of a stream solely in the hands of the sender and the > receiver has no way to communicate (at the transport layer) if it wishes > that stream to cease. (Other, perhaps, than starving it via flow > control.) Though I agree, it is consistent with the principle that stream > lifetime is entirely in the hands of the application. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, August 14, 2017 5:49 PM > To: Jana Iyengar > Cc: Mike Bishop ; QUIC WG > Subject: Re: Splitting transport and application error code spaces > > On 15 August 2017 at 10:00, Jana Iyengar wrote: > > I'm not sure exactly what this split buys us... and it changes > > behavior on receiving STOP_SENDING. > > So, what the split buys us is certainty: an application is responsible for > the lifetime of streams. In return the application can be certain that the > transport won't destroy any state that it puts on streams at a whim. The > split enforces this separation. > > This issue with STOP_SENDING is a good one. I have a solution to that as > well: move STOP_SENDING to HTTP. If the required reaction (RST_STREAM), is > an application-layer action, then we should make the trigger > application-layer as well. > --f403045eb7f44925a00556d3891a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the idea of moving STOP_SENDING to the application = entirely. It's basically an HTTP/2 thing anyway, so that seems like an = excellent clean-up.

Mike: QUIC currently does not use RS= T_STREAM without the application asking for it outside of responding to STO= P_SENDING; do you think there are conditions under which it may be useful f= or the transport to issue one? STOP_SENDING was the only thing I could thin= k of, but moving it up to HTTP makes that moot.=C2=A0

On Mon, Aug 14, 2017 at 11:= 52 PM, Mike Bishop <Michael.Bishop@microsoft.com>= wrote:
I'm a little unhappy about th= at one.=C2=A0 I see the logic, but that would leave each direction of a str= eam solely in the hands of the sender and the receiver has no way to commun= icate (at the transport layer) if it wishes that stream to cease.=C2=A0 (Ot= her, perhaps, than starving it via flow control.)=C2=A0 Though I agree, it = is consistent with the principle that stream lifetime is entirely in the ha= nds of the application.

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Monday, August 14, 2017 5:49 PM
To: Jana Iyengar <jri@google.com&g= t;
Cc: Mike Bishop <Michael= .Bishop@microsoft.com>; QUIC WG <quic@ietf.org>
Subject: Re: Splitting transport and application error code spaces

On 15 August 2017 at 10:00, Jana Iyengar <jri@google.com> wrote:
> I'm not sure exactly what this split buys us... and it changes
> behavior on receiving STOP_SENDING.

So, what the split buys us is certainty: an application is responsible for = the lifetime of streams.=C2=A0 In return the application can be certain tha= t the transport won't destroy any state that it puts on streams at a wh= im.=C2=A0 The split enforces this separation.

This issue with STOP_SENDING is a good one.=C2=A0 I have a solution to that= as well: move STOP_SENDING to HTTP.=C2=A0 If the required reaction (RST_ST= REAM), is an application-layer action, then we should make the trigger appl= ication-layer as well.

--f403045eb7f44925a00556d3891a-- From nobody Tue Aug 15 19:52:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0879132483 for ; Tue, 15 Aug 2017 19:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=C9CNGBwX; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=cbFJQuGf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmH9k9QlCczm for ; Tue, 15 Aug 2017 19:52:11 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406A1132481 for ; Tue, 15 Aug 2017 19:52:11 -0700 (PDT) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7G2oD1b017727; Tue, 15 Aug 2017 19:52:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=mYUzC8MAoqAFmDs49l1itrjqnQJZVe/p71BtDFPT3YA=; b=C9CNGBwX0SHQR/bc3EouyIe9UR8OsEup0LmcefQp9UHh+tia0iETpOBGBaSJySncN1ao FwPw26fIjD3wlYOpWU+zwCCZn9hsvBh19d8H78YblMhd9t64Jr0SoEP6fF+WON5FBpsJ CySWWO2NMONc96aluaxpp1T3p0z6lQDJTc0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2cc93d0qau-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Aug 2017 19:52:05 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 15 Aug 2017 19:52:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mYUzC8MAoqAFmDs49l1itrjqnQJZVe/p71BtDFPT3YA=; b=cbFJQuGfa0QpEY2BXWmRa3RTk/NN2huoHdbfaHD9Coylpmog7w9UfNke/f0oZucZ7/XpaGIRcOAu8DkS/JSl2mZ5FY5Uz+R1VdCr/zW4C/XMOzoq0FQtVR3MHIxQJFdb2sL6SgPURpJ4CZj7FV8loE4Fpx+1Mdnis5BFSTkzJN0= 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.1.1341.21; Wed, 16 Aug 2017 02:52: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.01.1341.023; Wed, 16 Aug 2017 02:52:01 +0000 From: Subodh Iyengar To: Jana Iyengar CC: Benjamin Kaduk , Martin Thomson , Mike Bishop , "Ian Swett" , "quic@ietf.org" Subject: Re: flow control description in draft Thread-Topic: flow control description in draft Thread-Index: AQHTB7S0p26p684Re025NNzzwCphFqJpdcCAgBqxhK6AAAPoAIAAIPgLgAALJ/CAAAXE8YAAK4CAgAAVf4CAAAiTAIAAC+wAgAADewCAABjwQIABWegAgAA8eN0= Date: Wed, 16 Aug 2017 02:52: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::1:1bde] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1454; 20:77BlzCHfDSCR7/Cxb2XM/1CpGdDFRuMdXc6AqmyQ5b30yrF5Yn4Kb218V2z3MNcpzH7Q+5FNY2AswrE4E3jOkpCnau7YrPIxUSXW7zFCsFSme2vvy0iwrXpmFjWanGfqKRh+UtmZJJ5Am3zD9WW3a0tOHQFtndSkR5vwuei9kNU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 512b4a32-ddda-4d6d-5bea-08d4e451c4e2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR15MB1454; x-ms-traffictypediagnostic: MWHPR15MB1454: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524)(67672495146484)(211936372134217)(153496737603132); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(920507026)(6041248)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1454; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1454; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(377454003)(199003)(189002)(93886004)(606006)(54896002)(55016002)(6306002)(99286003)(5660300001)(54906002)(77096006)(25786009)(105586002)(19627405001)(33656002)(6506006)(229853002)(81166006)(3660700001)(14454004)(4326008)(81156014)(236005)(8676002)(9686003)(3280700002)(2906002)(6436002)(8666007)(53936002)(86362001)(8936002)(97736004)(966005)(101416001)(189998001)(7696004)(102836003)(74316002)(6116002)(478600001)(76176999)(50986999)(54356999)(53546010)(39060400002)(6246003)(2900100001)(106356001)(110136004)(34040400001)(7736002)(2950100002)(68736007)(6916009)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1454; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455442E1784518BAE5982BCB6820MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 02:52:01.1797 (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-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-15_16:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 02:52:14 -0000 --_000_MWHPR15MB1455442E1784518BAE5982BCB6820MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks everyone for the discussion. I'm going to abandon my PR and wait for= the changes that Mike mentioned. Subodh ________________________________ From: Jana Iyengar Sent: Tuesday, August 15, 2017 4:13:46 PM To: Subodh Iyengar Cc: Benjamin Kaduk; Martin Thomson; Mike Bishop; Ian Swett; quic@ietf.org Subject: Re: flow control description in draft Yes, Martin I know what arrays are. BTW, the reference you sent for C array= s is incorrect, here's a b= etter one :-) Thanks, Ben, for the blog post: I like that articulation. My apologies: I was legitimately confused because TCP consumes a sequence n= umber for both the SYN and the FIN, and I keep reverting to old behavior. T= CP consumes a number for reliability purposes (so that a receiver can ACK t= hese bits), but QUIC does not need to do this on stream FINs and stream off= sets, since these aren't about reliability, they're about receive-ordering. I agree that FIN does not need to consume an offset, so there needs to be n= o provision in flow control for it. Given that, I'll look at the PR to see = if it helps clarify this point further. On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar > wrote: Ya I think Jana probably just made a typo in saying 6, it would clearly be = 5. I see your point here though, that is only data has offsets, FIN just commu= nicates how much data was sent. Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with some sort of editorial change which changes the name of final Offset to be = called Written Bytes. I've updated the PR to reflect some of this discussion. The PR should now b= e editorial. Subodh ________________________________ From: Benjamin Kaduk > Sent: Monday, August 14, 2017 6:06:28 PM To: Martin Thomson; Jana Iyengar Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org Subject: Re: flow control description in draft On 08/14/2017 07:54 PM, Martin Thomson wrote: The FIN has an offset of 5. 5 octets of data each start at offsets 0, 1, 2, 3, and 4. The next octet starts at 5. The empty STREAM frame has an offset of 5. I have no idea why an offset would be consumed by declaring the stream complete. What has changed is that you now know how long the stream/message is. Ben Kaduk mentioned C arrays. This is a perfect analogy. If you haven't read up on these before, here's a primer: http://www.cplusplus.com/doc/tutorial/arrays/ I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-b= etween-elements/ , which has some advantages in reintroducing symmetry as to which pointer= values are defined to compute/dereference, forward/reverse iteration, etc. -Ben --_000_MWHPR15MB1455442E1784518BAE5982BCB6820MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks everyone for the discussion. I'm going to abandon my PR and = wait for the changes that Mike mentioned.


Subodh

From: Jana Iyengar <jri@= google.com>
Sent: Tuesday, August 15, 2017 4:13:46 PM
To: Subodh Iyengar
Cc: Benjamin Kaduk; Martin Thomson; Mike Bishop; Ian Swett; quic@iet= f.org
Subject: Re: flow control description in draft
 
Yes, Martin I know what arrays are. BTW, the reference you= sent for C arrays is incorrect, here's a better one :-) 
Thanks, Ben, for the blog post: I like that articulation.

My apologies: I was legitimately confused because TCP consumes a seque= nce number for both the SYN and the FIN, and I keep reverting to old behavi= or. TCP consumes a number for reliability purposes (so that a receiver can = ACK these bits), but QUIC does not need to do this on stream FINs and stream offsets, since these aren't abou= t reliability, they're about receive-ordering.

I agree that FIN does not need to consume an offset, so there needs to= be no provision in flow control for it. Given that, I'll look at the PR to= see if it helps clarify this point further.


On Mon, Aug 14, 2017 at 7:56 PM, Subodh Iyengar = <subodh@fb.com>= ; wrote:

Ya I think Jana probably just made a typo in saying 6, it would clearly = be 5.


I see your point here though, that is only data has offsets, FIN just co= mmunicates how much data was sent.
Even though this value is encoded in an offset field, it's not really an of= fset. I think this point could be better illustrated with

some sort of editorial change which changes the name of final Offset to = be called Written Bytes.

I've updated the PR to reflect some of this discussion. The PR should now b= e editorial.


Subodh 

From: Be= njamin Kaduk <bka= duk@akamai.com>
Sent: Monday, August 14, 2017 6:06:28 PM
To: Martin Thomson; Jana Iyengar
Cc: Mike Bishop; Ian Swett; Subodh Iyengar; quic@ietf.org
Subject: Re: flow control description in draft
 
On 08/14/2017 07:54 PM, Martin Thomson wrote:
The FIN has an offset of 5.  5 octets of data each start at offsets 0,
1, 2, 3, and 4. The next octet starts at 5.  The empty STREAM frame
has an offset of 5.

I have no idea why an offset would be consumed by declaring the stream
complete.  What has changed is that you now know how long the
stream/message is.

Ben Kaduk mentioned C arrays.  This is a perfect analogy.  If you
haven't read up on these before, here's a primer:
http://www.=
cplusplus.com/doc/tutorial/arrays/

I had mentioned it offlist, but since summoned, I will note that I was thin= king of a description like https://blog.nelhage.com/2015/08/indices-point-between-elements/<= /a> , which has some advantages in reintroducing symmetry as to which point= er values are defined to compute/dereference, forward/reverse iteration, et= c.

-Ben

--_000_MWHPR15MB1455442E1784518BAE5982BCB6820MWHPR15MB1455namp_-- From nobody Tue Aug 15 22:21:19 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E6132497; Tue, 15 Aug 2017 22:21:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-tls-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150286087142.12455.7636293117265940119@ietfa.amsl.com> Date: Tue, 15 Aug 2017 22:21:11 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 05:21:11 -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-05.txt Pages : 37 Date : 2017-08-15 Abstract: This document describes how Transport Layer Security (TLS) is used to secure QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/tls. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-05 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 15 22:21:26 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 29463132498; Tue, 15 Aug 2017 22:21:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-transport-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150286087312.12437.8012539705165838314@ietfa.amsl.com> Date: Tue, 15 Aug 2017 22:21:13 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 05:21:13 -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-05.txt Pages : 78 Date : 2017-08-15 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 15 22:22:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3084D132412 for ; Tue, 15 Aug 2017 22:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P6q40pjKXnm for ; Tue, 15 Aug 2017 22:22:45 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F811321F5 for ; Tue, 15 Aug 2017 22:22:45 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id c74so9821652iod.4 for ; Tue, 15 Aug 2017 22:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kZd2PtbNDkw53oZb5m8qfV4tglS3Hj3o0YPeiurJ7yw=; b=HWvLkJjXtEwCE28D6SrtFoqCxCIK4bGJKdpg0CV4NzDs+9OQvU8OhAezmU96wX5x4V E9swCHp4DODN5FzOE15bBJjZMgqVgcwq830Hb/MTIaSCLyxYB4N4bxgxXIgbRf1Wtw0T ZREsGp0seXquOHa3V9ow5knQZhiyI99nQW0pyXJ/KNurUXC0PKqHfsSwQrFDnJF4X2Dq pdDY8P11HfQQJPYEmGRQJtmyOTwZTETndgIQjMilY62W1lpHkrqu12IO7F7yxjnnk47f abAkJq48Ng0fj2gnFqtQgRdohcKuyvfEw4ray6lXhEAo6IIHP1df20X+vny4XFtdpWkC //Xw== 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=kZd2PtbNDkw53oZb5m8qfV4tglS3Hj3o0YPeiurJ7yw=; b=GyR0xj59UB/bxILsKouzfaY83PydSpcJ6m7y7yI/Dll0ham05bABTMahiieYUITGmk y/TNdH5U+cNFM3Ot/RA0V/X/LU7yQt47ZsfAu0Tou7FVo7/4U7YanDBkMXBkvQWRC2U4 OTKzjoHl0arwZ6jdqeS94ytVdfHn9FPvxFtC+9Ejwa4k81AXt0pnvHeFGXatEXuwds31 G07nzcQ0Zm24LroTPSx6yutDV6bMHRrurZV7NH4KPc+X6Pa5NvZBwx18m192du0VuiCS esO7KmYJ/Lc8tFwhc9uEBIMNBo/Z6PadRAfF2YM84B6V3W7FFBsBwpXszQYtUiktEm8h siPg== X-Gm-Message-State: AHYfb5h2lpeS+oSdYRWucoaiM2ZSd6P3Kho0/9W+QY/lqSfVEnpmk6vz kJzDLoAky/xpjaa1AiXTqnASRYUFPF0p X-Received: by 10.107.137.30 with SMTP id l30mr460987iod.279.1502860964959; Tue, 15 Aug 2017 22:22:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 15 Aug 2017 22:22:44 -0700 (PDT) From: Martin Thomson Date: Wed, 16 Aug 2017 15:22:44 +1000 Message-ID: Subject: -05 drafts published 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, 16 Aug 2017 05:22:47 -0000 You will see these coming through soon. There's never a good time to do this, but the editors agreed that it was about time. There are some larger changes in the pipe, so we thought that it would be helpful to create a marker for implementations. From nobody Wed Aug 16 00:32:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED4A132642 for ; Wed, 16 Aug 2017 00:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPUvppxgi9ly for ; Wed, 16 Aug 2017 00:32:17 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 534A513263F for ; Wed, 16 Aug 2017 00:32:17 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id r9so1494961uad.0 for ; Wed, 16 Aug 2017 00:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=GILRNVEzrEQouLLNrmTJQ6lnZgQWrFclCH21Z+YYPfU=; b=vE/U5aSuAuezdR8inXhW2qcUZWiTCU7jXFe9JT3wq4CNLr4fXKr3YqUMmkPqB0MU0b 1dY3JTYPJhV3YfnCulrth5pgiNGH/C+ZEIlX0f779QFTLRTMAwTST5CejM6SurS+LMfw qbr2U395uoZ/SoICg6xSbG3sVCOYh+LHFTB41wprLQgsFixDKf+wl9VUBwfMuWV5l3iY Oa48PE2OHLA0sqlADJ316aiKONlbmR7j3DNmuyQ2oLeStbhj0dsR6PNESkBkZTOrH6Jw vwUqVRlZnrWeiVKLlQateFwnm1TnnltytwWY6rvLtUZoFzmJ/JLXgUVTW+kQOjV3vyLc 1Qmw== 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=GILRNVEzrEQouLLNrmTJQ6lnZgQWrFclCH21Z+YYPfU=; b=MQag2PXqTzlARmeqaQgtS2D6dpUwDsRZTBXGko0xLsnetU+drgFCBO7TYFgBwRg5Wh t1bzj3TG05lmszkU3zyok+B4nR0qf8Lfoy9Ysm7QfYxZjMzX7466sIqzXd/If2D2ceHU SbuW139lz8UCtzntiFwuAt7xqZFhfW0NOM7XlbUWMuep0x1kVbx1SoTq/FUQTtFx7RL6 wFxEjkdT1JvPPTaiXRt4dLZz+0qaBYeduzNBfiZdWQ5L/24PJ/YrNgDErgkCwRnEtNMA h7pa/4aouIw/cPKrX8iJ8+OmFDl0Ah3gstWIkcHsR04QTxCqf2771N0ANHrFBiWPPmrd q82A== X-Gm-Message-State: AHYfb5jFWC71IiW4V41Mbg4jHd2SRPt1PMqld1U4XUiTTtnjYzg1ZVVh Hmmp7yW5e/y4CAhK08WkhU+N/K7R4w== X-Received: by 10.176.79.130 with SMTP id m2mr569255uah.152.1502868736428; Wed, 16 Aug 2017 00:32:16 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 16 Aug 2017 00:32:15 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 16 Aug 2017 00:32:15 -0700 Message-ID: Subject: Re: Splitting transport and application error code spaces To: Jana Iyengar , Mike Bishop Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="f403043ec64c2dd0f00556d9e591" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Aug 2017 07:32:19 -0000 --f403043ec64c2dd0f00556d9e591 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If STOP_SENDING is moved a basic application will no longer have a language to communicate intent. This is perhaps a broader issue - but the question is: what are the minimum primitives a basic application with no advanced higher level protocol needs in order to move data on multiple streams? It relates to adding bidi streams on top of uni streams. I=E2=80=99m not sure if STOP_SENDING is important in this context, or not, = but I believe it is a worthwhile question. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 16 August 2017 at 01.57.11, Jana Iyengar (jri@google.com) wrote: I like the idea of moving STOP_SENDING to the application entirely. It's basically an HTTP/2 thing anyway, so that seems like an excellent clean-up. Mike: QUIC currently does not use RST_STREAM without the application asking for it outside of responding to STOP_SENDING; do you think there are conditions under which it may be useful for the transport to issue one? STOP_SENDING was the only thing I could think of, but moving it up to HTTP makes that moot. On Mon, Aug 14, 2017 at 11:52 PM, Mike Bishop wrote: > I'm a little unhappy about that one. I see the logic, but that would > leave each direction of a stream solely in the hands of the sender and th= e > receiver has no way to communicate (at the transport layer) if it wishes > that stream to cease. (Other, perhaps, than starving it via flow > control.) Though I agree, it is consistent with the principle that strea= m > lifetime is entirely in the hands of the application. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, August 14, 2017 5:49 PM > To: Jana Iyengar > Cc: Mike Bishop ; QUIC WG > Subject: Re: Splitting transport and application error code spaces > > On 15 August 2017 at 10:00, Jana Iyengar wrote: > > I'm not sure exactly what this split buys us... and it changes > > behavior on receiving STOP_SENDING. > > So, what the split buys us is certainty: an application is responsible fo= r > the lifetime of streams. In return the application can be certain that t= he > transport won't destroy any state that it puts on streams at a whim. The > split enforces this separation. > > This issue with STOP_SENDING is a good one. I have a solution to that as > well: move STOP_SENDING to HTTP. If the required reaction (RST_STREAM), = is > an application-layer action, then we should make the trigger > application-layer as well. > --f403043ec64c2dd0f00556d9e591 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
If STOP_SENDING is moved a basic application will= no longer have a language to communicate intent.
This is perhaps a broader issue - but = the question is: what are the minimum primitives a basic application with n= o advanced higher level protocol needs in order to move data on multiple st= reams? It relates to adding bidi streams on top of uni streams.

I=E2=80=99m not sure if STOP_SEN= DING is important in this context, or not, but I believe it is a worthwhile= question.

Kind R= egards,
Mikk= el Fahn=C3=B8e J=C3=B8rgensen


On 16 August 2017 at 01.57.11, Jana Iyengar (jri@google.com) wrote:

I like the idea of moving STOP_SENDING to the application entirely. It's basically an HTTP/2 thing anyway, so that seems like an excellent clean-up.

Mike: QUIC currently does not use RST_STREAM without the application asking for it outside of responding to STOP_SENDING; do you think there are conditions under which it may be useful for the transport to issue one? STOP_SENDING was the only thing I could think of, but moving it up to HTTP makes that moot.=C2=A0

On Mon, Aug 14, 2017 at 11:52 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
I'm a little unhappy about that one.=C2=A0 I see the logic, but that would leave each direction of a stream solely in the hands of the sender and the receiver has no way to communicate (at the transport layer) if it wishes that stream to cease.=C2=A0 (Other, perhaps, than starving it via flow control.)=C2=A0 Though I agree, it is consistent with the principle that stream lifetime is entirely in the hands of the application.

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Monday, August 14, 2017 5:49 PM
To: Jana Iyengar <jri@google.com&g= t;
Cc: Mike Bishop <Michael= .Bishop@microsoft.com>; QUIC WG <quic@ietf.org>
Subject: Re: Splitting transport and application error code spaces

On 15 August 2017 at 10:00, Jana Iyengar <jri@google.com> wrote:
> I'm not sure exactly what this split buys us... and it changes
> behavior on receiving STOP_SENDING.

So, what the split buys us is certainty: an application is responsible for the lifetime of streams.=C2=A0 In return the application can be certain that the transport won't destroy any state that it puts on streams at a whim.=C2=A0 The split enforces this separation.

This issue with STOP_SENDING is a good one.=C2=A0 I have a solution to that as well: move STOP_SENDING to HTTP.=C2=A0 If the required reaction (RST_STREAM), is an application-layer action, then we should make the trigger application-layer as well.

--f403043ec64c2dd0f00556d9e591-- From nobody Wed Aug 16 02:33:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EC3132031 for ; Wed, 16 Aug 2017 02:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QzMkIO3lyhwk for ; Wed, 16 Aug 2017 02:33:42 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1518A1323B4 for ; Wed, 16 Aug 2017 02:33:41 -0700 (PDT) X-AuditID: c1b4fb30-96f7a9c000005897-a1-59941174b06e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C4.A8.22679.47114995; Wed, 16 Aug 2017 11:33:40 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 16 Aug 2017 11:33:38 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mcwtISnluNnfzjeG6iQn3Sb0iIBuJuEkrpXysh+TkaY=; b=eoHo7b2qmRk3mwjSNJm+nPJFpb0DVv+1uY5Qcm/p+9AtCPudeUZsEMj+pSkSt6PnhsJgICWvZOUw1RxbgslAvl7zNgQ+ksJBJARu+/7/3vtRZyoiU7jCGF+Ziga5JaoSuDMxWvP589ymufNjdaS4OZedALxYccN//A4orjo53iY= Received: from AM3PR07MB340.eurprd07.prod.outlook.com (10.242.109.25) by AM3PR07MB1060.eurprd07.prod.outlook.com (10.163.187.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Wed, 16 Aug 2017 09:33:37 +0000 Received: from AM3PR07MB340.eurprd07.prod.outlook.com ([fe80::c8a4:ba1a:386b:7c72]) by AM3PR07MB340.eurprd07.prod.outlook.com ([fe80::c8a4:ba1a:386b:7c72%17]) with mapi id 15.01.1362.012; Wed, 16 Aug 2017 09:33:36 +0000 From: Ingemar Johansson S To: QUIC IETF mailing list CC: Magnus Westerlund , "Eggert, Lars (lars@netapp.com)" , "'mirja.kuehlewind@tik.ee.ethz.ch'" , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Bob Briscoe (research@bobbriscoe.net)" , marcelo bagnulo braun , Piers O'Hanlon , "Praveen Balasubramanian" , Ingemar Johansson S Subject: ECN in QUIC Thread-Topic: ECN in QUIC Thread-Index: AdMWaIZN+ofkuQeuQOGGa2om9/ikzQ== Date: Wed, 16 Aug 2017 09:33:36 +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.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1060; 6:wnj0EF/XWD7ATNTqQaIGdQv+Au+Y4odDAhXCf2Ka4+FHA0bgOJQxzXSdS6lPX9NVfJeKofkp0ItZ3B4cHbTA8ujrcCcK22cg+3uvR9xTl7Tflry2dAkWxW1lFvVzNMAEmo5JQhIc6TxTfnixL3D+OFjTAbLmgeZweWZTc4kX8yvUelXl85xJckn+fKmllxedQ7hpfcR7j0ugp8H0fj1gsJSemdqENVwULWiSH21e4bKVAjjrzMo6T+S+W+44aPcI6OwU1dXBbrCA6UOKlNfNhXbYtjqgMuVx4+V1Nxd6lPXOdFHPSC3522j9DjQe/wrOVkI8MpSkX/g90zOMx08d9w==; 5:DE0R7vZr9Hi5zrAI9ntUWTbBMBD1BBvTvXD0g+h728xHII0limXz+UHZACE3zCJIBQKKjaEwtrgS6vv/e8wns/rKKQk8xyt8bwhakqNxBvmtR/9qO8KVMHq3lxG0TLz2cAPxQ5FOl9ZWMGJvHaEA9Q==; 24:w30q0qS4fFifR6OYY1g2ymXV9WDkrjgiSn9Mgr6Xst0PcRL5Xqv8F2VQ5YIH1WJ2x4iysvyZo4a2gsaxPodng3Q2rYRDWM4WV9p97QYjZgc=; 7:Zh0CodwiUZzo7ANcjyOiwF+pVGe4jQAbXGe3Ls5OKDfrZi8nvEgPipSsmSo/S9zw2b2OUoFnizWZhPRkyhP+wqSWD2aTDjq9xlGznRjsLPunPZ8J5f3dY3UiDZR8nflEB6TNtZpIKHIm+jHvNi9zze8+E822Qy2Vs3kzdvRDEN/ZyK/8TWcCSwJggPPP8lA1dzBq4AuV8voCOPpX+Gb2LZubOrFVDRcxlxrO4pqCmTE= x-ms-office365-filtering-correlation-id: 9db40fbd-e48a-42ce-dee7-08d4e489df0b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603156)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1060; x-ms-traffictypediagnostic: AM3PR07MB1060: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1060; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1060; x-forefront-prvs: 0401647B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(189002)(199003)(606006)(19609705001)(7696004)(2906002)(101416001)(189998001)(9326002)(7116003)(6116002)(3846002)(74316002)(8676002)(5660300001)(478600001)(102836003)(790700001)(3480700004)(6916009)(7736002)(105586002)(106356001)(81156014)(81166006)(6506006)(8936002)(6436002)(53936002)(33656002)(55016002)(50986999)(2900100001)(25786009)(86362001)(236005)(54356999)(3660700001)(6306002)(9686003)(4326008)(110136004)(54896002)(99286003)(8666007)(54906002)(3280700002)(107886003)(5250100002)(68736007)(66066001)(966005)(14454004)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1060; H:AM3PR07MB340.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=ingemar.s.johansson@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB34048E916A7B18695313171C2820AM3PR07MB340eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2017 09:33:36.8582 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1060 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOXsvvlqD45r6aImyytBwqUXsQ0leiBckCCK8BLZlbyXOC3tN mvUhxWm5WQYrLylesvKCUCo5SVwOFf2QrYu3wvulixAhtpGhtu1d4Lff+f+f8z/P83AYQrJI BTDpWbmcJkulltFeZFVSd0p4rrcxOWKsz1cxZHsqUnxbNZAK3XIrrXjRZiQVHcWdlGLVsIgU hvpdivlHhegUw/6YtVLs5p1XJNvU9EfE2iZeUqzOtOnBVq6t02yhrZFmh379ps8yKV4nLnPq 9DxOcyRa6XXtwXgBnWNT3ijaDriNBs6XIk8G8DGwfpmkSpEXI8EDCPRVjSLhMIyg+cNH0nkg cRkB5tdWt1Mhgjn7BHLel+B5BPafoU6m8QlosdhduhSHQcfgU1cugY0klM8skE5jD5ZCa7uJ Eor84ee6zqEzDpZD2TLtRBIfhJn5EGeFGKfA9HaXKxLhQJi1z7hSCOwHn5fqRMIIGJp63xEC +8D3xS3KGQM4GJo2/QU5ED7U6ZGzG8DFHvDE0IkE4wzUWDYIwVgQgblL5w4KgzdzOnfRBTAO ldICZ0DPjw1SuPCRgp6KZXcX+8BaNOp+Yo6CaVMxIWyIg+ftOvcIabA2VUYJiwiA6U93UTkK rd4xkcDZsFb9hq52bcAbRqqWSEGXw+RDIy3wYXjWsEoIHA6VWxZyp16PPFqRD8/xlzKvRkXJ OU16Gs9nZ8mzuNwO5Ph6/V1/I0zo+9cYC8IMku0W+zPGZAmlyuO1mRYEDCGTirXYIYkvq7T5 nCb7oua6muMtaC9DyvzEMX3WJAm+qsrlMjguh9P8d0WMp+NvJeccKjz5yghts/bB2qIMfXPC mCVvc/xxYlC+obskZFmZw+8vUd86vdLCSsWRBcpJHxxcSybl10ePDOyZqu7vCxmNZ9RtqXSc 0rd3dC7kyvHwIHP0iHg49u29c20FLJ3YkBCrvxn995n2mPJovPZA3opvXE1qT0HJe/P95iRW RvLXVJFhhIZX/QOtittpdgMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Aug 2017 09:33:45 -0000 --_000_AM3PR07MB34048E916A7B18695313171C2820AM3PR07MB340eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Finally back from vacation, and very grateful for the support to continue t= he work to add ECN in QUIC. Just to recap.. there were two main topics raised at the meeting 1) ECN info in ACK frame or in dedicated frame : There were concerns about = adding extra complexity in an already potentially complex ACK frame, one ca= n have differing opinions about the complexity but can understand the conce= rns. As far as I am concerned, a separate frame type for ECN is possible, p= ossibly one need to add information about the amount of not-ECT marked pack= ets as well to keep the signaling robust, this needs further investigation = though. One concern with a separate ECN frame is that it becomes a not-impl= emented or optional feature, is there any reason to be worried about this ? 2) More detailed ECN information : Earlier versions of the ECN in QUIC draf= t (see https://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) provided= with examples. We (Myself, Koen, Mirja and Praveen) discussed this and we = could not come up with any use case where it is beneficial to know exactly = how each packet is ECN marked. I know that this kind of detailed ECN inform= ation is suggested for the generic feedback for RMCAT and I personally have= a problem to see the gain with the detailed ECN information also here. Inp= ut from others is very welcome here. There are a consequences with detailed= ECN marking information. a) necessary to correlate with the list of transmitted packets, this increa= ses amount of code on sender side, not sure of that is a large concern as l= ookup is anyway needed to process incoming ACKs b) necessary to embed ECN information in ACK frame ?, at least this was my = conclusion when I devised the detailed ECN marking info in the 01 version o= f the draft. Comments are welcome /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_AM3PR07MB34048E916A7B18695313171C2820AM3PR07MB340eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

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

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

 

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

 

2) More detailed ECN information : Earlier versions = of the ECN in QUIC draft (see https= ://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) provided with ex= amples. We (Myself, Koen, Mirja and Praveen) discussed this and we could no= t come up with any use case where it is beneficial to know exactly how each packet is ECN marked. I know tha= t this kind of detailed ECN information is suggested for the generic feedba= ck for RMCAT and I personally have a problem to see the gain with the detai= led ECN information also here. Input from others is very welcome here. There are a consequences with detailed E= CN marking information.

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

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

 

Comments are welcome

/Ingemar

 

 

 

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

Ingemar Joh= ansson  M.Sc.

Master Researcher<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_AM3PR07MB34048E916A7B18695313171C2820AM3PR07MB340eurprd_-- From nobody Wed Aug 16 03:53:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1BDC132488 for ; Wed, 16 Aug 2017 03:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGedPrWJLubY for ; Wed, 16 Aug 2017 03:53:06 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4848A132139 for ; Wed, 16 Aug 2017 03:53:06 -0700 (PDT) Received: from [130.209.247.112] (port=63975 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1dhvwZ-000161-Qp; Wed, 16 Aug 2017 11:53:04 +0100 From: Colin Perkins Message-Id: <8E718F38-88DB-4E1D-BC1B-1C0F0E9E5C34@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_4D33A2B7-3986-481D-85D7-CFB2171AE3A5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: ECN in QUIC Date: Wed, 16 Aug 2017 11:52:34 +0100 In-Reply-To: Cc: QUIC IETF mailing list , Magnus Westerlund , "Bob Briscoe (research@bobbriscoe.net)" , Praveen Balasubramanian , "Eggert, Lars (lars@netapp.com)" , marcelo bagnulo braun , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Piers O'Hanlon , "De Schepper, Koen (Nokia - BE/Antwerp)" To: Ingemar Johansson S References: X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 10:53:10 -0000 --Apple-Mail=_4D33A2B7-3986-481D-85D7-CFB2171AE3A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 16 Aug 2017, at 10:33, Ingemar Johansson S = wrote: >=20 > Hi > =20 > Finally back from vacation, and very grateful for the support to = continue the work to add ECN in QUIC. > Just to recap.. there were two main topics raised at the meeting > =20 > 1) ECN info in ACK frame or in dedicated frame : There were concerns = about adding extra complexity in an already potentially complex ACK = frame, one can have differing opinions about the complexity but can = understand the concerns. As far as I am concerned, a separate frame type = for ECN is possible, possibly one need to add information about the = amount of not-ECT marked packets as well to keep the signaling robust, = this needs further investigation though. One concern with a separate ECN = frame is that it becomes a not-implemented or optional feature, is there = any reason to be worried about this ? > =20 > 2) More detailed ECN information : Earlier versions of the ECN in QUIC = draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt = ) provided = with examples. We (Myself, Koen, Mirja and Praveen) discussed this and = we could not come up with any use case where it is beneficial to know = exactly how each packet is ECN marked. I know that this kind of detailed = ECN information is suggested for the generic feedback for RMCAT and I = personally have a problem to see the gain with the detailed ECN = information also here. Input from others is very welcome here. For the RMCAT format, we wanted per-packet loss and timing information, = and it was as easy to feedback per-packet ECN information along with it = as to design something different. A benefit of per-packet ECN marking could be to allow a congestion = controller that reacted differently to bursts of consecutive ECN marks = than it did to isolated ECN marks, given the same fraction of marked = packets (i.e., that reacted to ECN marking events rather than ECN = marking rate, like how TCP responds to loss events). I don=E2=80=99t = think we have such a thing, but certainly in the context of RMCAT where = we=E2=80=99re experimenting with novel congestion control schemes for = traffic that has very different characteristics to traditional bulk = flows, it might be plausible. Per-packet marking information is also = useful for troubleshooting. Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE = marks since the last report, but I guess that=E2=80=99s already = possible. Cheers, Colin > There are a consequences with detailed ECN marking information. > a) necessary to correlate with the list of transmitted packets, this = increases amount of code on sender side, not sure of that is a large = concern as lookup is anyway needed to process incoming ACKs > b) necessary to embed ECN information in ACK frame ?, at least this = was my conclusion when I devised the detailed ECN marking info in the 01 = version of the draft. > =20 > Comments are welcome > /Ingemar > =20 > =20 > =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Ingemar Johansson M.Sc. > Master Researcher > =20 > Ericsson AB > Wireless Access Networks > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com = > www.ericsson.com > =20 > A mistake is to commit a misunderstanding > Bob Dylan > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_4D33A2B7-3986-481D-85D7-CFB2171AE3A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 16 Aug 2017, at 10:33, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi
 
Finally back from vacation, and very = grateful for the support to continue the work to add ECN in QUIC.
Just to = recap.. there were two main topics raised at the meeting
 
1) ECN = info in ACK frame or in dedicated frame : There were concerns about = adding extra complexity in an already potentially complex ACK frame, one = can have differing opinions about the complexity but can understand the = concerns. As far as I am concerned, a separate frame type for ECN is = possible, possibly one need to add information about the amount of = not-ECT marked packets as well to keep the signaling robust, this needs = further investigation though. One concern with a separate ECN frame is = that it becomes a not-implemented or optional feature, is there any = reason to be worried about this ?
 
2) More detailed ECN information : = Earlier versions of the ECN in QUIC draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt ) provided with = examples. We (Myself, Koen, Mirja and Praveen) discussed this and we = could not come up with any use case where it is beneficial to know = exactly how each packet is ECN marked. I know that this kind of detailed = ECN information is suggested for the generic feedback for RMCAT and I = personally have a problem to see the gain with the detailed ECN = information also here. Input from others is very welcome here. =

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

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

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

Cheers,
Colin




There are a consequences with detailed ECN marking = information.
a) necessary to correlate with the list of transmitted = packets, this increases amount of code on sender side, not sure of that = is a large concern as lookup is anyway needed to process incoming = ACKs
b) = necessary to embed ECN information in ACK frame ?, at least this was my = conclusion when I devised the detailed ECN marking info in the 01 = version of the draft.
 
Comments are welcome
/Ingemar
 
 
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ingemar Johansson  M.Sc.
Master Researcher
 
Ericsson AB
Wireless Access Networks
Labratoriegr=C3=A4nd 11
971 28, Lule=C3=A5, = Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
 
A mistake is to commit a = misunderstanding
          &nb= sp;          Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D



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




= --Apple-Mail=_4D33A2B7-3986-481D-85D7-CFB2171AE3A5-- From nobody Wed Aug 16 05:42:23 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1B1320BE; Wed, 16 Aug 2017 05:42:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150288734128.12601.15067017800297122554@ietfa.amsl.com> Date: Wed, 16 Aug 2017 05:42:21 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:42:21 -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-05.txt Pages : 19 Date : 2017-08-15 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic. Working Group information can be found at https://github.com/quicwg; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/recovery. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-05 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 16 06:35:17 2017 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F065F13201E; Wed, 16 Aug 2017 06:35:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-http-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150289051593.12518.11281124866431394765@ietfa.amsl.com> Date: Wed, 16 Aug 2017 06:35:15 -0700 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:35:16 -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-05.txt Pages : 33 Date : 2017-08-15 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-05 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 16 13:37:17 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1231326FE for ; Wed, 16 Aug 2017 13:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZinUQQNMQZ0X for ; Wed, 16 Aug 2017 13:37:13 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FD141326F5 for ; Wed, 16 Aug 2017 13:37:13 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id n83so1989923ywn.2 for ; Wed, 16 Aug 2017 13:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=2QhyOh29TE1hwe6ny0ppIMM4UVfBTyL5er6R0vG6JQ0=; b=pLwuAA3svI/CRvpW0JjarKaIYmuJ/9uvkL7Z9PXQBl0kHoPoY4oDUSe7RNwBjbDIk1 /m4A81nNxmcC5K1LvI6LXeAooxPq1NriMdDFpIK0R4dczUaegg5AO8beBNgtggESIve5 dCaMkZ46tBPSV8aQgkJYvhNTg8Q6hnU2beHwXxKylWirfesXu3jsOrrTr2Z9vYll3c8W Vq+As0G9cCqmHw473IFmlzwBjBhH9atycppjpm/L6jHy2Ff2YNnQxM8xHr93NKSLBlYG XWPy01GxTHcQyIYEgSkWkqeEPfEWtzFlznvPktTyyRewb7BJcqAHr8fXFAT/xWDZbDI8 Z7yw== 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=2QhyOh29TE1hwe6ny0ppIMM4UVfBTyL5er6R0vG6JQ0=; b=Va2LUX2BV/Lq9d+mbYhwZ+NGmlfvgocmwCuEXae5R0MHKQ48hAlc8LR52ptq3CakFO zt/2pZC5A+7IWUGykomk37jF9PzmQABVBX1XOcGLkKRc4g2GjW7N44Pv3HjAcOIMf1nR mMeCugr54t9VtjAMcLG3k8l9XFXuqRoIJV3XIsIHCVWaR7EOmeb2AkmB7IpAAipLNM3y U0pWeWFWwIG7pexZy5Kelc4Zwvrmy7tcVT+rpILBsjMRSCCfzkqdsFaSxRz51JZnN698 SMiozrWsc0ww02hafJRNtbvuu3vOZLedsA75wxMqyt3JWe3CUFNPjK+QyqcOnppSxcig Ff9A== X-Gm-Message-State: AHYfb5gy3X5hblr9pJjTvWB0CsQAXUlVTmwoR7xh0MkhseM+ZnvmX63X MMewAQZ1yjAdOlY9jnQa9cqemtv0RkTjvYZOfw== X-Received: by 10.129.182.9 with SMTP id u9mr2346729ywh.261.1502915832086; Wed, 16 Aug 2017 13:37:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.171.9 with HTTP; Wed, 16 Aug 2017 13:36:51 -0700 (PDT) From: "Charles 'Buck' Krasic" Date: Wed, 16 Aug 2017 13:36:51 -0700 Message-ID: Subject: draft-ietf-quic-http-05 and PUSH_PROMISE To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045d10664d0f040556e4dc94" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 16 Aug 2017 20:37:15 -0000 --f403045d10664d0f040556e4dc94 Content-Type: text/plain; charset="UTF-8" Would it make sense to mention PUSH_PROMISEs in draft-ietf-quic-http-05. html#rfc.section.4.2 ? -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --f403045d10664d0f040556e4dc94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Would it make sense to me= ntion PUSH_PROMISEs in=C2=A0=C2=A0draft-ietf-quic-http-05.html#rfc.section.4.2?

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

--f403045d10664d0f040556e4dc94-- From nobody Wed Aug 16 18:43:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CB913226B for ; Wed, 16 Aug 2017 18:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 86lK1AYPHUjl for ; Wed, 16 Aug 2017 18:43:06 -0700 (PDT) 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 BAE78132391 for ; Wed, 16 Aug 2017 18:43:06 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id g71so18775525ioe.5 for ; Wed, 16 Aug 2017 18:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vuoXEAE+bq89k+jBQqd6TFwDj8EG3vVIQg4DlQob0uc=; b=QgXilXjoWEKHtWZeBA0SzERkNzFlEpTdUbu/bt+AG0D/bzMnl6vyYgxFK3UJd2Y8fh KMGTbVS3BTTkiuuxERtBRfTdqhYJH/7ZUUm1R7seobLiIMlWP/xE5VbN34vPrxJ+dAPt 4A2moas3GhUE2c+v5IWfby5lIs3XdN7/b0lq+GWNrnLCsjDwqnjBfDJ2B7p2gYAz8GBr MUUSgG29Oz9pKWQPSArjMSRQCkYt91ImeDaU0US8VP/z0UXFobvN5WZwGertxnVSgrQa k2smTtj1XfC7eswRcI+GFs+0J1LEbcOnNMo5o+/nLnuTuTMTS0WQpQgs/cJLGXRusqpr PfDw== 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=vuoXEAE+bq89k+jBQqd6TFwDj8EG3vVIQg4DlQob0uc=; b=M53ZYgkI8rIg/RM82J9pXWR5LfCPR2hSxgKSodvIj+XQWmZyJo6NteNvpJyWfMSLQx 6lpuxgr84awPWDqcc5Y4QKPAOCiK5RK1ZSe0qc1NJl3+J+4iEX/MQJPwrReKGsJ8/Dnr N2XYVUYM/jd97Ni1Sp/t2LxExt5aV8pcC+Qlz9t/GfF6COZEgaAI3UW1NzKP4JdMAY/Z dLlJCgu7M/TzDI8lOyJ3UXwwf9Sl3uxfYAa2Mb4o6HOA+RgBZKzxOT49W9Pz6BAkjkN4 jfKWr5uzaCxuHSD3vW57XxsWmDDl3EJqa1PF4ZGDpFPYpned/JO67cEkgTvCr9L5b8as WUhQ== X-Gm-Message-State: AHYfb5hpBz2OGnRvp9Rd4PkacYFy0N1JmPA0plHEstNp1darduJR8MaA /3yCnh1UkoEpK8Ve2M0fKZ6KZ5b2VA== X-Received: by 10.107.16.196 with SMTP id 65mr3681808ioq.297.1502934186018; Wed, 16 Aug 2017 18:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:43:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 17 Aug 2017 11:43:05 +1000 Message-ID: Subject: Re: draft-ietf-quic-http-05 and PUSH_PROMISE To: "Charles 'Buck' Krasic" Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 01:43:09 -0000 Open an issue? A PUSH_PROMISE is a request, and we could say that. On 17 August 2017 at 06:36, Charles 'Buck' Krasic wrote: > Would it make sense to mention PUSH_PROMISEs in > draft-ietf-quic-http-05.html#rfc.section.4.2? > > -- > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > From nobody Wed Aug 16 18:46:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69C39132407 for ; Wed, 16 Aug 2017 18:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ghNMKe9n9CC for ; Wed, 16 Aug 2017 18:46:01 -0700 (PDT) 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 8CC2F13226B for ; Wed, 16 Aug 2017 18:46:01 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g71so18789852ioe.5 for ; Wed, 16 Aug 2017 18:46:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Tb1AGSV2mU3BYlQElV7ylzqCjU5EK3UrEES3nyA++/I=; b=kCV/sf+qOjE/OCJcYbqcPKmGbbwfKKvptXA5sAcN4Vlzxnwpl73P7mHNwTYGhxqjIr r76TrF1RDGwKP226BuzVrT+pUQYgiKCz2qFOIGWpxSfz+8wJranrDoNhEy2yvbAESVjY 9+qPzkcGXmPCTD5WndaGSJca2iaYt4MmimKa3E6hMQwzKycNmyCwbO8sefCyLoemh4GF /JzYnuwEaVqKrh/9h3D0Qos/u+J53QePOsUdL8uhF+9OMA7hy1MYJcTrFTAU3MZOef5Q kAM2P0KN4CnsRA8aVEzOHbFxp4QAUCrV6vpFydVfx7sScsec1JVEi7P+Y6jJZBAOyTpS WRFg== 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=Tb1AGSV2mU3BYlQElV7ylzqCjU5EK3UrEES3nyA++/I=; b=UAX6kW5vc4OuTgtmZcWwx5kLguEjpuBhNMSxHGoqgh9WvvLA0SyZ3lX5b5rNh6IPC6 Q8NYDVqH/+uDFzBLcq00r8EOcGv8NELGnhmCZzQkD4O50D+4PuKmyX6jDv/suBWGNtHX gFik5FenndzyXy2UN/KXbSAoKFsJt2Bt6BfFO7DkqiycmwGfsROTSVhYZR3dE3goi35z GnSKzMvdb757pjblPxfm0ELgrEbiuX7aQlZJ5YURBoXCq54mWBDxAMwsTD0m3OoioiI8 TrjH6Ju7MsEuT7jCxV9+3FheIDymEpPRu1Qz7GHMsytJqjXWVCv9N09JZtPmOSHGo4E0 Bw+Q== X-Gm-Message-State: AHYfb5j23IlwKhMxUO/bI05YGg4QZDNhVfGuRSmTg/mN+emA7hnUIoLr hMpbIbcT1bz/QDOhap+PdBzrv9aPAkXl X-Received: by 10.107.201.65 with SMTP id z62mr3688413iof.74.1502934360954; Wed, 16 Aug 2017 18:46:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Wed, 16 Aug 2017 18:46:00 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 17 Aug 2017 11:46:00 +1000 Message-ID: Subject: Re: Splitting transport and application error code spaces To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Jana Iyengar , Mike Bishop , 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, 17 Aug 2017 01:46:03 -0000 On 16 August 2017 at 17:32, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > If STOP_SENDING is moved a basic application will no longer have a langua= ge > to communicate intent. > This is perhaps a broader issue - but the question is: what are the minim= um > primitives a basic application with no advanced higher level protocol nee= ds > in order to move data on multiple streams? It relates to adding bidi stre= ams > on top of uni streams. The assertion here is that STOP_SENDING isn't a necessary primitive. And it isn't generated or consumed by the transport, even if the effects (RST_STREAM) are. It is useful in HTTP, so HTTP can define it. We might see something like that if someone ported (for example) websockets to QUIC. I can't see it being used for DNS. I might speculate and say the same about RTP, but that's so nebulous I'd likely be wrong. From nobody Wed Aug 16 22:54:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 610251323B2 for ; Wed, 16 Aug 2017 22:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBnE7BhedJYF for ; Wed, 16 Aug 2017 22:54:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73ECB124E15 for ; Wed, 16 Aug 2017 22:54:23 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7H5phHI032618; Thu, 17 Aug 2017 06:54:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=i/lAAGeHX7SBPx3vHDcoS1+/fHuENo3KvUZdPXsALbk=; b=BAQnZZh7e21++zmLN1IzhdCQMw63FPSUU9DTWaPvmZQGnd/wHvwbl+dzTnNm/wkcZypL AuqR8wJRknihZi0/etLP9bHnUo7ixwVcEw0VXUGFANOkbUl43ysPymUb4zk5zv+K/OdK BRnJcc5AABjX+rUQLWYuetpYUJKY7abjGpKOP4WLxXzdBBB+IWtr/h+IAOo0rDHbUPnu 41262OQdoy8r871oywb9GNo0PNy7FKT6p1Z66ROKTRp/CPX4EfaPvlFPAy5eM1MbGted kVDb/M97FZhJQ+pxnNqAVqBC5S2mExPCefoz9XvjJ78Dx7Vy4hIF+U2lYBz4s2NspcpM aw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2cc6e2ncgn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 06:54:18 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7H5pJcW030319; Thu, 17 Aug 2017 01:54:17 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cc6cvdxt3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 17 Aug 2017 01:54:17 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 16 Aug 2017 22:54:16 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1263.000; Thu, 17 Aug 2017 01:54:16 -0400 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "mikkelfj@gmail.com" CC: "quic@ietf.org" , "jri@google.com" , "michael.bishop@microsoft.com" Subject: RE: Splitting transport and application error code spaces Thread-Topic: Splitting transport and application error code spaces Thread-Index: AQHTEmRPR0mlt8Dp80CXcj5p+FhJS6J/fliAgAFEoICABA5DAIAADY8AgABltICAAR4qAIAAfy2AgAExlwCAAAJQNw== Date: Thu, 17 Aug 2017 05:54:15 +0000 Message-ID: <4ad8822827db4086a06442e2543cf9ac@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_4ad8822827db4086a06442e2543cf9acusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170100 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-17_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708170100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Aug 2017 05:54:25 -0000 --_000_4ad8822827db4086a06442e2543cf9acusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The response to STOP_SENDING may be faster if it were a part of the transpo= rt (especially if QUIC transport is implemented on a kernel level). An appl= ication on a busy system that has written 100K to the transport might not r= eceive and process the STOP_SENDING request and then ask for a stream reset= in time to save a large chunk of unnecessary data from being transmitted. Other than this, I can see how moving this frame to the application is a mi= nor transport simplification. -----Original Message----- From: Martin Thomson [martin.thomson@gmail.com] Received: Wednesday, 16 Aug 2017, 9:46PM To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com] CC: Jana Iyengar [jri@google.com]; QUIC WG [quic@ietf.org]; Mike Bishop [mi= chael.bishop@microsoft.com] Subject: Re: Splitting transport and application error code spaces On 16 August 2017 at 17:32, Mikkel Fahn=F8e J=F8rgensen wrote: > If STOP_SENDING is moved a basic application will no longer have a langua= ge > to communicate intent. > This is perhaps a broader issue - but the question is: what are the minim= um > primitives a basic application with no advanced higher level protocol nee= ds > in order to move data on multiple streams? It relates to adding bidi stre= ams > on top of uni streams. The assertion here is that STOP_SENDING isn't a necessary primitive. And it isn't generated or consumed by the transport, even if the effects (RST_STREAM) are. It is useful in HTTP, so HTTP can define it. We might see something like that if someone ported (for example) websockets to QUIC. I can't see it being used for DNS. I might speculate and say the same about RTP, but that's so nebulous I'd likely be wrong. --_000_4ad8822827db4086a06442e2543cf9acusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The response to STOP_SENDING may be faster if it were a pa= rt of the transport (especially if QUIC transport is implemented on a kerne= l level). An application on a busy system that has written 100K to the transport might not receive and proces= s the STOP_SENDING request and then ask for a stream reset in time to save = a large chunk of unnecessary data from being transmitted.

Other than this, I can see how moving this frame to the application is a mi= nor transport simplification.

-----Original Message-----
From: Martin Thomson [martin.thomson@gmail.com]
Received: Wednesday, 16 Aug 2017, 9:46PM
To: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]
CC: Jana Iyengar [jri@google.com]; QUIC WG [quic@ietf.org]; Mike Bis= hop [michael.bishop@microsoft.com]
Subject: Re: Splitting transport and application error code spaces
On 16 August 2017 at 17:32, Mikkel Fahn=F8e J=F8rg= ensen <mikkelfj@gmail.com> wrote:
> If STOP_SENDING is moved a basic application will no longer have a lan= guage
> to communicate intent.
> This is perhaps a broader issue - but the question is: what are the mi= nimum
> primitives a basic application with no advanced higher level protocol = needs
> in order to move data on multiple streams? It relates to adding bidi s= treams
> on top of uni streams.

The assertion here is that STOP_SENDING isn't a necessary primitive.
And it isn't generated or consumed by the transport, even if the
effects (RST_STREAM) are.

It is useful in HTTP, so HTTP can define it.  We might see something like that if someone ported (for example) websockets to QUIC.  I can't=
see it being used for DNS.  I might speculate and say the same about RTP, but that's so nebulous I'd likely be wrong.

 --_000_4ad8822827db4086a06442e2543cf9acusma1exdag1mb5msgcorpak_-- From nobody Wed Aug 16 23:14:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1471F124E15 for ; Wed, 16 Aug 2017 23:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5Ceep7PYBFt for ; Wed, 16 Aug 2017 23:14:40 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 7B48F1323B1 for ; Wed, 16 Aug 2017 23:14:40 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id j189so19264058vka.0 for ; Wed, 16 Aug 2017 23:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=UfDW7oWMD3TGt7Tx1KjQFMea2CXpiGQfzaZ1kaDp4IQ=; b=QLOTsQKX6o3u/2ixHweS+tqv1UZ8+XjI/VGKZRGz80zhd11cTXvjc6eLzoBmAbG3sa UKeX3aw+yvO6Yt1RJvzz+H5+KNttGOfH9dKMif+JXITf3zCPfRBA/ACqhSliWJaiN1XR Cda5wN4tPSJ400OVXckcecj+40osH0UojVwT8RCRp/SMMOruh/XJSfu5/qNb5y970zdN Lw1rjI8DFxiECSZ16un64SKRGy5HnTEiFddA3mmRyxyChhhi0IYH5J9KkJ68adYxMTaD T9o5ff4KEfW0G2GiWC9t9us3Weg0hM3Spr4HK7rFc6UMKiB73iXl/1JocOxRsE3JttZR 5Nhg== 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=UfDW7oWMD3TGt7Tx1KjQFMea2CXpiGQfzaZ1kaDp4IQ=; b=cKg0T8nKRJuqfKtT6XhcBhjD0f2FqCBjvVWLx1obUCZJl+g328neMKRuRT1sG0uzmz xq15KL4hd1+lGKOWh6QeHAeCNyqvekOB+Fe79S7I7ofraI5kmexyNpIeU3O7v+/amUzu WrMEwqIwlT7Dyf0MHoaFpJMIpkxTTGs9DMmLKa+mB1HTwfKBpeI49UZiThtFUqo4iH3M Pc6sLcRj7ycZz7mBQQ1TgrTjWjYFclmNVxgiXbriSqSN3KEhGZIvO32VEt09+Ztk9P47 KCCKcqSiaIUyy66mu33Ec1ZnKmZ23zpaiLq3YB2/H822f0gRMOlpfz7wG2G99ElOsyJB iEhw== X-Gm-Message-State: AHYfb5hRsIofFKxbhZU9TAtg/JBlcwjm2VczqZ8Ns6EEIjmdSMnAQQgQ xZvFwqDLWpDOBoJqH507ESXNhvW42Q== X-Received: by 10.31.54.215 with SMTP id d206mr2896833vka.24.1502950479595; Wed, 16 Aug 2017 23:14:39 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Aug 2017 02:14:38 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <4ad8822827db4086a06442e2543cf9ac@usma1ex-dag1mb5.msg.corp.akamai.com> References: <4ad8822827db4086a06442e2543cf9ac@usma1ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 17 Aug 2017 02:14:38 -0400 Message-ID: Subject: RE: Splitting transport and application error code spaces To: "Lubashev, Igor" , "martin.thomson@gmail.com" Cc: "michael.bishop@microsoft.com" , "jri@google.com" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a11439272738ffd0556eced5c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Aug 2017 06:14:43 -0000 --001a11439272738ffd0556eced5c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > An application on a busy system that has written 100K to the transport might not receive and process the STOP_SENDING request and then ask for a stream reset in time to save a large chunk of unnecessary data from being transmitted. That is a good point. It is rather relevant in high volume async transmission scenarios. It can easily be much more than 100K via mmap transmit references. In some cases that application might not even want to know about the stream after forwarding a file handle to the transport. STOP_SENDING might be initiated by sub-process termination. In other words, there can a be simple process/resource control layer between transport and the application that does not know about data frame formats but still manage resources. Without STOP_SENDING at transport level this might be difficult to implement in a generic fashion. On 17 August 2017 at 07.54.19, Lubashev, Igor (ilubashe@akamai.com) wrote: The response to STOP_SENDING may be faster if it were a part of the transport (especially if QUIC transport is implemented on a kernel level). An application on a busy system that has written 100K to the transport might not receive and process the STOP_SENDING request and then ask for a stream reset in time to save a large chunk of unnecessary data from being transmitted. Other than this, I can see how moving this frame to the application is a minor transport simplification. -----Original Message----- *From:* Martin Thomson [martin.thomson@gmail.com] *Received:* Wednesday, 16 Aug 2017, 9:46PM *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mikkelfj@gmail.com] *CC:* Jana Iyengar [jri@google.com]; QUIC WG [quic@ietf.org]; Mike Bishop [ michael.bishop@microsoft.com] *Subject:* Re: Splitting transport and application error code spaces On 16 August 2017 at 17:32, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > If STOP_SENDING is moved a basic application will no longer have a language > to communicate intent. > This is perhaps a broader issue - but the question is: what are the minimum > primitives a basic application with no advanced higher level protocol needs > in order to move data on multiple streams? It relates to adding bidi streams > on top of uni streams. The assertion here is that STOP_SENDING isn't a necessary primitive. And it isn't generated or consumed by the transport, even if the effects (RST_STREAM) are. It is useful in HTTP, so HTTP can define it. We might see something like that if someone ported (for example) websockets to QUIC. I can't see it being used for DNS. I might speculate and say the same about RTP, but that's so nebulous I'd likely be wrong. --001a11439272738ffd0556eced5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
>=C2=A0=C2=A0An application on a = busy system that has written 100K to the transport might not receive and pr= ocess the STOP_SENDING request and then ask for a stream reset in time to s= ave a large chunk of unnecessary data from being transmitted.
<= 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">
That is a good po= int. It is rather relevant in high volume async transmission scenarios. It = can easily be much more than 100K via mmap transmit references. In some cas= es that application might not even want to know about the stream after forw= arding a file handle to the transport. STOP_SENDING might be initiated by s= ub-process termination.

In other words, there can a be simple process/resource control layer bet= ween transport and the application that does not know about data frame form= ats but still manage resources. Without STOP_SENDING at transport level thi= s might be difficult to implement in a generic fashion.


On 17 = August 2017 at 07.54.19, Lubashev, Igor (ilubashe@akamai.com) wrote:

The response to STOP_SENDING may be faster if it were a part of the transport (especially if QUIC transport is implemented on a kernel level). An application on a busy system that has written 100K to the transport might not receive and process the STOP_SENDING request and then ask for a stream reset in time to save a large chunk of unnecessary data from being transmitted.

Other than this, I can see how moving this frame to the application is a minor transport simplification.

-----Original Message-----
From: Martin Thomson [ma= rtin.thomson@gmail.com]
Received: Wednesday, 16 Aug 2017, 9:46PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mikkelfj@gmail.com]
CC: Jana Iyengar [jri@google.com]; QUIC WG [quic@ietf.org]; Mike Bishop [michael.bishop= @microsoft.com]
Subject: Re: Splitting transport and application error code spaces

On= 16 August 2017 at 17:32, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com= > wrote:
> If STOP_SENDING is moved a basic application will no longer have a language
> to communicate intent.
> This is perhaps a broader issue - but the question is: what are the minimum
> primitives a basic application with no advanced higher level protocol needs
> in order to move data on multiple streams? It relates to adding bidi streams
> on top of uni streams.

The assertion here is that STOP_SENDING isn't a necessary primitive.
And it isn't generated or consumed by the transport, even if the
effects (RST_STREAM) are.

It is useful in HTTP, so HTTP can define it.=C2=A0 We might see something
like that if someone ported (for example) websockets to QUIC.=C2=A0 I can't
see it being used for DNS.=C2=A0 I might speculate and say the same about
RTP, but that's so nebulous I'd likely be wrong.

--001a11439272738ffd0556eced5c-- From nobody Thu Aug 17 03:07:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D71131D27 for ; Thu, 17 Aug 2017 03:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yplgM1UPjTsr for ; Thu, 17 Aug 2017 03:07:11 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393DE13239C for ; Thu, 17 Aug 2017 03:07:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xY2253ywlz15Mh8; Thu, 17 Aug 2017 12:07:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdZOWmsJc44I; Thu, 17 Aug 2017 12:07:08 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11B0F.dip0.t-ipconnect.de [217.225.27.15]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 17 Aug 2017 12:07:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Splitting transport and application error code spaces From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 17 Aug 2017 12:07:07 +0200 Cc: Jana Iyengar , Mike Bishop , QUIC WG , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 10:07:15 -0000 That=E2=80=99s what the applicability draft should capture. If you have = concrete things that need to be mentioned somewhere, you can file an = issue there. However, as the base specs are still changing quite a bit, = it=E2=80=99s a bit hard for me to track all things now=E2=80=A6 > Am 16.08.2017 um 09:32 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen = : >=20 > If STOP_SENDING is moved a basic application will no longer have a = language to communicate intent. > This is perhaps a broader issue - but the question is: what are the = minimum primitives a basic application with no advanced higher level = protocol needs in order to move data on multiple streams? It relates to = adding bidi streams on top of uni streams. >=20 > I=E2=80=99m not sure if STOP_SENDING is important in this context, or = not, but I believe it is a worthwhile question. >=20 > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen >=20 >=20 > On 16 August 2017 at 01.57.11, Jana Iyengar (jri@google.com) wrote: >=20 >> I like the idea of moving STOP_SENDING to the application entirely. = It's basically an HTTP/2 thing anyway, so that seems like an excellent = clean-up. >>=20 >> Mike: QUIC currently does not use RST_STREAM without the application = asking for it outside of responding to STOP_SENDING; do you think there = are conditions under which it may be useful for the transport to issue = one? STOP_SENDING was the only thing I could think of, but moving it up = to HTTP makes that moot.=20 >>=20 >> On Mon, Aug 14, 2017 at 11:52 PM, Mike Bishop = wrote: >> I'm a little unhappy about that one. I see the logic, but that would = leave each direction of a stream solely in the hands of the sender and = the receiver has no way to communicate (at the transport layer) if it = wishes that stream to cease. (Other, perhaps, than starving it via flow = control.) Though I agree, it is consistent with the principle that = stream lifetime is entirely in the hands of the application. >>=20 >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Monday, August 14, 2017 5:49 PM >> To: Jana Iyengar >> Cc: Mike Bishop ; QUIC WG = >> Subject: Re: Splitting transport and application error code spaces >>=20 >> On 15 August 2017 at 10:00, Jana Iyengar wrote: >> > I'm not sure exactly what this split buys us... and it changes >> > behavior on receiving STOP_SENDING. >>=20 >> So, what the split buys us is certainty: an application is = responsible for the lifetime of streams. In return the application can = be certain that the transport won't destroy any state that it puts on = streams at a whim. The split enforces this separation. >>=20 >> This issue with STOP_SENDING is a good one. I have a solution to = that as well: move STOP_SENDING to HTTP. If the required reaction = (RST_STREAM), is an application-layer action, then we should make the = trigger application-layer as well. From nobody Thu Aug 17 04:06:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B7B124207 for ; Thu, 17 Aug 2017 04:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLbSr4-SfXrJ for ; Thu, 17 Aug 2017 04:06:02 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 07F9E126B6D for ; Thu, 17 Aug 2017 04:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502967959; l=130; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=vFL0FN1ka99KMbvz9kO8Uy8ec0BvdF3Mjq5OKVhwDsk=; b=K6j7UtqByk5HxE9LqY11rTgmt/Cv2At4YCNVgP77YmZktZ+ToOiICagmsdbIUQjP+F e8abLrpw9jv+qqstFcAbZLbzamFEhVYgaqIZyspgOVyqd2kYsu3098X9/dFmfcVZajul Dewybn7mKEX8bBFwLU4XZI45LUR6RE/QfRkhc= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWW4p8jDXe5M/g3+y+F4= X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p57B97D38.dip0.t-ipconnect.de [87.185.125.56]) by smtp.strato.de (RZmta 41.2 DYNA|AUTH) with ESMTPSA id D01c65t7HB5w9DB (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 17 Aug 2017 13:05:58 +0200 (CEST) Subject: Re: I-D Action: draft-ietf-quic-recovery-05.txt To: quic@ietf.org References: <150288734128.12601.15067017800297122554@ietfa.amsl.com> From: Roland Zink Message-ID: <5785471a-2611-3407-1121-7d584af26a08@zinks.de> Date: Thu, 17 Aug 2017 13:05:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <150288734128.12601.15067017800297122554@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 11:06:04 -0000 I'm missing a Security Considerations section. Is this planned for a later version or will it go to another document? Roland From nobody Thu Aug 17 04:27:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A25FF1321AC for ; Thu, 17 Aug 2017 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUeaa2u0N7eA for ; Thu, 17 Aug 2017 04:27:06 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC2B132064 for ; Thu, 17 Aug 2017 04:27:06 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m88so21854674iod.2 for ; Thu, 17 Aug 2017 04:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dZ0mAz9GJfSsqlwBqNeHbmu0Jqr88LsuU/zrnc4cNys=; b=j946laIk+QDppzjKdz1xz4rPDOqWeInOonol7wN9TYoBrnxjHdZ26YtRWeSEd5UnHI YTgldKHwL/ehPQgkTPPZsKetyx7geXzsma/3eZid8AOQWZV7jHS27x2gFDmDu0mKdFBu dPsM8TBUHtpCCxfHanHiZn+8TeOsv7rDUjwyCsLbL0VYOLzhJXymmAot84kwsZ2XQ9om QFelJRezYSS1Be4VtWMWCNXQmPJPEJc8Zbl2l+ykW4qLya0syTRXpH4F4GWEFd+lq+Ll YeSsPhh/ssl/plRirYMK3fKa8H22KDRxXDCMdmR6js0FTx2eKNGGW+nSQS2Py5709W/i Rghw== 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=dZ0mAz9GJfSsqlwBqNeHbmu0Jqr88LsuU/zrnc4cNys=; b=KjMjiFrmWbzoZx2UNgz0tOCqHjISdfw/1mB6k7IaNlkL6LfbWLInzHRQEh3xAFwPxn R7/SAd1oaNe2//IlVAdJ+N/UdCgJkZG5OCH83KQVvhgHdUqwsO6jIGjY533NBD+WIrKK 2+hQvqtzO1qdzLIML/6byUI16Q/LzX+WapNdwFZWVErSVA70fS6kGMa67VpAtaXSxy5D Vtfw2QfSzuLhLegcFHYceIzU7UxUeIRFahs9eqRtCoo2/DV8xg2lfpumRPYfojiW20AX vqI0xmL4LDql1xkxVUuefqS88aFZFeUZS126Fr35FqvxmsNQ9anmQSXlQhkQHOd2oKG7 trcA== X-Gm-Message-State: AHYfb5gg9DcqL61uUeSHiACNl0Yi7bWJLfGO26e7pYcNq0df8G/DBl6a BdF7UhL874VjrDtlmrgifN57hYT+KJsLS3g= X-Received: by 10.107.46.155 with SMTP id u27mr4179110iou.107.1502969225878; Thu, 17 Aug 2017 04:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Thu, 17 Aug 2017 04:27:04 -0700 (PDT) In-Reply-To: <5785471a-2611-3407-1121-7d584af26a08@zinks.de> References: <150288734128.12601.15067017800297122554@ietfa.amsl.com> <5785471a-2611-3407-1121-7d584af26a08@zinks.de> From: Martin Thomson Date: Thu, 17 Aug 2017 21:27:04 +1000 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-recovery-05.txt To: Roland Zink 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, 17 Aug 2017 11:27:09 -0000 On 17 August 2017 at 21:05, Roland Zink wrote: > I'm missing a Security Considerations section. Is this planned for a later > version or will it go to another document? https://github.com/quicwg/base-drafts/issues/740 I'm pretty sure that it will have issues that need calling out. From nobody Thu Aug 17 11:50:09 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3C2613237B for ; Thu, 17 Aug 2017 11:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXFDeM6R1jn3 for ; Thu, 17 Aug 2017 11:50:07 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D321F12426E for ; Thu, 17 Aug 2017 11:50:06 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id s143so46434302ywg.1 for ; Thu, 17 Aug 2017 11:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E9KvEniMLVDZRKfqrpYTrrw8zl+qJGKhO60cXv7eE3E=; b=iWSOSxHmB6iF9VzpruVric0UwdcAdLvT+BgJ6Z8C9erj0NlHK/RVZeqMN80DiPR1U6 A7ylCc08O7y4yzzC/vymx/cE1xHSp4k3xeq/y6nr0K4iS5Q0+yx2v2T/LIt6LNfLq4MP y2R011RreG3EIuAsR6ZE/txJSxYS9HpHKyPG5Dr78rmS1ScCTrwQayXXqOGGLBnhPnGl daStnylbGuS4AffJAIuR5Rk/Z/y/KPskRPFBJclfHDnzAwj+dAsZSwAdXdpisVznNmMT x4hntkAqgdxDtJ8PwfugQNxSMQEz8WiAxqfxXmiY5pSo2G3c+aLX/HfWJ1XVywgHIJn3 GFuw== 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=E9KvEniMLVDZRKfqrpYTrrw8zl+qJGKhO60cXv7eE3E=; b=exNSVxwi6tzqPpaLt+gbwk3dDMoQLdEbV63H2H1H0dB6XzYVV5gHAEkuBoHUnWUQ37 UhqiBgBxS2SXmQNMEYDs3GgSILm3qo3E+VS1b7+AtROUKXNooM3oUC7AUg8COvxAjmjS GM1Xi/xCYTkF6WZE+EoDNyToBRS+p0ELr2PH+B0N57DVwfNky+m9GVQfbqxF7cXWsuFd 8z27UbpLCweaC/dtGh7goWzcKGPnJJSqJn91kDQ/t4syn2HW0YkWpcyw9deBgUPgeZm0 OPscSNgIbl5/fzo7ShFy0A+cWUQRu5LS+3YpKKHPYTLuk8z3sk4B0f5m78FzOH2azPF6 akVA== X-Gm-Message-State: AHYfb5hJHMPTzrNLCo1UK7e4XdS1IvvCIeM3lfRgdPQ3zs3qVf045r9z 08ZvcKY4Y5bBqP3+qeMHQNaCQYm5DBA1 X-Received: by 10.37.22.66 with SMTP id 63mr5593224ybw.176.1502995805994; Thu, 17 Aug 2017 11:50:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.171.9 with HTTP; Thu, 17 Aug 2017 11:49:45 -0700 (PDT) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Thu, 17 Aug 2017 11:49:45 -0700 Message-ID: Subject: Re: draft-ietf-quic-http-05 and PUSH_PROMISE To: Martin Thomson Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114160fe1e27a00556f77b4b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 17 Aug 2017 18:50:09 -0000 --001a114160fe1e27a00556f77b4b Content-Type: text/plain; charset="UTF-8" Opened 741 . On Wed, Aug 16, 2017 at 6:43 PM, Martin Thomson wrote: > Open an issue? A PUSH_PROMISE is a request, and we could say that. > > On 17 August 2017 at 06:36, Charles 'Buck' Krasic > wrote: > > Would it make sense to mention PUSH_PROMISEs in > > draft-ietf-quic-http-05.html#rfc.section.4.2? > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 > (408) > > 412-1141 > > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a114160fe1e27a00556f77b4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Opened=C2=A0741.

On Wed, Aug 16, 2017 at 6:43 PM, Martin Thomson <martin= .thomson@gmail.com> wrote:
= Open an issue?=C2=A0 A PUSH_PROMISE is a request, and we could say that.

On 17 August 2017 at 06:36, Charles 'Buck' Krasic <ckrasic@google.com> wrote:
> Would it make sense to mention PUSH_PROMISEs in
> draft-ietf-quic-http-05.html#rfc.section.4.2?
>
> --
> Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408)
> 412-1141
>



--
=
= 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

--001a114160fe1e27a00556f77b4b-- From nobody Fri Aug 18 11:37:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF551321A1 for ; Fri, 18 Aug 2017 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGfM_m4Eqod7 for ; Fri, 18 Aug 2017 11:37:52 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115B4132198 for ; Fri, 18 Aug 2017 11:37:52 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id y96so70480529wrc.1 for ; Fri, 18 Aug 2017 11:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=uDIjg+oxqCSCzxb5OKVwo1lb295u99LmUW2n6jJLjVU=; b=HfF8C8tiUJDN7Q0w5ANbYuw18sRWN3wQ9mojwvXdGEVd7mA2QGKveiUyugY4LIRkqK tUOqGvVFQBmRDDELjDWidiCPVTDEe+GdPP/r2xPbixDChPdGqV7D13kgznWlrScKTcA5 H13P+WC2sJJPJSey74lGVTS27zEG87T7YbQd6p99xQO3+v/+T+z3RLw07I57RrPY+jXP p6ypfJZLFd3RUWGtwihduU0Vp+LTGSgU5+7P64IJFDOd1zso1vYAeNQ/tUSqhOTR/jo9 4+jN5CElVgXoL8hmLuSbX6eFPfO7UeV2m0Xs8BYUreRuSMi4oTTPzpEWndhgP4e6qIMw 7q5Q== 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=uDIjg+oxqCSCzxb5OKVwo1lb295u99LmUW2n6jJLjVU=; b=XyOe5KStdBlIzkSADkNAHbUEjmr/K50BmRl2yR3lUwi0/CoyM00+IEOGpQhjkWwf8W L72B+H1ITJdJ89jdo1EYu6XIjY3FGrSeWNaLQV0PxhxyhSDuK2DIx7dtTIobKaRnqqTk Fru50wt4CNxtC8D/PzzsSdkMRqGQICeeAwh2h1wGZVYMITjCq0gmIEjFzLJHYziSlwDm DxvwJjLh7itDHW+JjOVJQH8odCyEShbLM5HYXvy5+xjSHXvBoTUjKHQDtrjtmMOLveSo tSEdegOp0kPwZ7cWA+6+TVIt1BGfqd4FvVslWT8nCN4yat9+De1Vo9ifXuiO36anWi7f pG2w== X-Gm-Message-State: AHYfb5h+sj2VAHUXztkTH+lyeLmd50H5C0VQk2shjiH7ICItvDwkBbUo 7ohY3HxmHpRu4Pu5YaQrSKZdE44ZZfk/ X-Received: by 10.223.133.201 with SMTP id 9mr7201883wru.177.1503081470205; Fri, 18 Aug 2017 11:37:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.17 with HTTP; Fri, 18 Aug 2017 11:37:49 -0700 (PDT) From: Martin Duke Date: Fri, 18 Aug 2017 11:37:49 -0700 Message-ID: Subject: Transport Draft Comments, mostly about error handling To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1149221e19a41405570b6d52" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Aug 2017 18:37:54 -0000 --001a1149221e19a41405570b6d52 Content-Type: text/plain; charset="UTF-8" I'm deep into implementing the handler for a stream frame straight from the -05 spec, and there seem to be a lot of ambiguities in the errors, as well as things that should probably be prohibited: (1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in Cleartext packets of any kind. (2) Section 12.2 Stream Errors: We need to have some sort of special considerations for handshake, especially cleartext packets. In particular, any sort of cleartext packet that triggers an error should be dropped rather than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is trivially easy for a man-on-the-side to abort connections. I believe, by the same logic, that bad 0RTT packets should simply be dropped rather than reset. As I see it, there are two possible responses to problems processing the stream frame, each appropriate to different situations: - Internal error that doesn't break the stream (e.g. failure to allocate memory for the stream reassembly queue element): drop the packet -- make the peer retransmit and hope it works next time. Also do this for errors in cleartext. - a stream error that still allows the receiver to find the end of the frame (e.g. STREAM_STATE_ERROR). Send a RST_STREAM for that stream,but keep processing the packet. If this analysis is correct, it would be nice to specify it in the draft explicity. (4) Section 12. Error Handling: If a peer initiates an odd stream when it's supposed to be even, or vice versa, what kind of error is that? Is it a stream error or connection error? (5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame, is the last two bytes of the error code the whole flags byte of the packet, or just the mask (0xa0, 0xb0) of the frame type? If I am not way off base on some or all of these points, I am happy to create issues or PRs. Martin Duke --001a1149221e19a41405570b6d52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm deep into implementing the handler for a stream fr= ame straight from the -05 spec, and there seem to be a lot of ambiguities i= n the errors, as well as things that should probably be prohibited:
(1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT= be in Cleartext packets of any kind.

(2) Section = 12.2 Stream Errors: We need to have some sort of special considerations for= handshake, especially cleartext packets. In particular, any sort of cleart= ext packet that triggers an error should be dropped rather than causing RST= _STREAM or CONNECTION_CLOSE. Otherwise it is trivially easy for a man-on-th= e-side to abort connections.

I believe, by the sam= e logic, that bad 0RTT packets should simply be dropped rather than reset.<= /div>

As I see it, there are two possible responses to p= roblems processing the stream frame, each appropriate to different situatio= ns:
=C2=A0 - Internal error that doesn't break the stream (e.= g. failure to allocate memory for the stream reassembly queue element): dro= p the packet -- make the peer retransmit and hope it works next time. Also = do this for errors in cleartext.
=C2=A0 - a stream error that sti= ll allows the receiver to find the end of the frame (e.g. STREAM_STATE_ERRO= R). Send a RST_STREAM for that stream,but keep processing the packet.

If this analysis is correct, it would be nice to sp= ecify it in the draft explicity.

(4) Section 12. E= rror Handling: If a peer initiates an odd stream when it's supposed to = be even, or vice versa, what kind of error is that? Is it a stream error or= connection error?

(5) Section 12.3 Error Codes: F= or a Frame Error on a STREAM or ACK frame, is the last two bytes of the err= or code the whole flags byte of the packet, or just the mask (0xa0, 0xb0) o= f the frame type?

If I am not way off base on some= or all of these points, I am happy to create issues or PRs.

=
Martin Duke

--001a1149221e19a41405570b6d52-- From nobody Fri Aug 18 15:22:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7611323A5 for ; Fri, 18 Aug 2017 15:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9jtFShJf3Bd for ; Fri, 18 Aug 2017 15:22:32 -0700 (PDT) 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 2F98D1323A6 for ; Fri, 18 Aug 2017 15:22:32 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 49so65481954wrw.2 for ; Fri, 18 Aug 2017 15:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0I7FhDSg736k+tKw6r9QL94I5vuJsNC+qed3/STUb1A=; b=D7777xXgvzMnpxslkPH8yh7X58JRAb4DMr9v9jSYwI6I1oXLrSya0C47krIpAJ2cZ1 sNIyrtALhtnJVhzzcjxc/KmbzRkuaWOrFzsx3YxA40tBwKoluzJI6gghWYcDr7TZZ7/N hQ1qh4mhAyYN9P0hEpYloUO0tnMZuUSQNjvm1LSrghXBE50Zqeh1BNfbKb9OtrRUxihF f8VzozVeZSomcObPgCxI1zbIbUGr2z3lJk6+wLAIKY5gifMBw40QzSKpgyukhBpZUHpG E6gqaCiL5hrkxH1GFpTEDS9nUWA+W2bWNv8GKIpUJ3GMHLNWtq7BWpKB/O6qTSjr9P6L nzgw== 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=0I7FhDSg736k+tKw6r9QL94I5vuJsNC+qed3/STUb1A=; b=bA0SoRPEQJ6TMiZDmlr92geJSi3KsbGsh1/8O1g1BKPdCaqqp8fG9p6BCHNXhfnmbI TOJ2YZRPN0aMcAEx6JY3RxWqkcCtkHL/9tQkr3A92wg7Sde2d0lpa3GJP4yB3CHMGXxx LcFra2cuWIy+sdTVTZCNmHaHqaulzq7WQgUpjMzyJx+kqsIrwtZZCWO/9poSBlmrJVpZ JI44hzJsez8DHsIDTYic55p6kT5utJ6dZt/M5w4+KzLekEAUnqukkcbK5iTP8Qf/5/Rr stQusXAaxTVLoIKQLyt5G7tiew+U8E3IiwEEURXOxG91plsMNJNvpG0rnROHWOLalBgC lAcg== X-Gm-Message-State: AHYfb5hFXPcvwR4e9fRKe51i69lSBf3jkJK6Jwhqb/BRDYL0tfs53wIN gnk3x3yrhDSzk6U21LLBmZS4HgEk9LJG X-Received: by 10.223.173.182 with SMTP id w51mr3022873wrc.113.1503094950495; Fri, 18 Aug 2017 15:22:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.193 with HTTP; Fri, 18 Aug 2017 15:22:29 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Fri, 18 Aug 2017 15:22:29 -0700 Message-ID: Subject: Re: Transport Draft Comments, mostly about error handling To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045cf65e96c78805570e9070" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 18 Aug 2017 22:22:34 -0000 --f403045cf65e96c78805570e9070 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Aug 18, 2017 at 11:37 AM, Martin Duke wrote: > I'm deep into implementing the handler for a stream frame straight from > the -05 spec, and there seem to be a lot of ambiguities in the errors, as > well as things that should probably be prohibited: > > (1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in > Cleartext packets of any kind. > > (2) Section 12.2 Stream Errors: We need to have some sort of special > considerations for handshake, especially cleartext packets. In particular= , > any sort of cleartext packet that triggers an error should be dropped > rather than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is > trivially easy for a man-on-the-side to abort connections. > =E2=80=8BWhile I'm with you in spirit, I'm not sure about this. One downsid= e of such an approach is it means that if the peer is actually broken, the local endpoint must keep the connection alive until it finally decides to abort the handshake. I'm not sure how desirable this as. As for attackers, I suspect it's just as easy to close the connection will a well-formed packet than it is with a malformed packet. > I believe, by the same logic, that bad 0RTT packets should simply be > dropped rather than reset. > > As I see it, there are two possible responses to problems processing the > stream frame, each appropriate to different situations: > - Internal error that doesn't break the stream (e.g. failure to allocat= e > memory for the stream reassembly queue element): drop the packet -- make > the peer retransmit and hope it works next time. Also do this for errors = in > cleartext. > - a stream error that still allows the receiver to find the end of the > frame (e.g. STREAM_STATE_ERROR). Send a RST_STREAM for that stream,but ke= ep > processing the packet. > > If this analysis is correct, it would be nice to specify it in the draft > explicity. > > (4) Section 12. Error Handling: If a peer initiates an odd stream when > it's supposed to be even, or vice versa, what kind of error is that? Is i= t > a stream error or connection error? > > (5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame, > is the last two bytes of the error code the whole flags byte of the packe= t, > or just the mask (0xa0, 0xb0) of the frame type? > > If I am not way off base on some or all of these points, I am happy to > create issues or PRs. > > Martin Duke > > --f403045cf65e96c78805570e9070 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Aug 18, 2017 at 11:37 AM, Martin Duke &= lt;martin.h.duke@gmail.com> wrote:
I'm deep into implementing the handler for = a stream frame straight from the -05 spec, and there seem to be a lot of am= biguities in the errors, as well as things that should probably be prohibit= ed:

(1) Section 8.14. Stream Frames for Stream 1 and abo= ve MUST NOT be in Cleartext packets of any kind.

(= 2) Section 12.2 Stream Errors: We need to have some sort of special conside= rations for handshake, especially cleartext packets. In particular, any sor= t of cleartext packet that triggers an error should be dropped rather than = causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is trivially easy for = a man-on-the-side to abort connections.

=E2=80=8BWhile I'm with you in spirit, I'm not= sure about this. One downside of such an approach is it means that if the = peer is actually broken, the local endpoint must keep the connection alive = until it finally decides to abort the handshake. I'm not sure how desir= able this as. As for attackers, I suspect it's just as easy to close th= e connection will a well-formed packet than it is with a malformed packet.<= /div>
=C2=A0
I believe, by the same logic, that bad 0RTT packets should simply be = dropped rather than reset.

As I see it, there = are two possible responses to problems processing the stream frame, each ap= propriate to different situations:
=C2=A0 - Internal error that d= oesn't break the stream (e.g. failure to allocate memory for the stream= reassembly queue element): drop the packet -- make the peer retransmit and= hope it works next time. Also do this for errors in cleartext.
= =C2=A0 - a stream error that still allows the receiver to find the end of t= he frame (e.g. STREAM_STATE_ERROR). Send a RST_STREAM for that stream,but k= eep processing the packet.

If this analysis is= correct, it would be nice to specify it in the draft explicity.
=
(4) Section 12. Error Handling: If a peer initiates an odd s= tream when it's supposed to be even, or vice versa, what kind of error = is that? Is it a stream error or connection error?

(5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame, = is the last two bytes of the error code the whole flags byte of the packet,= or just the mask (0xa0, 0xb0) of the frame type?

= If I am not way off base on some or all of these points, I am happy to crea= te issues or PRs.
=
Martin Duke


--f403045cf65e96c78805570e9070-- From nobody Sun Aug 20 23:24:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA18F1321F0 for ; Sun, 20 Aug 2017 23:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC3ygYqTjUjP for ; Sun, 20 Aug 2017 23:24:21 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B54113226B for ; Sun, 20 Aug 2017 23:24:21 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id o196so3129193ioe.0 for ; Sun, 20 Aug 2017 23:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=faYQmuflyUCK8MQeBMf9D9zBFV4+KR8GiQqUErvldMg=; b=EGlw/dsfhhllD2wJfPAVnQMmm09zab0V9jzWqb7fFLNzAcI+XDp71MIl9hj6QLlBTK c+bD31XRDtaOM/1Sneva4OO2WnlrIBLH/B1JpGKeC1QypugjIMaj23U+ASXIM/v+eyEk udfdY9U77eteRGtT6Yt1wzTAxqkDMU7KB87cyLahJK3kJETMnbzVUIhxWxp/CFvpso+c 5FmnWLuIw6lBy6Uu+sMZ8e+/6IFF0QdUJhwbgtprPx7Wlm6KwNgiDqAu4BW7DrjOpU3l /P3LXO//1+1/TPNDlGVJQ3Dl/xz7FjnWA1gSO1v9fobA6up605jDEObG+j4n8FF76xpG K7Ow== 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=faYQmuflyUCK8MQeBMf9D9zBFV4+KR8GiQqUErvldMg=; b=AYKIe84wSsRrInbu84Ai9GWeaOEOaXSGKU1P7PzZX1rrWsjwMIcTNJgniSRnaZdGFW lNec1NpZvHgKgVEMH4Z2NGwj0gPkBMPnHGDL2yswbhDc1/+y4/7tL/Nt5V0NCqHW0ZmQ KeY3ixlAXx+3bUq9pPYbSzoEvR65h/m8hLE85AS3aj7s5+1CTawDjePZu7X/FhXgSB1i N9NDfyOZFVQxId2beVT0y10hi/m9VgMmSd5u/G67HJbcTPepO84Szwx6eT+/FU5kpQaN mNTw7qB0JzYPk7tMkadD0RYZPUNdk9vRC0F3CpaeRDv/lp1nU5ILWxVtga/Ep7gIsuU1 kYtw== X-Gm-Message-State: AHYfb5i+fMezvVxGUkSf6MxsNRveWF0aomjlJz7ixKdaIyUZdO/2aRXI pUez8GSIW9N1TAClHWSZImzkbLbupg== X-Received: by 10.107.46.155 with SMTP id u27mr14313614iou.107.1503296660302; Sun, 20 Aug 2017 23:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Sun, 20 Aug 2017 23:24:19 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 21 Aug 2017 16:24:19 +1000 Message-ID: Subject: Re: Transport Draft Comments, mostly about error handling To: Ryan Hamilton Cc: Martin Duke , 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: Mon, 21 Aug 2017 06:24:23 -0000 On 19 August 2017 at 08:22, Ryan Hamilton wrote: > On Fri, Aug 18, 2017 at 11:37 AM, Martin Duke > wrote: >> >> I'm deep into implementing the handler for a stream frame straight from >> the -05 spec, and there seem to be a lot of ambiguities in the errors, as >> well as things that should probably be prohibited: >> >> (1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in >> Cleartext packets of any kind. >> >> (2) Section 12.2 Stream Errors: We need to have some sort of special >> considerations for handshake, especially cleartext packets. In particular, >> any sort of cleartext packet that triggers an error should be dropped rather >> than causing RST_STREAM or CONNECTION_CLOSE. Otherwise it is trivially easy >> for a man-on-the-side to abort connections. > > > While I'm with you in spirit, I'm not sure about this. One downside of such > an approach is it means that if the peer is actually broken, the local > endpoint must keep the connection alive until it finally decides to abort > the handshake. I'm not sure how desirable this as. As for attackers, I > suspect it's just as easy to close the connection will a well-formed packet > than it is with a malformed packet. The minutes from the Prague meeting should show that we agreed that we would rely on protection against off-path attackers only when it came to disrupting the handshake. From nobody Sun Aug 20 23:27:35 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B427E1320BE for ; Sun, 20 Aug 2017 23:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpkNjBXA-MDT for ; Sun, 20 Aug 2017 23:27:32 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 6EFC5126B71 for ; Sun, 20 Aug 2017 23:27:32 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id 76so28060458ith.0 for ; Sun, 20 Aug 2017 23:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YiN8fpSoyqPatYlBzOYhMISk93Ae/y2z4tfrx/C9wcA=; b=LOtWMboyQ9nY1fd1D9Jgtw5zbwrtHeGUzVc/OyfkIRs+NVdJK/JMz98ZyneaU7zoYf ZIJjhIaUZj8sdHQsGlSNxduz1fs8WeZdNGlq/Bc3Qtdk6SWu5JQ2fMEhYi0sYBgOrnhN RAEwvhlN1bTnfkI+yao8oy9IkBD7/TL6ULRHhHymjhA1nZ71o3CpA5eBZqt4ZPrh1v4b oD2TWbLaP0sH/qVx6EG72A19aTC+J08miTflk96UH2RlhY/J63HV/FN6XfG1iRMw7NFA O+6L3shLbaV/bdul3HWCkQ4PWEIVk0QFYjlE6H1gvZXjb96i2Fe06fX2WFXqnVdIFnim 56RA== 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=YiN8fpSoyqPatYlBzOYhMISk93Ae/y2z4tfrx/C9wcA=; b=tmVCn/36CvUdl5tlHYqv6/2F5VH/QVRNS+TTtp26A0GFnFP1wgVnTO7OIVBpfO8uev f3chvhPQ1tdb8Ms3OSFsO/Kd7mA9zERx+z+DI8ZPidqjf05J7zR37V8zK+7ZtnXMxbsN ufKACdzn+pdbpd+ZQ2U/g5g2MBOGp2YfEvQvwG+0v0ESM6uY3ZeXgTdwgfYoEkdUxvgb 8zjeKdnUR5n+fyxxgUgzJq+UYChXuJLNnM+y/B7JRSx7iuzDCiV0fBg0IYWVEhsHKeIN iEv4s+V+iOo+5lFPng6/5Uh92c5zk93FeaKNRBxoIqbQsaEJVLATv8FYg1UYh4gS5f6R cCpQ== X-Gm-Message-State: AHYfb5j5Y6I+aH6DYacjTt8Q51DYwggiyjXw6+GmrqopjIy0lsrL6z+R idrKuBXk+tI0mobGp0TMXWZTVDsTYQ== X-Received: by 10.36.253.198 with SMTP id m189mr3539068ith.165.1503296851813; Sun, 20 Aug 2017 23:27:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Sun, 20 Aug 2017 23:27:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 21 Aug 2017 16:27:31 +1000 Message-ID: Subject: Re: Transport Draft Comments, mostly about error handling 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: Mon, 21 Aug 2017 06:27:35 -0000 On 19 August 2017 at 04:37, Martin Duke wrote: > (1) Section 8.14. Stream Frames for Stream 1 and above MUST NOT be in > Cleartext packets of any kind. That should be in the -tls draft (though it will eventually move to -transport). > (4) Section 12. Error Handling: If a peer initiates an odd stream when it's > supposed to be even, or vice versa, what kind of error is that? Is it a > stream error or connection error? Since all stream opening uses authenticated packets, I think that connection error is appropriate. Also, I don't know how to recover from this situation gracefully, particularly if the numbers collide. That said, it makes the h2 settings situation bad. > (5) Section 12.3 Error Codes: For a Frame Error on a STREAM or ACK frame, is > the last two bytes of the error code the whole flags byte of the packet, or > just the mask (0xa0, 0xb0) of the frame type? The entire byte. Thus, there are many error codes that represent STREAM frame errors. (I agree that that could be difficult, and it's something I'd be happy to see someone open an issue on to track.) From nobody Mon Aug 21 12:18:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1FD132709 for ; Mon, 21 Aug 2017 12:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXXIfK7q8Nxs for ; Mon, 21 Aug 2017 12:18:55 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EB351326FE for ; Mon, 21 Aug 2017 12:18:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,409,1498546800"; d="asc'?scan'208";a="212586023" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx143-out.netapp.com with ESMTP; 21 Aug 2017 11:49:40 -0700 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 12:13:47 -0700 Received: from NAM03-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.1263.5 via Frontend Transport; Mon, 21 Aug 2017 12:13:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1G47scYRxEfLkpXBNsYuGSilZ4dEq1EisDN9TpXUXgE=; b=Qyx9+rTevNFHTBXUHfBqae4Z3OttePGmoeyf5bLAn8W3JoWRL3rNqqf0xduTlYVibYIpf1yDvLwfosYOiPzaxBtTM2Zdhe0XpQnDjancRNAyXMLKHnXPuTPWslSsmSRXIHlCF22w4Ia3Z20diTKx3uqScw5s7956nhKX66blfRI= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB227.namprd06.prod.outlook.com (10.242.191.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Mon, 21 Aug 2017 19:13:48 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1362.019; Mon, 21 Aug 2017 19:13:47 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Towards a Scalable Modular QUIC Server Thread-Topic: Towards a Scalable Modular QUIC Server Thread-Index: AQHTGrGdl5mGISyzLEKwofxMmMDFMg== Date: Mon, 21 Aug 2017 19:13:47 +0000 Message-ID: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2607:f010:2e9:17:1030:b066:3f74:551f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB227; 6:i9HvaVSv9k0VpXK1QITifxuxRH0pK5b+Hygyz0hl3sVtOQ9KhbP3Nqvt7Oiz+wcfLK3hWYozMuQ1wRmyMDpzp1UYDzwMdKSD6v5s4wbfT5lom9r5QaOJ+/1hM1kEvZHl0xwveCY5knG+XCFMghV5JFf/pPZOBlW6o1orEJo/Oobf8yII9i+dbzu/qgGDYHm8eA1f4nyjeH43hPxx6Hi0x2C2o61Mmt7RZqflMVNq/8tkz3lxMXH8euM4aRQEjNG+Y2y0M7KqH2O/XlpL+sXGVrz6FgvbHNSUFNNffRzDQWU9hPh+ExSB5pW7rCQp2Dmxe4DcfdgJg1dhLYRefGUiNQ==; 5:52Ia2KQiLHzXYiM9DovKJl5ZOLgCi9YehGgRuSAL3mg9MXLkCceO9Kh2S7jwX2Vfx9NrANPDrjvnaspKzsSIztj6scQZJcdkw2EKYnzA757bCA6nxEcadLjuQXlJm22ST2TZrNwoYoIXBWvehezpMQ==; 24:ZOjB2l14QhchkKz/bZbp4ZnHT7XiHjlmNykQMCt7AKMUcbZMuQPZziH3Eip1JkzD0uIXHr3dPtWgLzjzcac7iZQtQUEnROjf/YDtiebMrpM=; 7:DlGtHyj7ACfvJpJnhL9EtmZPiNUzNxS1Up7A/VVzo8M2TBMajXqmxP1v2Y5PfMUOMyRFTcQX00H0RKTS3fOIOfikffG35k+jz+l4Fyq880gPaT9EOSxKP3jEuYm/uGLInn8S3KnHHwhTUpwSTCMvXBDguClGZ9WroegjHmBqHN6t0Gz5bgO1ShagUiEFA6pBAl1UMxPXXYjcNW5xUYx/rd2hBTtYl684vQOd9L42XHg= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 356a8160-fe06-4a60-67f5-08d4e8c8c004 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB227; x-ms-traffictypediagnostic: BLUPR06MB227: x-exchange-antispam-report-test: UriScan:(165104125076784)(158342451672863)(101264311250101)(213716511872227); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB227; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB227; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(199003)(2900100001)(2906002)(6916009)(57306001)(6436002)(33656002)(966005)(53936002)(5660300001)(6506006)(101416001)(3280700002)(50986999)(50226002)(97736004)(8936002)(105586002)(189998001)(82746002)(99936001)(3660700001)(6306002)(106356001)(68736007)(110136004)(83716003)(99286003)(14454004)(8676002)(7736002)(305945005)(86362001)(6486002)(6116002)(77096006)(102836003)(25786009)(6512007)(36756003)(81166006)(81156014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB227; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_D52C9A34-6774-4837-8BA7-22DC6FE300F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 19:13:47.6668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB227 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: Mon, 21 Aug 2017 19:18:57 -0000 --Apple-Mail=_D52C9A34-6774-4837-8BA7-22DC6FE300F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This was just presented at the SIGCOMM KBNets workshop: = https://dl.acm.org/citation.cfm?id=3D3098587 Yufeng Duan, Massimo Gallo, Stefano Traverso, Rafael Laufer, and Paolo = Giaccone. 2017. Towards a Scalable Modular QUIC Server. In Proceedings = of the Workshop on Kernel-Bypass Networks(KBNets '17). ACM, New York, = NY, USA, 19-24. DOI: https://doi.org/10.1145/3098583.3098587 Possibly of interest to some. Lars --Apple-Mail=_D52C9A34-6774-4837-8BA7-22DC6FE300F2 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----- iQIcBAEBCgAGBQJZmzDrAAoJEFS1wwm/cMFXkhQP/i/ZvN7GnBDkWnD3WV6stR6L uhqWmNMlbelthBW2tUM4RCwUfPArmX9vfFegCOIw95XE0yDuSvF0CMwF48a2+0IH 2eE5uWhvi0ZGYbjHOC15h4MT7Mb/LgEhSpzNvrbM68an+Jza5L9dUYLMy9zqUFMD K61zdMeEIKVNmFVnKptt1IMAdxdKFdyC3UEVpMEvBhWEqqd9STXw/3GpnbcjyzVD PY3OLAUWqVxvdaW630Xfg3ex6/ZB0bduNN5QzNk+4Lj+L+GOTw6jRz8trTkjyDwA dMOx4oR+UHfKdGkiA0v+X0Ov2FMaJaIUQRwR8/488NRWjIMBmWdiQt/uGJ5Dkws3 cZxQlK35hUR4ykkskNqTBvpVxLny7ud2tOKV4/mEYISqJAPNZUCoZGlVEHrM7Vcb PhGz0DhAi1fLDWRXbU45kNoGB37VhjWmM2E/3jP6vsQ2IfjmjzgmfN1aNRug4/OZ 8uaAaJQovUjsxdSeAhUYtCsmop3XcrAG1zXEzMLTNDJCjgxWjEUTuGmmKMFZI1t7 4LSFUSz16/UbjGPAQA0s1hLxnnRbFkn5bXprMb3QJpZzmk+ZFAcrhYEqnOwJ+N0+ Bclq0yys/hAXEYbysbP3pT/5Ml6RtaJF5upAAvZoqvyIgNTcqq2ebnAEE+SFOC6Z ZsL8RSSAO9w6XTHhyTJO =ZvNa -----END PGP SIGNATURE----- --Apple-Mail=_D52C9A34-6774-4837-8BA7-22DC6FE300F2-- From nobody Mon Aug 21 17:06:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F9E132ADF for ; Mon, 21 Aug 2017 17:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGXzjj2tOGKd for ; Mon, 21 Aug 2017 17:06:51 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4021132ADD for ; Mon, 21 Aug 2017 17:06:51 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 1so22088250ioy.2 for ; Mon, 21 Aug 2017 17:06:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pfXH1DFft8GRdWNiswlJfKQPbBodOMFluJn4lLpG3gg=; b=LNPz6tGK3sa91ewM5G9MyzkbvRDQIA3iE6ZLlH3yp4GV97RLgRijEuwAp1TgccvK4f 99CSiJ8iLiVmcSuuX5wFAJhbww4+ZEfiVnzSsLAThe9ThxhI7Xb/aQFcBZRj3lOhVvai WK3vyDbyRYTCBHCx/Fd7GImB3P5YKrb6PD54U9ntG2BhEzmY4e++v1Rvt3QkLsJRD7lY nSONugzwYq5CsAwe9GFN4rDAHSgMah/7uPrNBe7HD5GH2t3+e7mmW11AsAf2ijnq0Wex Iq49dwea3hOcf4F5w8wC3pwH856Ocyjjl7Nr8nk8u2IyOaKKdH+6oiK2bzvek0zZFNpc hQcA== 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=pfXH1DFft8GRdWNiswlJfKQPbBodOMFluJn4lLpG3gg=; b=LX6VDAJVikQThPvCBpIw+aIhohpLIDWKw34SE3GpsvSCYTsqp9evHAsw5ZeHa+Cj0b k/TLug+O2tHxZti24usMK9yZuN+QOxnG+cl18J//KfpbtKGyQmTTBc++Ajm1MtsVteQu lP6Wu8TWsOAp5czKxp6Jns5qIUAjS/mcXPGIA1IpdPkCVjDQvNulKj4WtBKZ40rHbjf1 XuwGgV0hHWMrBKJ1/XdQyev+l26dXRzKIVf+Te1dmcNVK2jg7e7g87hMp/fDlBFRuj3/ VTuRx3T+3eTZJcriL9jpqe2/v0XC+oWI2Wu+AtlOHenr+RstHSYw8O6yuhdIbKil/OvL 4Srg== X-Gm-Message-State: AHYfb5hehGf9VTJgPc/fQAVU8owXfZ2R0dHsLq2QP5ebQY3WRBxEgcr+ 8skW4A+HOpRn/0P8BQsjEtkFPv5TDiKF X-Received: by 10.107.27.10 with SMTP id b10mr17724883iob.241.1503360411047; Mon, 21 Aug 2017 17:06:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Mon, 21 Aug 2017 17:06:50 -0700 (PDT) In-Reply-To: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> References: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> From: Martin Thomson Date: Tue, 22 Aug 2017 10:06:50 +1000 Message-ID: Subject: Re: Towards a Scalable Modular QUIC Server To: "Eggert, Lars" 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: Tue, 22 Aug 2017 00:06:54 -0000 Clearly the authors didn't understand why RSA was chosen by Google. On 22 August 2017 at 05:13, Eggert, Lars wrote: > This was just presented at the SIGCOMM KBNets workshop: https://dl.acm.or= g/citation.cfm?id=3D3098587 > > Yufeng Duan, Massimo Gallo, Stefano Traverso, Rafael Laufer, and Paolo Gi= accone. 2017. Towards a Scalable Modular QUIC Server. In Proceedings of the= Workshop on Kernel-Bypass Networks(KBNets '17). ACM, New York, NY, USA, 19= -24. DOI: https://doi.org/10.1145/3098583.3098587 > > Possibly of interest to some. > > Lars From nobody Mon Aug 21 17:18:44 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20E5E132AE9 for ; Mon, 21 Aug 2017 17:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37tzq2wb3ZKb for ; Mon, 21 Aug 2017 17:18:41 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1930B132AD9 for ; Mon, 21 Aug 2017 17:18:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,410,1498546800"; d="asc'?scan'208";a="212635703" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 21 Aug 2017 16:49:30 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 21 Aug 2017 17:13:38 -0700 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.1263.5 via Frontend Transport; Mon, 21 Aug 2017 17:13:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dKTHOMDE6vOlyXgmqYKjcujwhQMBhGQe3hqddd0+akQ=; b=ktox5tchtpDBMW7LJ6Yzjdyru9sA+nQwd+D70I4BJV6NgyZsbGwoy/mxj6bGB31u11723JIGTMl13W2TRhKjD3tZB4gLrP/hz9k8AiwjlMgaOPHaVKRfEdlAdK6ZKqkJDP0NmTcTfJRVroPWop53550TFpl6OG3oIux8rnqJhzE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB179.namprd06.prod.outlook.com (10.242.190.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.18; Tue, 22 Aug 2017 00:13:37 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.01.1362.019; Tue, 22 Aug 2017 00:13:36 +0000 From: "Eggert, Lars" To: Martin Thomson CC: IETF QUIC WG Subject: Re: Towards a Scalable Modular QUIC Server Thread-Topic: Towards a Scalable Modular QUIC Server Thread-Index: AQHTGrGdxY6rwbYzl0+5SsqL/mKzc6KPf7cAgAAB4gA= Date: Tue, 22 Aug 2017 00:13:36 +0000 Message-ID: References: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2607:f010:2e9:17:c10a:5918:1a07:cbaa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB179; 6:IKinQydtWsUYUX/uQFg/ecelQ1ehELeX7EOihO8N6iyIdX7VsOQy4Oxr6PvOHKjg/MpferI44tBbUwmNMfPyy9CS5+9zdfBqltaY2ces2luYBEjqHmM43JnzRNTpQce/L1K1pVpXvNDaZBJNStfMahor8gw118nNYW1cFECpeMgZm5lp+jC7E6bV8ehAEsknIaRDu4vHv94Xf+Tf9vSMhkfdZfbGGSerHS1FcRU08Qobm4SX9n4iDGsBONQwTEDOMd0DvcMk+3//NYOMCFokNrQAlgrZCKyTsTl7dV1/tNlDL+ZAtsoJtXG6CTnL3HrQl9OYUhpzchZaRCfBq+kolg==; 5:NiwW0R2eHfdsdVlvJjHBJl+wIB7XBwhju9aW6NWQxL+2nPtEjKPt3W4VJHQhPLrMgYOmnvcprURX5qaZPcnbsnWFmfU8jCpeEnWqoj345dJtHwsz33WqpOfaj4J7bDXLkt8pIKy01leDZzkhagkVCw==; 24:uvk3OfQ6aGBFQ6ARMfr2kPD5cZ08Kpt6WH5OaQdZCFFmLfrO/8wsQxh0wf6rnHsxKGDKEZ9gmTSYjL5jSDP8I1R2zFeUxJYAIt9UbtGN1+U=; 7:XuAjxguqaqQEowngFV+8iu1gF8hwHZhKwzCzbS2nrs8VFBpyCFo0QHzQerirgtvLDEjVdztcz8PiV0hykUSLGeki05pYLjmKvwqez6CL0kBKX36XaIAB0K/22x/wQ4d2rW7Ra86DiN12ELuzpRHKLpCWqNBEgn2AdbEddYmqN9kaZa2rzXFlq10dBVlc2l1/JWcicRdCP8xtciMw3y7ki4xd6B72Bi8SAV3hROtPPAo= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 36e5163d-56db-42b2-46f2-08d4e8f2a20d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603160)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB179; x-ms-traffictypediagnostic: BLUPR06MB179: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB179; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB179; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(199003)(189002)(377424004)(53546010)(53936002)(25786009)(83716003)(102836003)(6436002)(6116002)(8936002)(558084003)(105586002)(4001150100001)(36756003)(106356001)(3280700002)(110136004)(6246003)(229853002)(57306001)(5660300001)(2900100001)(3660700001)(6512007)(99286003)(82746002)(305945005)(478600001)(7736002)(86362001)(68736007)(76176999)(189998001)(99936001)(39060400002)(97736004)(50986999)(2950100002)(4326008)(6506006)(14454004)(6916009)(81166006)(8676002)(81156014)(2906002)(50226002)(6486002)(33656002)(77096006)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB179; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_94D95FFD-6C17-4525-A6EA-0F17472EB2A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 00:13:36.3497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB179 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, 22 Aug 2017 00:18:43 -0000 --Apple-Mail=_94D95FFD-6C17-4525-A6EA-0F17472EB2A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-8-21, at 17:06, Martin Thomson wrote: > Clearly the authors didn't understand why RSA was chosen by Google. I asked whether they had thoughts on whether their results might be = influenced by QUIC-Crypto and if IETF-QUIC might perform differently... Lars --Apple-Mail=_94D95FFD-6C17-4525-A6EA-0F17472EB2A3 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----- iQIcBAEBCgAGBQJZm3cvAAoJEFS1wwm/cMFXh18QAM1CDJjuLS6IwbEFjy2S0ora lCvmGp9Lu2b8PWd0AG9xuMSf7ylX2ssOzTwvgK25Tao+8phxi60dTsbdNO3LQwHa Q25WI4jThPrR0CDWAConzTjGducOUiybXVByb4OVXCN84ti25XDkddNtK7m4tbR2 lyqkdx+Izadxg4NswQb2rwL2iPBtO471Mz5dWSkrcketC2JHvNiXoKPt0KQMnS/E +UOMXpRSvdqc2Ze8TjBLd5lb3jP+gZyenUPAhwy3wIngUFCHxTRFssRr+22B4X+k APbi18HDs9qN2uCEnKkP3bVPn78x19MB0BLES+rcSwW4d/0qBKgATOFlgvNUKzb7 9x1XSbG1nThhtm1PARQUKpcs/AelVflBQ0p8D/J1NTkRYKLfpy9whRqw923k8jDy Pudq+rRWu/jIhgQc5ax3rqu5ASw+Ham4wswRX2yhVcjEomgnId6y0ewslog+o5la j5LrcAG0oGSDGGUTmetADHdH9lTYxjKY/TTaNmPt1zlqK+aPFoOqqwlaZR/k1RH1 RWoTFgNZHSTNVffLQKk3FimpHCfrcZQc3Spu/cfwHGrovqz2bQDFO2EftsIb0v+u /1Xk9MXUjh09V1tg8ish/Q2ZDcWdAYUnY8eee5g+lnDCDd8HmtobwdgQcGioW4mu nBjdGt5VdMJRKboiq84h =IwjI -----END PGP SIGNATURE----- --Apple-Mail=_94D95FFD-6C17-4525-A6EA-0F17472EB2A3-- From nobody Mon Aug 21 17:21:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B2132AE4 for ; Mon, 21 Aug 2017 17:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsCYTb4AOvlo for ; Mon, 21 Aug 2017 17:21:17 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAD3132AD9 for ; Mon, 21 Aug 2017 17:21:17 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id o196so11154866ioe.0 for ; Mon, 21 Aug 2017 17:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O/4F5JbMZRbJ4hfeOEWxHHraJssfBfZ1Hn8yJWqPgfU=; b=LYO30YBn6iOSa+USRfK8dJ4rj0cR9fOXu86c3Uh76ZGGED9Dqe6UkQKHCYjG79lHYN FK4nPBtF0V7uv271qeDX6IFQbvWlJcgRiWN9kOpRLVO843pxwF35Ll0tPSTIwuhIT9wJ wpAhCkgsRnKBpwAFbuaOnd7beqfpE0LKlJThtY45laAgO4LFLBoiD3yVqHG/TDi1Kye+ IL+WvhOWEGNz5EVFmRtKC9uayT0IN6bkpRwgEZJDceVnyvMF2U76d5QXIh3+lByFkStJ 0N2OKR3dNfusG5kMhamynLqS795mLMPR3i8P87teTjDn6RNfXTh4yD/neeWU2grXqSAw whgQ== 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=O/4F5JbMZRbJ4hfeOEWxHHraJssfBfZ1Hn8yJWqPgfU=; b=OGb5PGsI2sPGUEbT5KtNhgpU9EiHfAHToP8l3IA4QEKAfXKLzuyoM5fCQRZ2xYpQ00 VBStisYZhzEblMxRlEUldlkhh/dHSwt8ABALV6INWJhs8uN11rvWLlk11GNG97eJ9U1d On0uCqg7qC/oEUOzYp4bRZqdrvVTjyfYkISj1gFVAnvBL3EYdcrXEqFf9HvHxJaA4H2c G7x1/LxLYykN6ShZBDpte3FOJQC2wPvGwYSGsnZ9gExDcN/eU9/cgSlWKNpAnV3MZClC ni7ZNllaNKcnzw9oyMboDPyZXhDsqdOQVn7GaLxY4PKMNEiVeECGx6UL9yOoU27lyf+J AYZQ== X-Gm-Message-State: AHYfb5jG9QxKeReh67mYpCxAwpbpR3VIrtQv9Ly322DkgiU0WPPitodI VcS9QtANuRYqjXGBHSeJDgGa27APWTCC X-Received: by 10.107.9.203 with SMTP id 72mr10145409ioj.72.1503361276396; Mon, 21 Aug 2017 17:21:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Mon, 21 Aug 2017 17:21:15 -0700 (PDT) In-Reply-To: References: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> From: Martin Thomson Date: Tue, 22 Aug 2017 10:21:15 +1000 Message-ID: Subject: Re: Towards a Scalable Modular QUIC Server To: "Eggert, Lars" 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, 22 Aug 2017 00:21:19 -0000 On 22 August 2017 at 10:13, Eggert, Lars wrote: > On 2017-8-21, at 17:06, Martin Thomson wrote: >> Clearly the authors didn't understand why RSA was chosen by Google. > > I asked whether they had thoughts on whether their results might be influenced by QUIC-Crypto and if IETF-QUIC might perform differently... ECDSA might produce entirely different results here. The computation effort is largely dominated by the cost of the signature. That is assuming that they used x25519 for key exchange, which is pretty close to zero cost in comparison to RSA. From nobody Tue Aug 22 16:12:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BD1132AA8 for ; Tue, 22 Aug 2017 16:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9T_M2Ia2JjGX for ; Tue, 22 Aug 2017 16:12:23 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A7E132AA5 for ; Tue, 22 Aug 2017 16:12:23 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h127so916025ywf.0 for ; Tue, 22 Aug 2017 16:12:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t6DY1yVM1o2XEDbjeV/oooeUBsNOeERMCi/j4nDOfJM=; b=ImcP1Sn9qWNcX6fPE9WNuNOb1HKmBQesIiPTN4uxY8VcQcYYBN8e3/dqLI7hicALdZ c/asYR97eQduoSRs4fYUz5ZMILJpZLJunQDeqTBhWfVFrKvUQU/ZRi2KWy2JhMkdc6SS PWflUV9gIJraDgMfnrs4YIWedMv4oGOrq91pgcGrHg6sT3g/HhnLLK0uBM9WP+TXtCKM jHZCZ2GGj2JRhQumcaatlO74C4QxF4c8k8Ir2ubCjmoY2ps++Q4/WAGeaGPHpfOswV9A xiAtg36ib1WBploDLsvAE5zOkv2aaCRnY8mFRMfDcXBZIDeLhg6CMsRudLVn3okRp5of E+Cg== 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=t6DY1yVM1o2XEDbjeV/oooeUBsNOeERMCi/j4nDOfJM=; b=IU0BvxrupYhy+/rJxKOFnEA78FJlwOJe6TvDLsogPe/zcGTQVWs8rIxGME/cqxRnmi mSMg082SRIVA1kZHcB2aq770f05lDYj4mJTstFlxhd4MqnEv1n2/EJdwgCBjYWBscQFk gtssS11XZ3/HHA2wzV+n9/EQmSU3IExYOZm8gfLADG1X6nW1s62NTq2q6946vhQbNPPg Bt/hmbW4cvRKCDK1N1vhq99HGGOg8b1nCXVFMdkgHjSea7epZYKkkYgwd4u+oMGtiRHX jUof/9tySHu4xKI8Vu+c3LmV3ok50q0j143BbIbdNMgX/+QHnEsU9VrKKpIrke5BIUGT 9VIA== X-Gm-Message-State: AHYfb5hnzNf98HEe8KkyYxE+KGjezepYh3OfoulbvqqYhq4xQXf0CcbV sqHux4Pme0MgLGchNra+xeahO0xkmC5L1zc= X-Received: by 10.37.56.12 with SMTP id f12mr629559yba.289.1503443543041; Tue, 22 Aug 2017 16:12:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.218.130 with HTTP; Tue, 22 Aug 2017 16:11:42 -0700 (PDT) In-Reply-To: References: <8BDD717E-76DE-4C58-A242-C24DFFADEA8E@netapp.com> From: Eric Rescorla Date: Tue, 22 Aug 2017 16:11:42 -0700 Message-ID: Subject: Re: Towards a Scalable Modular QUIC Server To: Martin Thomson Cc: "Eggert, Lars" , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c03e4c252bff605575fba47" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Aug 2017 23:12:25 -0000 --94eb2c03e4c252bff605575fba47 Content-Type: text/plain; charset="UTF-8" I'm not sure what to make of this paper: "A single thread in cQUIC based on DPDK achieves 600 and 1000 connections/s for 2-RTT and 0-RTT, respectively. ... Interestingly, the performance gap between the 2-RTT and 0-RTT handshakes is around 75%, but cQUIC scarcely overcomes the threshold of 1000 connections/s for the 0-RTT. " 1. 1000/600 = 1.667, which isn't really 75% (this is a nit). 2. As MT says, you would expect a far larger gap between any handshake involving RSA and one which does not, so that's surprising. As MT says, ECDSA should make this is a lot faster. Without knowing more about their methodology, and about their profiles, etc., I don't think we can draw that many conclusions from this beyond what we already know from the standard microbenchmarks. -Ekr On Mon, Aug 21, 2017 at 5:21 PM, Martin Thomson wrote: > On 22 August 2017 at 10:13, Eggert, Lars wrote: > > On 2017-8-21, at 17:06, Martin Thomson wrote: > >> Clearly the authors didn't understand why RSA was chosen by Google. > > > > I asked whether they had thoughts on whether their results might be > influenced by QUIC-Crypto and if IETF-QUIC might perform differently... > > ECDSA might produce entirely different results here. The computation > effort is largely dominated by the cost of the signature. That is > assuming that they used x25519 for key exchange, which is pretty close > to zero cost in comparison to RSA. > > --94eb2c03e4c252bff605575fba47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure what to make of this paper:

"A single thread in cQUIC based on DPDK achieves= 600 and 1000
connections/s for 2-RTT and 0-RTT, respectively.

...

Interestingly, the perf= ormance gap between the 2-RTT and 0-RTT
handshakes is around 75%,= but cQUIC scarcely overcomes the threshold
of 1000 connections/s= for the 0-RTT. "



1. 1000/600 =3D 1.667, which isn't really 75% (this is a nit).
=
2. As MT says, you would expect a far larger gap between any handshake=
involving RSA and one which does not, so that's surprising. = As MT says,
ECDSA should make this is a lot faster.

Without knowing more about their methodology, an= d about their profiles,
etc., I don't think we can draw that = many conclusions from this beyond
what we already know from= the standard microbenchmarks.

-Ekr

=

On Mon, Aug= 21, 2017 at 5:21 PM, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:
On 22 August 2017= at 10:13, Eggert, Lars <lars@netapp.com> wrote:
> On 2017-8-21, at 17:06, Martin Thomson <martin.thomson@gmail.com> wrote:<= br> >> Clearly the authors didn't understand why RSA was chosen by Go= ogle.
>
> I asked whether they had thoughts on whether their results might be in= fluenced by QUIC-Crypto and if IETF-QUIC might perform differently...

ECDSA might produce entirely different results here.=C2=A0 The compu= tation
effort is largely dominated by the cost of the signature.=C2=A0 That is
assuming that they used x25519 for key exchange, which is pretty close
to zero cost in comparison to RSA.


--94eb2c03e4c252bff605575fba47-- From nobody Tue Aug 22 16:52:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48915132B93 for ; Tue, 22 Aug 2017 16:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 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_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TL9qghlHI4t7 for ; Tue, 22 Aug 2017 16:51:56 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0101.outbound.protection.outlook.com [104.47.41.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 F39C1132B9E for ; Tue, 22 Aug 2017 16:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VxnFCjw25DTyDXzigiynEr1m0H0U0gueA8WrDsFa9NQ=; b=ON1DFMap3id+2n3bh2AobDwW1k+GPA5XBgM+Qfj23f3RUSrxwJlIkq0AHHTXeOi7jqRrRXgo1SXqxBjDMamf3eeeXXc4fq0oGUInQZzE9KIK7pMpG0RurqGXQ26zOhz3hZfU+C0LA9bwdKYjaiqMOoE8o6RIP8EYx9arafgEjDM= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.0; Tue, 22 Aug 2017 23:51:50 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0013.000; Tue, 22 Aug 2017 23:51:50 +0000 From: Mike Bishop To: GENG Liang CC: quic Subject: RE: Interests of Using QUIC for 3GPP 5G Core Control Plane Thread-Topic: Interests of Using QUIC for 3GPP 5G Core Control Plane Thread-Index: AQHS+qXfG9GSk92hqE2tSD/y2hc5gKKRSk2Q Date: Tue, 22 Aug 2017 23:51:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:7::664] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0144; 6:Si92z3ClSbcsOkOYb551X9eTPrSSzIZ3rRE0653ftqm+f/eS5pGMuG5iCrCS2HrltTNaXZ84H/MWsF+ltSF9UPgwcCsLdLOD8k7PIiiYjTSC+0nv97lR2w0Sf9osNHUtzvKMGVxV2kVaPsm/o7YOCgdoc6CRSeOjhz9lFHx3AXUBe0xOiQaYawfxIrVSG7mW+EO5AfIBL4TeFPDmx4VkOyVOJ2rRMJ/dhNF/vQS3MtXRVlSa2z/hFciI0GyYqsaiirO1tGfX2dCKQZ6TwW7nzNMse/riqM2r5gcfgJXtkR2JNhzBf9XSvKaQeMH1n/3GPGfWItXQemu2tDhznNUF/w==; 5:v//plWE2ZeWFumDXQHV6IxnHe4a62ZguZ6+61M+R49ttG0doFVd5L4C4bjTjqoDxygYN6Mg4TRyPmH7ObFh8pRixJFKX+tPJixxIzVFFkVpi7z5GYyMm7epnw2fogz3DLsH9okqaYPsncEYyP1TIOw==; 24:cBG4KMJXrD+upXSMsu4yM7Xp30oO4y4d1shvgPV7dtnRcbXhCqc5Ok2uDvi9PTNHUqpKdq7N73UoWYOhiL3UI8x/1P5PwdKHKEk5ZVWUmHA=; 7:GBoIPjxfXHSM30MsfHrAO8pGuriVDM5m8g0Y2FrPrgDmfCsM19viTI5FmdTsun0j0VEKB6rOE+wu/qaOCdz6bQU47EsEjirVordpr0zcwGtIHmdG8gw95QNGONRfFX283ObykJNhBpSF4RYzb+Ai7tI1kcP1OKKow0xWFQfHS1f8b/ntV66h6kEw0J02l3yv1Ag/eDO1QBmLIQsm93tD8Sy7q2aNZ11NFFPRzyRCTnY= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0722b322-67b7-4bef-1651-08d4e9b8c1fc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603175)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR21MB0144; x-ms-traffictypediagnostic: MWHPR21MB0144: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123558100)(20161123560025)(201703131423075)(201703031522075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0144; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0144; x-forefront-prvs: 04073E895A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(47760400005)(189002)(501624003)(377454003)(199003)(53936002)(86362001)(86612001)(10290500003)(478600001)(99286003)(55016002)(9686003)(6306002)(3660700001)(3280700002)(50986999)(54356999)(76176999)(561944003)(2900100001)(6246003)(110136004)(39060400002)(101416001)(106356001)(2906002)(54896002)(105586002)(33656002)(6436002)(4326008)(6916009)(229853002)(25786009)(2950100002)(77096006)(6506006)(6116002)(74316002)(10090500001)(97736004)(7736002)(102836003)(7696004)(790700001)(72206003)(5660300001)(53546010)(8990500004)(5005710100001)(68736007)(81156014)(14454004)(8676002)(189998001)(8936002)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0144; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01412B8BF6A36DC140AA7EF187840MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 23:51:50.2454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0144 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 22 Aug 2017 23:51:59 -0000 --_000_MWHPR21MB01412B8BF6A36DC140AA7EF187840MWHPR21MB0141namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Liang - I wanted to make sure we got back to you on this, since this didn't make it= onto the IETF 99 agenda and I didn't see any subsequent list discussion. The answer to the question you ask in your slides is definitely "no": the = QUIC transport will not be sent to the IESG by Q4 of 2017. The QUIC WG was= chartered in October 2016 and our chartered milestones say that we hope to= finish the transport, TLS, and congestion control docs by March of 2018. = That already seems somewhat improbable to me. (Chairs and fellow editors, = speak up if you disagree.) This is a really interesting proposal and I'd love to see it move forward. = You say that it would need to be "a stable WG document," which seems sligh= tly contradictory - a WG document is inherently still changing. If what yo= u need is the fact that those features are present and not going to be remo= ved, we're already there. If what you need is that the wire format is lock= ed, I don't think that's likely. But if 5G slips, or just has feature requirements to relay to us so that it= could leverage QUIC in future work, I'm interested in seeing what those re= quirements would be. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of GENG Liang Sent: Tuesday, July 11, 2017 5:29 PM To: quic Subject: Interests of Using QUIC for 3GPP 5G Core Control Plane Dear all, We are proposing and promoting the use of QUIC for 3GPP SBA control plane. = This results from various advantages of QUIC protocol, which align with the= 3GPP requirements: -Performance advantages including 0-RTT and Multiplexing -Reliability advantages including ACK mechanism over UDP and etc. We put together a set of sides to introduce the timeline of 3GPP work and w= hat we think are important to be considered if QUIC could be potentially ad= opted. Although I fully understand that the WG session may be packed in IETF99, we= would really appreciate if a 5-10 mins could be allocated to us to present= this interest to all QUIC colleagues. Any comments will be extremely welcome. Best wishes Liang ________________________________ Liang GENG China Mobile Research Institute --_000_MWHPR21MB01412B8BF6A36DC140AA7EF187840MWHPR21MB0141namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Liang –

 

I wanted to make sure we got back to you on this, si= nce this didn’t make it onto the IETF 99 agenda and I didn’t se= e any subsequent list discussion.

 

The answer to the question you ask in your slides is= definitely “no”:  the QUIC transport will not be sent to = the IESG by Q4 of 2017.  The QUIC WG was chartered in October 2016 and= our chartered milestones say that we hope to finish the transport, TLS, and congestion control docs by March of 2018.  That a= lready seems somewhat improbable to me.  (Chairs and fellow editors, s= peak up if you disagree.)

 

This is a really interesting proposal and I’d = love to see it move forward.  You say that it would need to be “= a stable WG document,” which seems slightly contradictory – a W= G document is inherently still changing.  If what you need is the fact that those features are present and not going to be removed, we’= ;re already there.  If what you need is that the wire format is locked= , I don’t think that’s likely.

 

But if 5G slips, or just has feature requirements to= relay to us so that it could leverage QUIC in future work, I’m inter= ested in seeing what those requirements would be.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of GENG Liang
Sent: Tuesday, July 11, 2017 5:29 PM
To: quic <quic@ietf.org>
Subject: Interests of Using QUIC for 3GPP 5G Core Control Plane=

 

Dear all,

 

We are proposing and promoting the use o= f QUIC for 3GPP SBA control plane. This results from various advantages of = QUIC protocol, which align with the 3GPP requirements:

 

-Performance advantages including 0-RTT = and Multiplexing

-Reliability advantages including ACK me= chanism over UDP and etc.

 

We put together a set of sides to introd= uce the timeline of 3GPP work and what we think are important to be conside= red if QUIC could be potentially adopted.

 

Although I fully understand that the WG = session may be packed in IETF99, we would really appreciate if a 5-10 mins = could be allocated to us to present this interest to all QUIC colleagues.

 

Any comments will be extremely welcome.<= o:p>

 

Best wishes

Liang 

 

Liang GENG

China Mobile Research Institute

--_000_MWHPR21MB01412B8BF6A36DC140AA7EF187840MWHPR21MB0141namp_-- From nobody Tue Aug 22 17:13:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D44132B8C for ; Tue, 22 Aug 2017 17:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32vxKQsvId1H for ; Tue, 22 Aug 2017 17:13:33 -0700 (PDT) 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 1090D132AD6 for ; Tue, 22 Aug 2017 17:13:33 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id p141so2300557iop.3 for ; Tue, 22 Aug 2017 17:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2FdxV4+mIyx31tXk2yLqAUL7xd68uC3d4+L9gbMkxLc=; b=cE9XHXAjDBpn+tWPro7wQIuCFDVr/baD3ZkNT9aPLW/UlbyWbu36Pi+dWL6K37Jxz+ wCnaUWq4Qor+9kFgHwMO1a3hez7/LUfJTMqhVfRHawar25Sbu6heY7DX8Q0Nw9rzM2Ry i2QO9jQvImJmdxAsnW5UtSeCz402a6rwUbgw4/vpWT2YfCpZNBhHNxeTtShe86piVOT+ rmFnJ+W0OXaSgK0jEU5YtjQ4vOO0q9rAvBSmBFuuC8Wlaq5dmBj9Y2O3wXBP5HS5aUhV 2/hPSy1a4DdvHhCqTyEQMkHPc4y53s20fRJg/9+OWSHwmUReyLbiwKZlxPFCS/rb4VG9 tNZg== 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=2FdxV4+mIyx31tXk2yLqAUL7xd68uC3d4+L9gbMkxLc=; b=dZR8tUm+uZGLBFaJj3+/cBo3ppyOfmowQz//7AEVTdzopFUBQrCoyc9VD/ZZzyXbFH CwnmQqUdcBVqIj0+aAqrsjUb5IKtayTdf4c/I7yqdzU+bDE1r/NJ8jVnNTxj9iu5zOML dsvCEUjMJLmLJCarBT+hsV0jiEgoGtBlw/sjP8GxVOunNxbLzJwy+K2ZoP4z4TW+ZcKF eCqWzOtuk1yPHNR2GGAL9PX5nk7XLwsinrfiJmLowo0AJ2V6NvuUzrNv2ErDW1Frf1ff MOrRPp2gEviCrV8ytMYmDBqqERSw2er26ysmy/afs2ooNMV6y6tX5knwknI7FyDG24ZP qqEg== X-Gm-Message-State: AHYfb5jgnDwP1Q4p7MfrbH9IYf/T0j4fb949xyNT2RqQU7VqVjbCDdDU sv86yYcGCaD5UUgqc9VsgzR0zCaV9Q== X-Received: by 10.107.180.72 with SMTP id d69mr529348iof.291.1503447212340; Tue, 22 Aug 2017 17:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Tue, 22 Aug 2017 17:13:31 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 23 Aug 2017 10:13:31 +1000 Message-ID: Subject: Re: Interests of Using QUIC for 3GPP 5G Core Control Plane To: Mike Bishop Cc: GENG Liang , quic 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, 23 Aug 2017 00:13:35 -0000 I agree with Mike, it seems like your timelines are too tight for a requirement on *QUIC*. But that's probably the wrong way to look at this. The question you should instead ask is whether HTTP can meet your requirements. Based on the slides, it would appear that HTTP with HTTP/2 and TLS 1.3 would meet those requirements. That leaves the option to use QUIC open when QUIC is ready. We have what we believe is an adequate story for seamlessly introducing QUIC into a system that uses HTTP. Creating dependencies on HTTP generically and maybe HTTP/2 and TLS 1.3 would be a reasonable plan in my view. On 23 August 2017 at 09:51, Mike Bishop wrot= e: > Hi, Liang =E2=80=93 > > > > I wanted to make sure we got back to you on this, since this didn=E2=80= =99t make it > onto the IETF 99 agenda and I didn=E2=80=99t see any subsequent list disc= ussion. > > > > The answer to the question you ask in your slides is definitely =E2=80=9C= no=E2=80=9D: the > QUIC transport will not be sent to the IESG by Q4 of 2017. The QUIC WG w= as > chartered in October 2016 and our chartered milestones say that we hope t= o > finish the transport, TLS, and congestion control docs by March of 2018. > That already seems somewhat improbable to me. (Chairs and fellow editors= , > speak up if you disagree.) > > > > This is a really interesting proposal and I=E2=80=99d love to see it move= forward. > You say that it would need to be =E2=80=9Ca stable WG document,=E2=80=9D = which seems > slightly contradictory =E2=80=93 a WG document is inherently still changi= ng. If > what you need is the fact that those features are present and not going t= o > be removed, we=E2=80=99re already there. If what you need is that the wi= re format > is locked, I don=E2=80=99t think that=E2=80=99s likely. > > > > But if 5G slips, or just has feature requirements to relay to us so that = it > could leverage QUIC in future work, I=E2=80=99m interested in seeing what= those > requirements would be. > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of GENG Liang > Sent: Tuesday, July 11, 2017 5:29 PM > To: quic > Subject: Interests of Using QUIC for 3GPP 5G Core Control Plane > > > > Dear all, > > > > We are proposing and promoting the use of QUIC for 3GPP SBA control plane= . > This results from various advantages of QUIC protocol, which align with t= he > 3GPP requirements: > > > > -Performance advantages including 0-RTT and Multiplexing > > -Reliability advantages including ACK mechanism over UDP and etc. > > > > We put together a set of sides to introduce the timeline of 3GPP work and > what we think are important to be considered if QUIC could be potentially > adopted. > > > > Although I fully understand that the WG session may be packed in IETF99, = we > would really appreciate if a 5-10 mins could be allocated to us to presen= t > this interest to all QUIC colleagues. > > > > Any comments will be extremely welcome. > > > > Best wishes > > Liang > > > > ________________________________ > > Liang GENG > > China Mobile Research Institute From nobody Wed Aug 23 13:51:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0522D132710 for ; Wed, 23 Aug 2017 13:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjfsUmX1L_VZ for ; Wed, 23 Aug 2017 13:51:12 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CF08132716 for ; Wed, 23 Aug 2017 13:51:12 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id p67so1999070qkd.1 for ; Wed, 23 Aug 2017 13:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=qJKDHbTKkrlMnGSY9PV/HfbDo9kwbP6Pc1gWPCOHcbo=; b=xJqsuA3eg4HIqr+VKsb+nhQlYasfJLabHaB8UaeEsGwTlI/oxGKzCIO/QQpT51w3aF 32Sy3r9gRZq6vngPNyjsoXV3JoKQLWLj4Ty56DdeSV6AYiXwSS8yeYmHyYn2E8jp4JRb N5LUX1RA3ZperhSxwdi3N58yQ8brQ/FJEMBKtDXtYtCG2EkkVTHZbXlh66bZrqbwdTNM 4SOi5diemFNFifCWvGfv//82dd40CmQJAJJZ3yn6372N+VN9gvleqx6VKLN12eshsOcY m2pypDHc6t5KRlV1vQNFGstfPG+XfBxxnwcYhlB4PdF661+I/FGp34QMg/5YWF5FDp8F LYWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=qJKDHbTKkrlMnGSY9PV/HfbDo9kwbP6Pc1gWPCOHcbo=; b=HI59UmOtA/v8ypIbXGYSmCfTkYlnHe4fgJ+NNHsO6qBL+/1ibv0EdnIV2nYEgK+n7c 8kDkgPA9Rc9P5NanMuRuQhtgHdRdE0n3gN7VYdxf1Hlda3eXwI0adU9v8Ljm518Z0CjW y/JsBk9t9I+B4VeiNmiWjjNLZmO9P3YOlGZLDZBkCl91Kq+uLpZqRsHt0fHyLNyGfboW GqFHsXTaUhQ1Tx/mQvxvwE1t6QBG9UPlhetBlMu64LUxwqUSdhjwCgl0UiAjn6tqPZxn WyrKkOH0WM/H7kftSy+QqKQ3zMFCwf7pUgTmOneTMBExgVX/+X0cjBOzq7bL4IIhpBHz Qkbw== X-Gm-Message-State: AHYfb5hKy7L8Qc27/Gq+dif2QYNqyvlH64IrmST/LZmS6+sj5RnCvzNh NmcREs2b1UbSVPBZrho= X-Received: by 10.55.167.86 with SMTP id q83mr5175599qke.221.1503521471205; Wed, 23 Aug 2017 13:51:11 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id 12sm1690440qkz.24.2017.08.23.13.51.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 13:51:10 -0700 (PDT) Date: Wed, 23 Aug 2017 16:50:58 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Why is MAX_DATA in units of 1024 octets? Message-ID: <20170823205057.GA8231@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Aug 2017 20:51:14 -0000 Hello, I would like to know why maximum data is defined as it is, "in units of 1024 octets:" " The fields in the MAX_DATA frame are as follows: " " Maximum Data: A 64-bit unsigned integer indicating the maximum " amount of data that can be sent on the entire connection, in units " of 1024 octets. That is, the updated connection-level data limit " is determined by multiplying the encoded value by 1024. (I did not see a discussion regarding this on GitHub or on the mailing list. If I missed a resource, please let me know.) This requirement means having to write extra code to handle what is effectively a 74-bit integer for something that is not likely to occur, as 2^64 bytes is a lot of data. I am tempted to say that a smart implementation would close the connection when Maximum Data starts to approach 2^54 and not bother. - Dmitri. From nobody Wed Aug 23 13:56:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249721329DB for ; Wed, 23 Aug 2017 13:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_YuISaoYqgO for ; Wed, 23 Aug 2017 13:56:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 039A0126BFD for ; Wed, 23 Aug 2017 13:56:12 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id s187so7889761ywf.2 for ; Wed, 23 Aug 2017 13:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ia6OVdSrmuJkQMudbCl+urNYMBfmfo2NHL3htwCOqr0=; b=hwQTONUS9s4rtTB7qkXDGrfJBVVYR/IS85EAtP6Mn1hyt5H8bxatFk/Evtxxawv6ed Nl4gQZ199syWCKgfP8/NBLlkn5hx6fih0MCjrt6QBGRLKJCA6kbUbW8SEOM2Qa7WLBUA 6qZedGJ6LdqOVhBTRvGTShHyZwIs2gINpOACTtUgek4BqcJCNX7loBbSOKWqArRfX99N eRwmXWqY/aI9kWeXwbp9/0C8EoWHPGlgowibtIqo929kTyWNsZ92SxCwGFL6GJf3ikgE K9deGEWJAWRsnH283FaN7V9AmOtSlzhf601i20NgwSfBCtM6FZ4qQt+sJdImB+iuAG5o +emg== 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=ia6OVdSrmuJkQMudbCl+urNYMBfmfo2NHL3htwCOqr0=; b=GWjz8butjGd2UHYXwl5zPmSNIbTpjjddST+NocopkBoWdZZU33djGmNqD2ltnxpiPe JHgT0Zb0Da2xDXD+/MDP2UM4tGFeYaPcQLy8BqNOpggJ2cNbf3NMZBN7cex/JpHmlXVw At3yFM+PQ0mK4NqjBa4bNtezLs+eDT15b1Lrp/VkW+X54sO6RlQJySnwkJaXGL7KyGGj nBvWIGAJhcu/86W/uPvY7/cWP/4MhFFCN4yTDpxf/L5nzg1Vxltd8P/gYgQdOF6QKJcZ +pD4gtdHZ4+npuXnEX6rWumDhyeKDhQLBB00+PC8udSHZlhpGTbfdm+WczJYDH1SWYtJ 8oWw== X-Gm-Message-State: AHYfb5gXC1LZYZnt2+y0GCPgmmDq32HpdURYLG7oAC1pUKNXEjEefZqH 3OrTidtRdabcq0/u9TsMAuOLdnlHOX9I X-Google-Smtp-Source: ADKCNb5okBxVbCNVrDJ/3FQCXe4BzRNmASSHt9hmot4hpfw6d53VB3SJwIhF0BWrWDaaAsSQF9XDfpUVe76HaF565II= X-Received: by 10.37.188.13 with SMTP id i13mr3413677ybh.103.1503521767129; Wed, 23 Aug 2017 13:56:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.132 with HTTP; Wed, 23 Aug 2017 13:55:46 -0700 (PDT) In-Reply-To: <20170823205057.GA8231@ubuntu-dmitri> References: <20170823205057.GA8231@ubuntu-dmitri> From: Ian Swett Date: Wed, 23 Aug 2017 16:55:46 -0400 Message-ID: Subject: Re: Why is MAX_DATA in units of 1024 octets? To: Dmitri Tikhonov Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08240254d7d308055771f097" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 23 Aug 2017 20:56:14 -0000 --089e08240254d7d308055771f097 Content-Type: text/plain; charset="UTF-8" I believe the thinking was that if we allow 2^32 streams and 2^64 packets that the max connection level flow control value becomes the limiting factor of connection lifetime. However, you make a good point that integers longer than 64 bits are very non-standard and this could be a source of bugs. I will note that there is no requirement a sender or receiver ever send or allow receipt of more than 2^64 bytes. But if the peer advertised a connection level flow control value that large, they'd have to handle it correctly. On Wed, Aug 23, 2017 at 4:50 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > Hello, > > I would like to know why maximum data is defined as it is, "in units > of 1024 octets:" > > " The fields in the MAX_DATA frame are as follows: > " > " Maximum Data: A 64-bit unsigned integer indicating the maximum > " amount of data that can be sent on the entire connection, in units > " of 1024 octets. That is, the updated connection-level data limit > " is determined by multiplying the encoded value by 1024. > > (I did not see a discussion regarding this on GitHub or on the mailing > list. If I missed a resource, please let me know.) > > This requirement means having to write extra code to handle what is > effectively a 74-bit integer for something that is not likely to > occur, as 2^64 bytes is a lot of data. I am tempted to say that a > smart implementation would close the connection when Maximum Data > starts to approach 2^54 and not bother. > > - Dmitri. > > --089e08240254d7d308055771f097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the thinking was that if we allow 2^32 streams a= nd 2^64 packets that the max connection level flow control value becomes th= e limiting factor of connection lifetime.

However, you m= ake a good point that integers longer than 64 bits are very non-standard an= d this could be a source of bugs.=C2=A0 I will note that there is no requir= ement a sender or receiver ever send or allow receipt of more than 2^64 byt= es.=C2=A0 But if the peer advertised a connection level flow control value = that large, they'd have to handle it correctly.

On Wed, Aug 23, 2017 at 4:5= 0 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
Hello,

I would like to know why maximum data is defined as it is, "in units of 1024 octets:"

=C2=A0" The fields in the MAX_DATA frame are as follows:
=C2=A0"
=C2=A0" Maximum Data:=C2=A0 A 64-bit unsigned integer indicating the m= aximum
=C2=A0"=C2=A0 =C2=A0 amount of data that can be sent on the entire con= nection, in units
=C2=A0"=C2=A0 =C2=A0 of 1024 octets.=C2=A0 That is, the updated connec= tion-level data limit
=C2=A0"=C2=A0 =C2=A0 is determined by multiplying the encoded value by= 1024.

(I did not see a discussion regarding this on GitHub or on the mailing
list.=C2=A0 If I missed a resource, please let me know.)

This requirement means having to write extra code to handle what is
effectively a 74-bit integer for something that is not likely to
occur, as 2^64 bytes is a lot of data.=C2=A0 I am tempted to say that a
smart implementation would close the connection when Maximum Data
starts to approach 2^54 and not bother.

=C2=A0 - Dmitri.


--089e08240254d7d308055771f097-- From nobody Wed Aug 23 14:19:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838A3132714 for ; Wed, 23 Aug 2017 14:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCvTBUiXdRn1 for ; Wed, 23 Aug 2017 14:19:28 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDB61329E4 for ; Wed, 23 Aug 2017 14:19:28 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g71so4706400ioe.5 for ; Wed, 23 Aug 2017 14:19:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x8ryuU/eclfhPOI4MIOuoIktDvjPNoxoNmjNOgKTlWY=; b=DMQpurh+KrAifVrsw8FllG6UFz+wrQMJYj1N0DCNYJi5jnFzDILgklX0zKwI9CJ5Ou UiS7lv6Vm4Fcc2Q3SwfxpAIo6K3VzJoeqdAHoQxlVGTL7sGJjqY0x7F4ybTt5EuS0YtZ fDjsZ9QEWpRE2S+gE/OzrLzfK6gh7hh1wLDEBOmAjJC1hA8nSL56rPaJtoNQAqkuvB69 9Ys3QdcakpjjCLb+AegutXBNF5He9qoy/JkD8/rEcsPxt7s4mzIwqc2TUf3+X5PgAauc ggyiVh/QS3ZWSczoX68YxwIdJBkPTdMReDjXwIqLfo8uT+tgIqy72towyZmDilS6zeeV u3AA== 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=x8ryuU/eclfhPOI4MIOuoIktDvjPNoxoNmjNOgKTlWY=; b=EoJyFpVvgwohVu00mOt4BSdbOrfQ5xrZ3Oc0uVzVTHaKzkGTBLYSAdb8L6bIU2EOk2 o6c9jikIxE5mOP/z365z0AwVpXkKpcFzIz6wclSQfGo8PrMaeZhYP0VJOAl6b8wIKiUW /SspcSp4zvtfciA0TwuA3QJCYsBuRuk5kX+iU7CwRnFRz8evy5fjq1wKcfXr/duWIeIq vJHT4dV9oStNbRDVWbjiaNeSJ4xV/15uqTeNH0qzSdoBT18D3qZLM9VS65pfYjC4yklK aM1T9MfzoGxWf07QrPvtOYLl3ilLV5DB/JJ9bez9+xhny2cyud8YeGvtXhz+H1s36x9r Unwg== X-Gm-Message-State: AHYfb5i9VvRKqFA24sEqbLmeTO/zwLhVQb/xGgof4LyBuFzRB39Gq5c9 TVzcrKyvfhJ0B5xJ472gfp2LVEwvyw== X-Received: by 10.107.179.69 with SMTP id c66mr563201iof.174.1503523167490; Wed, 23 Aug 2017 14:19:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Wed, 23 Aug 2017 14:19:26 -0700 (PDT) In-Reply-To: References: <20170823205057.GA8231@ubuntu-dmitri> From: Martin Thomson Date: Thu, 24 Aug 2017 07:19:26 +1000 Message-ID: Subject: Re: Why is MAX_DATA in units of 1024 octets? To: Ian Swett Cc: Dmitri Tikhonov , 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, 23 Aug 2017 21:19:31 -0000 Ian has it right, if 2^74 is hard for you, stop before you get there. You don't have to advertise a window that large, and you don't have to send that much data. On 24 August 2017 at 06:55, Ian Swett wrote: > I believe the thinking was that if we allow 2^32 streams and 2^64 packets > that the max connection level flow control value becomes the limiting factor > of connection lifetime. > > However, you make a good point that integers longer than 64 bits are very > non-standard and this could be a source of bugs. I will note that there is > no requirement a sender or receiver ever send or allow receipt of more than > 2^64 bytes. But if the peer advertised a connection level flow control > value that large, they'd have to handle it correctly. > > On Wed, Aug 23, 2017 at 4:50 PM, Dmitri Tikhonov > wrote: >> >> Hello, >> >> I would like to know why maximum data is defined as it is, "in units >> of 1024 octets:" >> >> " The fields in the MAX_DATA frame are as follows: >> " >> " Maximum Data: A 64-bit unsigned integer indicating the maximum >> " amount of data that can be sent on the entire connection, in units >> " of 1024 octets. That is, the updated connection-level data limit >> " is determined by multiplying the encoded value by 1024. >> >> (I did not see a discussion regarding this on GitHub or on the mailing >> list. If I missed a resource, please let me know.) >> >> This requirement means having to write extra code to handle what is >> effectively a 74-bit integer for something that is not likely to >> occur, as 2^64 bytes is a lot of data. I am tempted to say that a >> smart implementation would close the connection when Maximum Data >> starts to approach 2^54 and not bother. >> >> - Dmitri. >> > From nobody Wed Aug 23 22:52:19 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327D513214D for ; Wed, 23 Aug 2017 22:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, 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=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 YpZl6wtsTNy4 for ; Wed, 23 Aug 2017 22:52:15 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AD7132359 for ; Wed, 23 Aug 2017 22:52:13 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id k22so569787iod.3 for ; Wed, 23 Aug 2017 22:52:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Q5ARY7NINaST58O1r06CYmFGunCxB7Z0I+rtT35NLLw=; b=bAQ7en/ewctWpN4QiuCcGX7aKDx0xuDaedpExb8TtaeH8JHe16sWvWEaG11jTFQWCp 22LxKHoao7LTbzVp72P9tQqlvmAlYhBLvAaIBvPIqM1SZUGnCt7bwtGN+8puSul0kpoB CRIvK7q7PBjkYWqwCHsSS6LN7r7Ckv/BmQ7H340EuD9Xss7GubguVoAQJi0H6SGKq5rv dlYebyjOroLIcZJbluCHbXTup1HGBMv0lLa0CRRqGnj7teaTkaAu594Ra452CDxDgC6R HV06Rx4s8bMQVnzteUbcbMHOScO1faiL7xXcjX54bqFLVaZYRWxYNuDv5CybODUeAkjn rqTA== 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=Q5ARY7NINaST58O1r06CYmFGunCxB7Z0I+rtT35NLLw=; b=OJ7NS2Ufw+Dfbe+uxQ5vNy+5Cfne9v5HbYkrVtN5Rofr6ab7SabScZbjTOJ8bzc2rg tllLwb45DRLU+EsIYLe/jwIylNtIrMxZO9oylVp/q1mUK4Y/WnZNWrjSbPMaGm3IvlVp wUevQm1wvpefEbYvAia6Wvh6h1Cq0bgJrCEeZ2CWBV0VLUV+PB4rlwVUrXNqLUwaFE8X ITupX26CFiRjTnf94CZRLXEHI4nLZD4ll0/RHmVnHg9nsHlZ8pByHBXc7HMnN7xsA+EF VgOh4SPNF3S36k+NGTTkAa2GbaXPI0G/yG//U6xruxAFnhL0ACUJCHEhqdqC6cTwFIPs GX8A== X-Gm-Message-State: AHYfb5ibXeL8wvTVO/qRFQgYlOGB7qrZ3ouTPyyhNmoa/UBSe7kIua28 sv/g8KtGvM8D7Lufx4RkAgkIFIQOwyunj3Y= X-Received: by 10.107.27.10 with SMTP id b10mr4400328iob.241.1503553932791; Wed, 23 Aug 2017 22:52:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Wed, 23 Aug 2017 22:52:12 -0700 (PDT) From: Martin Thomson Date: Thu, 24 Aug 2017 15:52:12 +1000 Message-ID: Subject: Congestion control algorithm questions 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, 24 Aug 2017 05:52:17 -0000 I've barely usable Internet access today, so I've had a lot of time to contemplate congestion control. I read through the congestion and loss recovery document and have a few questions and observations. These are in email form because I'm not an expert on this stuff and it could be my poor understanding. Firstly, the heavy reliance on pseudocode here is to the detriment of clarity. There are numerous examples of this, but here are two I found to be unnecessarily obtuse: 1. I realize that some people have internalized the fact that (end_of_recovery < largest_lost_packet.packet_number) and (acked_packet.packet_number < end_of_recovery) mean that the connection is out of recovery and in recovery respectively, but this is not very clear. I think that clarity would be improved immeasurably by an IsInRecovery() function. Maybe also some text. 2. The same goes for several other tests that are performed throughout, in particular (congestion_window < ssthresh) which would be better as IsInSlowStart() / not IsInCongestionAvoidance() / CwndIncrease() == slow_start / CwndIncrease() == congestion_avoidance. The next is that there are unused and undefined variables. acket_packets/acked_packets is the one that I noticed most acutely this time. When the congestion control is given an ACK to process, I infer that this means the sum of the lengths of newly acknowledged packets in that ACK. However this variable is derived, it needs to be explicitly defined somehow. Reading RFC 5681, its congestion avoidance algorithm is SMSS*SMSS/cwnd, which takes a fair bit of effort to map to acked_packets.bytes / cwnd. If I'm right, the unstated assumption in RFC 5681 is that the sender is transmitting as much as the cwnd permits, it is sending every segment at the maximum size (SMSS) and the receiver is acknowledging every segment it receives. That way the sender sends cwnd/SMSS segments every round trip and receives that many acknowledgements. This seems to be the only way that the stated goal of an increase of 1*SMSS per RTT is achievable. Aside: For those up to speed on TCP, can they explain why ACK splitting isn't considered when in congestion avoidance? So much effort is spent on explaining why it's important during slow start, then the spec seems to forget this. Sure, the effect is not as significant in congestion avoidance, but it's still baffling. The same applies if the sender sends more and smaller segments. Surely that leads to a larger increase in CWND in the same way that splitting ACKs would. It seems like QUIC attempts to address this by accounting for bytes received. The idea appears to be to trade this off against reducing the rate at which the window expands in congestion avoidance on connections that aren't using the full connection capacity. I think that the formula might be incorrect. Currently, it is: congestion_window += acked_packets.bytes / congestion_window I think that it probably wants to be something like: congestion_window += kDefaultMss * acked_packets.bytes / congestion_window (Here I'm assuming that kDefaultMss =~ SMSS, though it seems like the actual constant might need some better justification. Would this integrate MTU discovery if that were performed? Or would this produce the wrong outcome on paths with an unusual-sized MTU?) Otherwise, the formula will produce an increase of one byte for every round trip, or - more precisely - every time an entire congestion window worth of data is acknowledged. That seems a little too cautious. I found the description of when the congestion window is reset to be baffling: > QUIC decreases the congestion window to the minimum value once the retransmission timeout has been confirmed to not be spurious when the first post-RTO acknowledgement is processed. Maybe consider rephrasing that one. From nobody Thu Aug 24 03:58:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51E6132914 for ; Thu, 24 Aug 2017 03:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylwVGJSZ5v0N for ; Thu, 24 Aug 2017 03:58:39 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ED441321C9 for ; Thu, 24 Aug 2017 03:58:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xdLrF22Y5z15N0Z; Thu, 24 Aug 2017 12:58:37 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmjzijeTWq8k; Thu, 24 Aug 2017 12:58:35 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E114BB.dip0.t-ipconnect.de [217.225.20.187]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 24 Aug 2017 12:58:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Congestion control algorithm questions From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 24 Aug 2017 12:58:35 +0200 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 10:58:42 -0000 Hi Martin,=20 > Am 24.08.2017 um 07:52 schrieb Martin Thomson = : >=20 > Aside: For those up to speed on TCP, can they explain why ACK > splitting isn't considered when in congestion avoidance? So much > effort is spent on explaining why it's important during slow start, > then the spec seems to forget this. Sure, the effect is not as > significant in congestion avoidance, but it's still baffling. The > same applies if the sender sends more and smaller segments. Surely > that leads to a larger increase in CWND in the same way that splitting > ACKs would. Actually not 100% sure what you mean by ACK splitting, however, = initially it was assumed that every packets gets acked, then delayed = acks were introduced, which led to a too slower increase rate, which = however isn=E2=80=99t really significant in CA. Nowadays almost all = system implement appropriate byte count (ABC) [rfc3465] which counts = bytes as the quic draft does. However, delaying acks in slow would still = lead to packet burst of 4 (or more) instead of 2 packet (if no pacing is = implemented), which could lead to earlier losses, causing slow start to = end too early. Does that help? From nobody Thu Aug 24 06:16:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 552FC132944 for ; Thu, 24 Aug 2017 06:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpLOYcw2sM7d for ; Thu, 24 Aug 2017 06:16:07 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 BA38313295E for ; Thu, 24 Aug 2017 06:16:07 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id b129so2723462qkf.5 for ; Thu, 24 Aug 2017 06:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+1WD1Bh8pQof5dycbQsOC8B/nFoESAoKJ9YLagXwcYY=; b=1iUt97aadht/Z2yZosvq62xFzlcvqY+oTQnJK00y+ctBaX+7yKncIdw1pRZdDuuacf b58gk1iytPsVzsPKakWpFi5/xukq3HHwqalZXvbKMMlZF0vaxXy/NnTh37LLgKvIilWU vNjREzg1Yf4vp8y69R6HVE5jmaqMAv4hte27AzDZZ2ulEG7DnV3PCy795Fa/izHsCfyV 2WXED+7Riq5iMrc3XlzRM1X+Hlq8ArETcGDBa1hWkoGAYwa0tsX22bFjfRs79UN8vmAu VbOMDF07pFjwoUGQ1BmkVsiKHt8F0VNnta5SNbHlvh1hMR73LjDBUmhCf3vYl0uad4dY Ty8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+1WD1Bh8pQof5dycbQsOC8B/nFoESAoKJ9YLagXwcYY=; b=aWwHglNw3LBtN+7TAyhO9XPdUkL9K1Jy6Im8ZjxK+h4RPAKiazdN3My6AKaXPb2P69 EId9E8eJQJbwRJ/Qo3QAhDoo54y9F7kK1+CKsKPV+63eYxtoZK5B+llKct9UD8PQoEr3 Cywc3Q6QJmEDq/Mk3g26b353Q/v4AQ594TUCGqM4Mb/O0VU2Bf5Lk7FA3LIvPZnAhlW9 PW60Q1pTFuvMLaoxy9SYI6HEXYhxSKoR+xNvfOobINjwDoSzdRiV4rQoMQOIRV0ntP0L whxS2o2jO6b/S4/VzBzArHKhH7zP9ly+n6oyCBx0okd3YUBVIybU+KB7BnfYZJZ60ZuC KHHw== X-Gm-Message-State: AHYfb5hDTHTd4Jv5fz0djAdU3lEJH5vcBKZJiOh8S/Nb8w8anuiZzOxh Ij0ZD5J0U+UOtxOav+o= X-Received: by 10.55.197.145 with SMTP id k17mr8843347qkl.354.1503580566891; Thu, 24 Aug 2017 06:16:06 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id 22sm2512242qto.36.2017.08.24.06.16.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Aug 2017 06:16:06 -0700 (PDT) Date: Thu, 24 Aug 2017 09:15:56 -0400 From: Dmitri Tikhonov To: Ian Swett Cc: IETF QUIC WG Subject: Re: Why is MAX_DATA in units of 1024 octets? Message-ID: <20170824131556.GA11713@ubuntu-dmitri> References: <20170823205057.GA8231@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, 24 Aug 2017 13:16:14 -0000 I would like to point out that the maximum numbers of streams and packets are picked a) to be large enough and b) to match standard integer sizes. The (b) part of the rationale is obvious and is usually not stated; for the purposes of my argument, however, it needs to be noted. Take away (b), and the limits imposed are arbitrary. For example, why 2^32 and not 2^31 or 2^34? Does QUIC protocol need these limits? One could encode an integer of any size and not worry about hitting a limit. Yet QUIC chooses to have limits, and that is because, I believe, it wants to avoid forcing implementations to use specialized math routines to calculate byte offsets. Going back to (a), 2^64 is really large enough for both stream and connection offset limits: sending this many bytes at 10 Gbps will take about 467 years [1]. It will just not happen on a single QUIC connection. If, in fifty years, network transfer speeds are much faster, QUIC v2 (this is why QUIC has versions) can use 128-bit integers which, by that time, are sure to be supported natively by most processors. On Wed, Aug 23, 2017 at 04:55:46PM -0400, Ian Swett wrote: > But if the peer advertised a connection level flow control value > that large, they'd have to handle it correctly. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ That's the thing: every QUIC implementation will have code to handle -- and unit tests to test -- a condition that will never occur. - Dmitri. 1. http://www.wolframalpha.com/input/?i=16+exbibytes+%2F+10+gbps From nobody Thu Aug 24 15:20:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949771321BF for ; Thu, 24 Aug 2017 15:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8z0513Kbzz5 for ; Thu, 24 Aug 2017 15:20:07 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A528213235C for ; Thu, 24 Aug 2017 15:20:07 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id n5so258622itb.1 for ; Thu, 24 Aug 2017 15:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9iELvltUy7kg2d3Vv/h5XzwMn3V9/ESp/vMLJTR2Lmw=; b=q+cl1wCoL9WdXb0PXvhZXLfGleXC8BrMvVGhJMZGKhn304oHDWWxBOOocqCj7BdcMm 4EiYMSLroYjm9JNrzQX1xWfadUF6V54tXsNksEJXW9UrjQqnO+U8N/eJA291v+Tnq2ZL PEosovX4LMEFLGbIdj2vPOrTL+oG4CNmD8HJFrXvkdoxYiZ0T3/VMhBMZkU85FUIuuOp WcE90NVQi9akmSSmGx67tccS0EZje0m7OHZjY2FAQ0YY7NTFHjikXusop39PzqM+ayaF OH4+7bFVXbF2iEc23ESCFKGwxTLzNrR8QwwfkncWvSfEyiFeSQLijw9VtopYeJO0CMXo YMVA== 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=9iELvltUy7kg2d3Vv/h5XzwMn3V9/ESp/vMLJTR2Lmw=; b=unzXaLxAdLvSZGg3NLAXys+4za9VYMibZWc3U6S2ykN5EQK1I+Rr8gUC2ZNIauqxP9 l8lySb7sc6LRqVNIP3D/M0FFHPiz3sV/9Kpym54LxN41Q8zDl49gZMF0tGVMwTVjEWf6 PcLbh7gjWQVl0F8OnBvGNMXH7FJN98XX5n6ez4Hv8TTMR9i0hAcA6kw6OvZjDwf+QE/Z jFsOZMsy8+4pVBgajZCLWOqHuS+7edx2pQURtsL0L4Cm5t4hxY3XwxBFk+zfwwOUeg4T EIi5b42balyoGigmBvnrxTTwzIeTBKuHkGtzE0rshBEyXyaAbNLn+E8B5ezQZTD0ENjo sIeQ== X-Gm-Message-State: AHYfb5htUpiph0duv/CXI0Jko9Gfz2Cn0LjlrkSD9hU7sTdNQ9tJqkL/ XEr0klSsEGBgNJe+0a423i/oiB+pJg== X-Received: by 10.36.133.130 with SMTP id r124mr242799itd.23.1503613206909; Thu, 24 Aug 2017 15:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Thu, 24 Aug 2017 15:20:06 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 25 Aug 2017 08:20:06 +1000 Message-ID: Subject: Re: Congestion control algorithm questions To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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: Thu, 24 Aug 2017 22:20:09 -0000 On 24 August 2017 at 20:58, Mirja K=C3=BChlewind wrote: > Hi Martin, > >> Am 24.08.2017 um 07:52 schrieb Martin Thomson = : >> >> Aside: For those up to speed on TCP, can they explain why ACK >> splitting isn't considered when in congestion avoidance? So much >> effort is spent on explaining why it's important during slow start, >> then the spec seems to forget this. Sure, the effect is not as >> significant in congestion avoidance, but it's still baffling. The >> same applies if the sender sends more and smaller segments. Surely >> that leads to a larger increase in CWND in the same way that splitting >> ACKs would. > > Actually not 100% sure what you mean by ACK splitting, however, initially= it was assumed that every packets gets acked, then delayed acks were intro= duced, which led to a too slower increase rate, which however isn=E2=80=99t= really significant in CA. Nowadays almost all system implement appropriate= byte count (ABC) [rfc3465] which counts bytes as the quic draft does. Howe= ver, delaying acks in slow would still lead to packet burst of 4 (or more) = instead of 2 packet (if no pacing is implemented), which could lead to earl= ier losses, causing slow start to end too early. Does that help? My impression was that byte counting was common, but it still seems like an error in the RFC to not consider the possibility that someone might generate an ACK for every byte they receive. Using the math there and a modest SMSS, I could force a connection into CA and then cause your congestion controller to ratchet up by a megabyte per round trip (assuming that I can get 1000 or so ACKs through, of course[1]). That's more aggressive than slow start. ABC obviously corrects that problem, but it's odd that the RFC seems to forget this point. I get that delayed acks can cause the window to jump up in more discrete steps, leading to bursts of transmission, but that was part of what pacing was intended to address, right? [1] My current link is 6.3/0.18, so the notion of asymmetry is fascinating to me right now. From nobody Thu Aug 24 15:26:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612C613271F for ; Thu, 24 Aug 2017 15:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUHHUBz7wA-M for ; Thu, 24 Aug 2017 15:26:55 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 494A1132803 for ; Thu, 24 Aug 2017 15:26:50 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id k22so2850361iod.2 for ; Thu, 24 Aug 2017 15:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OzyqO8fx1BZViUCRnkf/XKPYzaUgqcGaHjMEmuRnxQ4=; b=KmRsiQrcHMezTZb9XMSahDUFdpUaoFudhVyxJZDgXVie3n8U9F7dJ5FlGjKcCAaVkM G5n/2OuUIWR09crqoJHWwUdu6U/3B59jeng9sQXyCq4Lphs59T0u9ZijJu+kFrfvPy/a Pmt/Ydp4QgrIfHIBPJda7qJGHxd1J1nQ7oH5l2iibsIVpnSRimuPYqUDCJ13wqTeHqfG Vu03Z2mIl0uiwcEidBFKz8EhzMcf5CFVnL3UAd6SHtPpzeRnisbFGcgkBPfMejl1N8EE lx0CEySoHfzx7Fp6gWCT90Y83VBN0ArM+EdgAeQisdoczCVC+fSENkOuvGEjkG0Dwq0t q+mw== 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=OzyqO8fx1BZViUCRnkf/XKPYzaUgqcGaHjMEmuRnxQ4=; b=SsgGmwdcQNZOtLrCCTKUkb6LFYUiv5BFJl1/tIY/rhzyfycqMZm8BH5skwL/VmJvVk Hot2nbPrnsbWVEityuwppdiyoxQ9zn5SjRH/QqP+LrjXChaNTbo+xKH6IAqqV4pptjn0 Tu/NpfTicCP9LnqjdMLKSIZ03GB8BvPTqGslP0vYKswH264bqdMyjF1c2pO0WuumoQhr MK3u52E5b8WH1yp9OOpStyjhiQSmooJxuTr3QUid5wOkY55VGIs2UbbDxhI7ZJGqM0Ly mqD5YWLr7EKGfsOMcgGRTUbNL/CjPLR4pq7b5IpVpDTvSVQUBJI+lLGwSTSzHn3Uqtqp z7HA== X-Gm-Message-State: AHYfb5iHw2ECtrl21K2p9EGsdOP2tnpO4RWs1ZA61R8T24sBg8bN9S5/ XbdWsTG2Qd8BQQP7QM117VUqUR3+3g== X-Received: by 10.107.179.69 with SMTP id c66mr3724474iof.174.1503613609669; Thu, 24 Aug 2017 15:26:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Thu, 24 Aug 2017 15:26:48 -0700 (PDT) In-Reply-To: <20170824131556.GA11713@ubuntu-dmitri> References: <20170823205057.GA8231@ubuntu-dmitri> <20170824131556.GA11713@ubuntu-dmitri> From: Martin Thomson Date: Fri, 25 Aug 2017 08:26:48 +1000 Message-ID: Subject: Re: Why is MAX_DATA in units of 1024 octets? To: Dmitri Tikhonov Cc: Ian Swett , IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 22:26:56 -0000 Most of the integers we have need to be encoded. That naturally leads to multiples of 8 bits. That's the first reason for having the numbers as they are. And terabit rates aren't implausible. On 24 August 2017 at 23:15, Dmitri Tikhonov wrote: > That's the thing: every QUIC implementation will have code to > handle -- and unit tests to test -- a condition that will never occur. As I said, you don't have to send that much. If you have a limit of 2^50, then when someone sends you a value of 2^40 or higher, stop paying attention to the flow control limit and rely on your own limit. It's not that hard. From nobody Thu Aug 24 15:57:20 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9E013291C for ; Thu, 24 Aug 2017 15:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, 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 HToVUHK1_Asr for ; Thu, 24 Aug 2017 15:57:15 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E671323AA for ; Thu, 24 Aug 2017 15:57:14 -0700 (PDT) Received: from mail-yw0-f180.google.com (mail-yw0-f180.google.com [209.85.161.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 74C88278540 for ; Fri, 25 Aug 2017 07:57:09 +0900 (JST) Received: by mail-yw0-f180.google.com with SMTP id s143so5034987ywg.0 for ; Thu, 24 Aug 2017 15:57:09 -0700 (PDT) X-Gm-Message-State: AHYfb5hK+GH2yCUA1fYhAxZGQDMh5BeYDupj9lFFP9N7eiO22PZN0g7v npHYuvPdEDLdbv/vVgBkm9ltCBqafg== X-Received: by 10.13.226.70 with SMTP id l67mr2858449ywe.201.1503615428242; Thu, 24 Aug 2017 15:57:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.68.193 with HTTP; Thu, 24 Aug 2017 15:57:07 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 24 Aug 2017 15:57:07 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Congestion control algorithm questions To: Martin Thomson Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 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, 24 Aug 2017 22:57:18 -0000 Hi Martin, On Thu, Aug 24, 2017 at 3:20 PM, Martin Thomson wrote: > My impression was that byte counting was common, but it still seems > like an error in the RFC to not consider the possibility that someone > might generate an ACK for every byte they receive. Using the math > there and a modest SMSS, I could force a connection into CA and then > cause your congestion controller to ratchet up by a megabyte per round > trip (assuming that I can get 1000 or so ACKs through, of course[1]). > That's more aggressive than slow start. ABC obviously corrects that > problem, but it's odd that the RFC seems to forget this point. I'm not sure why you think it is forgotten. rfc5681 mentions using ABC to provide robustness against ACK division attack. -- Yoshi From nobody Thu Aug 24 16:08:13 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0F1329C1 for ; Thu, 24 Aug 2017 16:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 KO9ZOlDD9Whm for ; Thu, 24 Aug 2017 16:08:09 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D9071329B2 for ; Thu, 24 Aug 2017 16:08:09 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id g33so3071992ioj.3 for ; Thu, 24 Aug 2017 16:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DSg1fbcg+ql6DfgHFGWbV7kQhC3r44gTjW6WJUiz50g=; b=FKH2U4uVcJhDWEqPxd9Z8x3rvjoACFAfCeehlzYEc+VtULL3MsYuk0jQfoOnr4FS6d B7IjT68AHQXFZUV4lsSXwJLCxidGmw+7RpldNcyQ1eF2gha/JBarNaLcNtMJvfoNczgY RLVcSvNb+ULzb7NYiH78DMIDuzn/bWkF+frF4QT1KDUCSs4WCw8P5cOBeP1Jldw++ciN +eqeZ+6jI1M2KwP7vr3N9oUYhAGyEa4UN41As6VANO+M9w5QyX9vOWVgYh0qmD6kdSjC GVkPY330QQeW/RO6bx9TNvFFo699Mrat1EpMC1dHOkFG+X39XfvYX9oxMIDU8QGoDIqv jlZQ== 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=DSg1fbcg+ql6DfgHFGWbV7kQhC3r44gTjW6WJUiz50g=; b=Vy0mUgEJ2WuI+AcnDAk/IycwR1kET9gBK8oakTACGt3WJ19fRwdMONirh5mTnC+B47 6wJmCR73oks4hD9gvZD8OoXNhO/wA3MD5EYZhb4TWUJ1xbogpZ1l5nHbTy+gEZJrpS7/ a1sggPSSSHW1IPemH/52Sn4gxbfZY8SnY9gTWt0VcFC8y6HjoB6Te6CnAgpzxMJot3hf Q1QiKk19/0Cr5AEqg6hZX3NlVeWjxSFFmmuec9vY3ydxJXnJiu1Wp7NyWeUejf0Gw7Hz Gs41LZNzMfzyAfmxiKibfwLMw4YQhZV3lIT1ouuuojWCNHAigVRdCoxHaZj90lHWADjZ PPOQ== X-Gm-Message-State: AHYfb5jKQ7D+6nypMiuqcV69D3ZJFyogSqpz8aeZphwtVaN96ZFraneT mEdusv+HMrogBhAfBg20byiCZGXyaTmkRK8= X-Received: by 10.107.59.70 with SMTP id i67mr7498075ioa.72.1503616088750; Thu, 24 Aug 2017 16:08:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Thu, 24 Aug 2017 16:08:08 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 25 Aug 2017 09:08:08 +1000 Message-ID: Subject: Re: Congestion control algorithm questions To: Yoshifumi Nishida Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 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, 24 Aug 2017 23:08:11 -0000 On 25 August 2017 at 08:57, Yoshifumi Nishida wrote: > I'm not sure why you think it is forgotten. > rfc5681 mentions using ABC to provide robustness against ACK division attack. It's equation 3 that distresses me. The remainder of the text does mention it, but provides no formula. cwnd += SMSS*min(N,SMSS)/cwnd would be a fine formula to have included somewhere, but this is left to the reader to work out for themselves. Also, RFC 3465 defines the following algorithm during congestion avoidance: When bytes_acked becomes greater than or equal to the value of the congestion window, bytes_acked is reduced by the value of cwnd. Next, cwnd is incremented by a full-sized segment (SMSS). That practically invites ACK division attacks. From nobody Thu Aug 24 16:52:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94D61326DF for ; Thu, 24 Aug 2017 16:52:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.3 X-Spam-Level: ** X-Spam-Status: No, score=2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YdnKw0ekQn3 for ; Thu, 24 Aug 2017 16:52:48 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC37132697 for ; Thu, 24 Aug 2017 16:52:47 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id x21so5467513ywg.2 for ; Thu, 24 Aug 2017 16:52:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=buagV4VuKCwI8k0LV3mlgnwL8ia2b5y8qV2R4e0IxKE=; b=a5JuaSyHsd3eWXEfJjdJUIyNiP+M4+VBncsX+ba1DV1ApbelYGw8Uoe7ROuZWlej/z 52rl6P7bcVi4h4TdpoAifOk6NSPsN/Ve+KxqraTkDhvAAAsmk71XSoW85pCL3Jqww5KI 61VzRq2ZMG7yPbJsiY2qca43Ai5e4KVbKpVi32z5m8f4t2GOjvJsLhSl52NAMMgChlfq GnH3kHarzciDhZ1LtUivt/Axc+aAEYgdM7hQ9jeFnJu13CYRsOotgUg/nfjrCrRXjmUL 3v1quGmpHWyIwwYdtle/E+Bv99t8QDwWvVfBT4/1hJ35DbjHiScfA42NM6CHa/C3liR5 J8sQ== 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=buagV4VuKCwI8k0LV3mlgnwL8ia2b5y8qV2R4e0IxKE=; b=af5BwxJWA0PSn6WM3OsmxJH7A3rynpAAk/tTpn6p8IWIqvyaem2a8Bnaj7gCAqp/G0 IfdPXsIQ6P3I1dSpMraw4clUHF+owaC9/Yjv6HIob4bMzfRIOKlMGD+EapjyB1Bkf3f7 bQHJU+vid7zfGm9saTwXDa+5puraMP7w8Hkuqa3gFrQKZLaQLdUf/gYFw6OCtb1AG/h/ uNoVIVUXiq5PIBcgDc5m7C4+6HXHF06d8L7ja/GVIGuiP/cnkBLzEEm0wk3ZGY/GcTZO EL56vPuagKu7GQulitfBCd8kxR0fsuGceeKmCEQ/PNzHhbaZh/FgNDGXnQ0k810GGL32 BBIw== X-Gm-Message-State: AHYfb5jJQ3sgqwVwtROzgyd/rNG8UPIYMlv7R63qx46TodgrTQZpScSb q+VgAxRocDBJpMY+6Z3aoQFZnvMJKw4P X-Google-Smtp-Source: ADKCNb5CVCns4I9xabDA8Avb2aFlAkhVTCEY8Ey7z1ek92QpvMz+J/qsSePwWTdtLtO8oNto1Ogfe96GxC7sXoAXp58= X-Received: by 10.13.233.198 with SMTP id s189mr6218080ywe.32.1503618766936; Thu, 24 Aug 2017 16:52:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.132 with HTTP; Thu, 24 Aug 2017 16:52:26 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Thu, 24 Aug 2017 19:52:26 -0400 Message-ID: Subject: Re: Congestion control algorithm questions To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c07cbe47ba0bc0557888618" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 24 Aug 2017 23:52:50 -0000 --94eb2c07cbe47ba0bc0557888618 Content-Type: text/plain; charset="UTF-8" Thanks for taking a close look at the draft. On Thu, Aug 24, 2017 at 1:52 AM, Martin Thomson wrote: > I've barely usable Internet access today, so I've had a lot of time to > contemplate congestion control. > > I read through the congestion and loss recovery document and have a > few questions and observations. These are in email form because I'm > not an expert on this stuff and it could be my poor understanding. > > Firstly, the heavy reliance on pseudocode here is to the detriment of > clarity. There are numerous examples of this, but here are two I > found to be unnecessarily obtuse: > > Yes, the hope is that the pseudocode will compliment the text, but at this point neither are completely sufficient. > 1. I realize that some people have internalized the fact that > (end_of_recovery < largest_lost_packet.packet_number) and > (acked_packet.packet_number < end_of_recovery) mean that the > connection is out of recovery and in recovery respectively, but this > is not very clear. I think that clarity would be improved > immeasurably by an IsInRecovery() function. Maybe also some text. > Good suggestion. > > 2. The same goes for several other tests that are performed > throughout, in particular (congestion_window < ssthresh) which would > be better as IsInSlowStart() / not IsInCongestionAvoidance() / > CwndIncrease() == slow_start / CwndIncrease() == congestion_avoidance. > > InSlowStart() is also a good suggestion(and is actually present in the GQUIC code). > The next is that there are unused and undefined variables. > acket_packets/acked_packets is the one that I noticed most acutely > this time. When the congestion control is given an ACK to process, I > infer that this means the sum of the lengths of newly acknowledged > packets in that ACK. However this variable is derived, it needs to be > explicitly defined somehow. > > SG, will attempt to fix this. > Reading RFC 5681, its congestion avoidance algorithm is > SMSS*SMSS/cwnd, which takes a fair bit of effort to map to > acked_packets.bytes / cwnd. If I'm right, the unstated assumption in > RFC 5681 is that the sender is transmitting as much as the cwnd > permits, it is sending every segment at the maximum size (SMSS) and > the receiver is acknowledging every segment it receives. That way the > sender sends cwnd/SMSS segments every round trip and receives that > many acknowledgements. This seems to be the only way that the stated > goal of an increase of 1*SMSS per RTT is achievable. > Yes, most congestion control specs assume the sender is never app-limited(which is ridiculous, but...). QUIC is specified to count bytes(RFC 3465), so the packet size should not matter. The idea is for every CWND acknowledged, the CWND increases by SMSS. > Aside: For those up to speed on TCP, can they explain why ACK > splitting isn't considered when in congestion avoidance? So much > effort is spent on explaining why it's important during slow start, > then the spec seems to forget this. Sure, the effect is not as > significant in congestion avoidance, but it's still baffling. The > same applies if the sender sends more and smaller segments. Surely > that leads to a larger increase in CWND in the same way that splitting > ACKs would. > I think that is also fixed when implementations do appropriate byte counting(RFC 3465)? > It seems like QUIC attempts to address this by accounting for bytes > received. The idea appears to be to trade this off against reducing > the rate at which the window expands in congestion avoidance on > connections that aren't using the full connection capacity. I think > that the formula might be incorrect. Currently, it is: > > congestion_window += acked_packets.bytes / congestion_window > > I think that it probably wants to be something like: > > congestion_window += kDefaultMss * acked_packets.bytes / > congestion_window > > (Here I'm assuming that kDefaultMss =~ SMSS, though it seems like the > actual constant might need some better justification. Would this > integrate MTU discovery if that were performed? Or would this produce > the wrong outcome on paths with an unusual-sized MTU?) > > Good catch, this is an error, assuming both variables are in bytes, which they should be. > Otherwise, the formula will produce an increase of one byte for every > round trip, or - more precisely - every time an entire congestion > window worth of data is acknowledged. That seems a little too > cautious. > > I found the description of when the congestion window is reset to be > baffling: > > > QUIC decreases the congestion window to the minimum value once the > retransmission timeout has been confirmed to not be spurious when the first > post-RTO acknowledgement is processed. > > Maybe consider rephrasing that one. > > I can split it into two sentences, but the text is fairly accurate. --94eb2c07cbe47ba0bc0557888618 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for taking a close look = at the draft.

On Thu, Aug 24, 2017 at 1:52 AM, Martin Thomson <martin.thomson@g= mail.com> wrote:
I've= barely usable Internet access today, so I've had a lot of time to
contemplate congestion control.

I read through the congestion and loss recovery document and have a
few questions and observations.=C2=A0 These are in email form because I'= ;m
not an expert on this stuff and it could be my poor understanding.

Firstly, the heavy reliance on pseudocode here is to the detriment of
clarity.=C2=A0 There are numerous examples of this, but here are two I
found to be unnecessarily obtuse:


Yes, the hope is that the pseudocode w= ill compliment the text, but at this point neither are completely sufficien= t.
=C2=A0
1. I realize that some people have internalized the fact that
(end_of_recovery < largest_lost_packet.packet_number) and
(acked_packet.packet_number < end_of_recovery) mean that the
connection is out of recovery and in recovery respectively, but this
is not very clear.=C2=A0 I think that clarity would be improved
immeasurably by an IsInRecovery() function.=C2=A0 Maybe also some text.
=

Good suggestion.=C2=A0

2. The same goes for several other tests that are performed
throughout, in particular (congestion_window < ssthresh) which would
be better as IsInSlowStart() / not IsInCongestionAvoidance() /
CwndIncrease() =3D=3D slow_start / CwndIncrease() =3D=3D congestion_avoidan= ce.


InSlowStart() is also a good suggestio= n(and is actually present in the GQUIC code).
=C2=A0
The next is that there are unused and undefined variables.
acket_packets/acked_packets is the one that I noticed most acutely
this time.=C2=A0 When the congestion control is given an ACK to process, I<= br> infer that this means the sum of the lengths of newly acknowledged
packets in that ACK.=C2=A0 However this variable is derived, it needs to be=
explicitly defined somehow.


SG, will attempt to fix this.
=C2=A0
Reading RFC 5681, its congestion avoidance algorithm is
SMSS*SMSS/cwnd, which takes a fair bit of effort to map to
acked_packets.bytes / cwnd.=C2=A0 If I'm right, the unstated assumption= in
RFC 5681 is that the sender is transmitting as much as the cwnd
permits, it is sending every segment at the maximum size (SMSS) and
the receiver is acknowledging every segment it receives.=C2=A0 That way the=
sender sends cwnd/SMSS segments every round trip and receives that
many acknowledgements.=C2=A0 This seems to be the only way that the stated<= br> goal of an increase of 1*SMSS per RTT is achievable.
<= br>
Yes, most congestion control specs assume the sender is never= app-limited(which is ridiculous, but...).

QUIC is= specified to count bytes(RFC 3465), so the packet size should not matter.<= br>

The idea is for every CWND acknowledged, the C= WND increases by SMSS.


Aside: For those up to speed on TCP, can they explain why ACK
splitting isn't considered when in congestion avoidance?=C2=A0 So much<= br> effort is spent on explaining why it's important during slow start,
then the spec seems to forget this.=C2=A0 Sure, the effect is not as
significant in congestion avoidance, but it's still baffling.=C2=A0 The=
same applies if the sender sends more and smaller segments.=C2=A0 Surely that leads to a larger increase in CWND in the same way that splitting
ACKs would.

I think that is also fixed = when implementations do appropriate byte counting(RFC 3465)?=C2=A0


It seems like QUIC attempts to address this by accounting for bytes
received.=C2=A0 The idea appears to be to trade this off against reducing the rate at which the window expands in congestion avoidance on
connections that aren't using the full connection capacity.=C2=A0 I thi= nk
that the formula might be incorrect.=C2=A0 Currently, it is:

=C2=A0 =C2=A0congestion_window +=3D acked_packets.bytes / congestion_window=

I think that it probably wants to be something like:

=C2=A0 =C2=A0congestion_window +=3D kDefaultMss * acked_packets.bytes / con= gestion_window

(Here I'm assuming that kDefaultMss =3D~ SMSS, though it seems like the=
actual constant might need some better justification.=C2=A0 Would this
integrate MTU discovery if that were performed?=C2=A0 Or would this produce=
the wrong outcome on paths with an unusual-sized MTU?)


Good catch, this is an error, assuming= both variables are in bytes, which they should be.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> Otherwise, the formula will produce an increase of one byte for every
round trip, or - more precisely - every time an entire congestion
window worth of data is acknowledged.=C2=A0 That seems a little too
cautious.

I found the description of when the congestion window is reset to be baffli= ng:

> QUIC decreases the congestion window to the minimum value once the ret= ransmission timeout has been confirmed to not be spurious when the first po= st-RTO acknowledgement is processed.

Maybe consider rephrasing that one.


I can split it into= two sentences, but the text is fairly accurate.
--94eb2c07cbe47ba0bc0557888618-- From nobody Thu Aug 24 17:15:50 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819E71329D1 for ; Thu, 24 Aug 2017 17:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 DIDXLNx3oioq for ; Thu, 24 Aug 2017 17:15:44 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DBA11321F5 for ; Thu, 24 Aug 2017 17:15:42 -0700 (PDT) Received: from mail-yw0-f175.google.com (mail-yw0-f175.google.com [209.85.161.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id C9C542784FA for ; Fri, 25 Aug 2017 09:15:37 +0900 (JST) Received: by mail-yw0-f175.google.com with SMTP id s143so5695997ywg.0 for ; Thu, 24 Aug 2017 17:15:37 -0700 (PDT) X-Gm-Message-State: AHYfb5i9jAagqvRVl5w3lJn5BdMcj0UMNktIpUqBzvFP0FJuzuPr4C3H bFoI5BcZ28KjeZ5ZeKRqm4kokHUsFQ== X-Received: by 10.129.84.139 with SMTP id i133mr6236694ywb.273.1503620136321; Thu, 24 Aug 2017 17:15:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.68.193 with HTTP; Thu, 24 Aug 2017 17:15:35 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 24 Aug 2017 17:15:35 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Congestion control algorithm questions To: Martin Thomson Cc: Yoshifumi Nishida , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 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, 25 Aug 2017 00:15:48 -0000 Hi Martin, On Thu, Aug 24, 2017 at 4:08 PM, Martin Thomson wrote: > On 25 August 2017 at 08:57, Yoshifumi Nishida wrote: >> I'm not sure why you think it is forgotten. >> rfc5681 mentions using ABC to provide robustness against ACK division attack. > > It's equation 3 that distresses me. The remainder of the text does > mention it, but provides no formula. cwnd += SMSS*min(N,SMSS)/cwnd > would be a fine formula to have included somewhere, but this is left > to the reader to work out for themselves. Fair enough. But, in my interpretation, the equation 3 is used to describe the concept (and it is "MAY use"). Also, since rfc3465 is an experimental, we can also try other similar formulas if we want. > Also, RFC 3465 defines the following algorithm during congestion avoidance: > > When > bytes_acked becomes greater than or equal to the value of the > congestion window, bytes_acked is reduced by the value of cwnd. > Next, cwnd is incremented by a full-sized segment (SMSS). > > That practically invites ACK division attacks. Hmm, not sure how it invites ACK division attacks.. You can increase cwnd only when byte_acked >= cwnd. -- Yoshi From nobody Thu Aug 24 17:26:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FF71329CD for ; Thu, 24 Aug 2017 17:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buM3dKu1tWHx for ; Thu, 24 Aug 2017 17:26:02 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FBCE1329CC for ; Thu, 24 Aug 2017 17:26:01 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id g33so3469650ioj.3 for ; Thu, 24 Aug 2017 17:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=39HjXZLdk1SrlDmzbMGxArsd7XzYhOAR8WooNg/ezZ0=; b=kb9rOzX4loK1Phdye9sVlJLgPNdkVBd4po6otCXWV2qzkWCBRZzursKtWWT8+An0hw ae8FZ7t+o5ExR1IjmRb67gtdxGoDSAEpUfrpKaHd68urt/VtOdVg52nwf/ERE2Dm9yPE DG1/8TsDHDzYOa4Y18EhARC9YOUBd7cH0NHNCrewZ6YyNs2JgDkoWAFnmaDFtlsSIgFU bKxFm07wuKFyc5Ndl5U/RoADd5aQ2VXwg6bq2N6k4OueCRLTIeI7OwG8dGE4SDeWWfCU j6O7/SD38JSOwNTcO0t22Br5jMh1XZARCkV3C2bcgDGHEzHQW7ZNC/V/gUabHB6qpBhF D38A== 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=39HjXZLdk1SrlDmzbMGxArsd7XzYhOAR8WooNg/ezZ0=; b=M09iGACEM2FhuGAGG3DUM2iTIYXAIrWmPxXwg5zwsoxpjRGmOkgPEItS6eNrPmBZ5p 6+lmCaKv8P2cFduwO4HFklPuari0sPE2NH6FDrEEUyehHDb3hIHU6cYB+dck3xl/X0Fj LBMKYpgI3UsPs+xqZ5XcjQ/ULmK/axUHOPH2Paz6U/i6Qy2XgQpE0ox52/YuxDkc4zVB 0PuDEXZj3c6lXUXVfS8sM8uMRhL5sa3mS0PmcUgKbO/5D+JCYPl4yMnHg6Vpoy9QmBIr +e6tID3l56HOxWxOoPJkF9twyuPJRPLYfGzEn1ZxuwUBNG2IIHmkJYD4/O3C+NuD2vTu nUSg== X-Gm-Message-State: AHYfb5g2JFLkLeUm7At8Qx2tH3W2pOSqqnfLs6y/qobg1icXex3GT7cw 3N0yHMth2SVdELR9XmTmdMu1fxnqqA== X-Received: by 10.107.59.70 with SMTP id i67mr7664791ioa.72.1503620761211; Thu, 24 Aug 2017 17:26:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.159.75 with HTTP; Thu, 24 Aug 2017 17:25:59 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 25 Aug 2017 10:25:59 +1000 Message-ID: Subject: Re: Congestion control algorithm questions To: Yoshifumi Nishida Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , 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, 25 Aug 2017 00:26:04 -0000 On 25 August 2017 at 10:15, Yoshifumi Nishida wrote: > Hmm, not sure how it invites ACK division attacks.. > You can increase cwnd only when byte_acked >= cwnd. Oh, I see. I misread. From nobody Thu Aug 24 22:52:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75A3B132954 for ; Thu, 24 Aug 2017 22:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMOn69nsrJQo for ; Thu, 24 Aug 2017 22:52:32 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E37C131D27 for ; Thu, 24 Aug 2017 22:52:32 -0700 (PDT) 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 1dl7Xb-0003Tx-4c for quic@ietf.org; Fri, 25 Aug 2017 07:52:29 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dl7XX-0007S1-Kb for quic@ietf.org; Fri, 25 Aug 2017 01:52:20 -0400 Received: (qmail 10824 invoked from network); 25 Aug 2017 05:52:17 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 05:52:17 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> Date: Thu, 24 Aug 2017 22:52:14 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Congestion control algorithm questions X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWea6pBBugJdVQWCV6zgcsND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23uahmRp+YBlecRecHJXo19NLrUi7cn2NORKNn NPpYi2fu66veXX8qGLF9z0ZW6RTqYOEkjsX7F8KmpUaZQHV+SU9tg6wnJ2lrZSUCZrKFYsG2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKrrXdhf8mmRqp8CWMEqUPf6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyYunZW1723s92xzFjs4mTUveNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj2357kOoTgosukdyElz7rBwHENdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxpi7UzHpJO9QrRDBoaz9Nyw078I0y+3uS4dN KiUgYTBUntp7TjeG3C6rIZDFvvceSYAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/RufmJqHIgpwQblHGid2pC00i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 05:52:34 -0000 On 8/23/2017 10:52 PM, Martin Thomson wrote: > I read through the congestion and loss recovery document and have a > few questions and observations. These are in email form because I'm > not an expert on this stuff and it could be my poor understanding. > > Firstly, the heavy reliance on pseudocode here is to the detriment of > clarity. There are numerous examples of this, but here are two I > found to be unnecessarily obtuse: I must say that I have some very similar feedback. The liberal use of pseudo-code in the recovery draft makes it seriously confusing. The recovery part should be simple enough. QUIC has a monotonously increasing packet sequence number, which simplifies the algorithm greatly. The recovery can be summarized by a set of simple decisions: 1) Are all packets candidate for retransmission? =C2=A0=C2=A0=C2=A0 No. Only those that contain important date.=C2=A0 Ther= e is no need to even acknowledge the other packets. 2) Is this packet lost? =C2=A0=C2=A0=C2=A0 The answer is Yes if another packet has already been a= cknowledged, with a sequence number more than N packets greater that the candidate packet. =C2=A0=C2=A0=C2=A0 The answer is also Yes if another packet has already b= een acknowledged, if it was sent more than delta-T after the candidate packet= =2E =C2=A0=C2=A0=C2=A0 And the answer is also Yes if more than Timer has elap= sed since the packet was sent. The variables N, delta-T and Timer are parameter of the algorithm. By default, they can be set to 3, the max of RTT/8 and 1 millisecond, and RTT plus two RTT standard deviation, respectively. Using a more conservative timer does not hurt much, because we expect that the sequence number and Delta-T test will be sufficient in most cases. If we were adventurous, we would add to the protocol some dynamic evaluation of N and Delta-T, based on the observation of out of of order packet deliveries. Of course, this is much easier to observe at the receiver, so we would need to define a management frame to pass these parameters. But I don't know whether we are that adventurous. 3) Can the senders do something to speed up retransmission? In the absence of continuous traffic flow, the previous decision tree degenerates to timer based retransmission. To speed things up, implementations can generate extra traffic. For example, if no acknowledgement is received after a short timer, they can send a gratuitous packet that may trigger a further acknowledgement. That's the essence of the "tail loss probe" algorithm of TCP, but things are really simpler with monotonously increasing packet sequence numbers. There are various plausible ways to send a gratuitous packet -- a Ping, a Max Data Update, or repeating the oldest packet will all work. Of course, implementations should avoid sending too many gratuitous packets, because it can cause congestion. The typical implementation will wait one min-RTT before sending the first tail loss probe, then just wait for the regular timer based retransmission. But we may start being creative. For example, if packets are waiting and the implementation is sending a naked ACK for whatever reason, it does not cost much to add a Ping to that. This simple text encompasses SACK, RACK, and Tail-Loss Probe. And it is very easy to implement. --=20 Christian Huitema From nobody Fri Aug 25 01:26:16 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E17132623 for ; Fri, 25 Aug 2017 01:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRRjKiAh_Lju for ; Fri, 25 Aug 2017 01:26:12 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C1D0132332 for ; Fri, 25 Aug 2017 01:26:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3xdvPt2BBzzMp47; Fri, 25 Aug 2017 10:26:10 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKNJpeIVyzup; Fri, 25 Aug 2017 10:26:09 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11DEC.dip0.t-ipconnect.de [217.225.29.236]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 25 Aug 2017 10:26:09 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Congestion control algorithm questions From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> Date: Fri, 25 Aug 2017 10:26:08 +0200 Cc: quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> References: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 08:26:15 -0000 Hi Christian, just one minor side comment: > Am 25.08.2017 um 07:52 schrieb Christian Huitema = : >=20 > 1) Are all packets candidate for retransmission? > No. Only those that contain important date. There is no need to > even acknowledge the other packets. You need to acknowledge all packets because the loss rate is/may be = input for congestion control. Mirja From nobody Fri Aug 25 01:43:58 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 282A9132623 for ; Fri, 25 Aug 2017 01:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pshlAi_CAb5F for ; Fri, 25 Aug 2017 01:43:54 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 727971241F5 for ; Fri, 25 Aug 2017 01:43:54 -0700 (PDT) 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 6284D1B00191; Fri, 25 Aug 2017 09:43:28 +0100 (BST) Message-ID: <599FE330.9010101@erg.abdn.ac.uk> Date: Fri, 25 Aug 2017 09:43:28 +0100 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mirja_K=FChlewind?= CC: Christian Huitema , quic@ietf.org Subject: Re: Congestion control algorithm questions References: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> In-Reply-To: <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 08:43:57 -0000 On 25/08/2017, 09:26, Mirja Khlewind wrote: > Hi Christian, > > just one minor side comment: > >> Am 25.08.2017 um 07:52 schrieb Christian Huitema: >> >> 1) Are all packets candidate for retransmission? >> No. Only those that contain important date. There is no need to >> even acknowledge the other packets. > You need to acknowledge all packets because the loss rate is/may be input for congestion control. > > Mirja > I agree there is a need to report *all* (or ACK virtually all) received segments - that doesn't mean the sender has to retransmit "lost" segments, but is one important input to a congestion controller that is "safe" for deployment outside of a controlled environment. Gorry From nobody Fri Aug 25 06:25:14 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E34132BEE for ; Fri, 25 Aug 2017 06:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs03-dfbs7x1 for ; Fri, 25 Aug 2017 06:25:11 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7B9132BED for ; Fri, 25 Aug 2017 06:25:11 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id x36so10927011qtx.2 for ; Fri, 25 Aug 2017 06:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=/3G9Vlv0BmUPfQdR47lOgYqtF+OoUrX6x7H8fZ7MwCs=; b=SdWMa2cpRQ4w8p/W12pbq/yxCqeMw2G1br5mBhNl1g+XTDz0q5RacqWddJ1sbtDFS6 Fav7Lxv1teJC1JSFUhdYSAwEFuTKAsD1y8mRKPvey7Un42mG2pco1EQAM5j6C+nfRiyk /Iw8imjoWAPiqXk/SKZUmgQS9S5TLbJomc94xePs7GsHMmaxb1OxsOTF/lZ1lZexcEuX S/Q40oLlMN7sHInFlCYsv91VptS+lSFy6xwMDzUJxBrr+eraZuV0zdzFg6Tk7Qx3/E5L b5Riy2zowISKNrXGqvUZ0ezqsDevOEyPSPQN3nO+bPlpJLsD/Pc75xeCQJe/Bdv60cKY kG+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=/3G9Vlv0BmUPfQdR47lOgYqtF+OoUrX6x7H8fZ7MwCs=; b=E+RwHGu/mVqLJYVjqnHsHV8siO/xSAEWz8Mot22YZfuLPB9F2BRQ250XFEil5+IMhT BWKwvRHCqjvhBGbLU8//lEZEj3sY3UgO50sX5cyyKF9Wo3Jkhzz4hgDW1e8uGlAA668v rIcmaw9v9pA8lY1B1xm38E9tHhTLNViXyEEd2BMuIImMuFOxo2PYTXwL40sJ2kb+Jf6Y C/BCv1A6/DdutOI5O+RqAienbiekqPlm99GNmSSFKhcAmJJ893uCsTQ0OjoFLABtcxrB Jr1KGfZfVQylrLoLogVbTe83cRl404aaQzfZ1okvn/e1hYMjieGGcazwVC9KSkU+nhdW nUWg== X-Gm-Message-State: AHYfb5hGoG8ytB1C/5r+ptdnAXkWxoljl7yhm4gUQp04wIXJQsAB6KbB DNe9/g8XuuwXnr8J X-Received: by 10.200.3.73 with SMTP id w9mr12987102qtg.108.1503667510164; Fri, 25 Aug 2017 06:25:10 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id e16sm3994993qkj.53.2017.08.25.06.25.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Aug 2017 06:25:09 -0700 (PDT) Date: Fri, 25 Aug 2017 09:24:59 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: Ian Swett , IETF QUIC WG Subject: Re: Why is MAX_DATA in units of 1024 octets? Message-ID: <20170825132458.GB17110@ubuntu-dmitri> References: <20170823205057.GA8231@ubuntu-dmitri> <20170824131556.GA11713@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 13:25:13 -0000 On Fri, Aug 25, 2017 at 08:26:48AM +1000, Martin Thomson wrote: > Most of the integers we have need to be encoded. That naturally leads > to multiples of 8 bits. That's the first reason for having the > numbers as they are. That's not what I wrote. I wrote: " the maximum numbers of streams and packets are picked a) to be " large enough and b) to match standard integer sizes. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ How numbers are encoded is not important here; what's important is that there are limits at all. And it's those limit sizes -- after decoding -- is at the root of the discussion. > And terabit rates aren't implausible. Fine, so my hypothetical scenario would take 4.5 years, which is still quite unlikely to occur. Speaking of likelihoods, why cap the maximum stream data at 2^64 and connection stream data at 2^74 -- is it more likely that a connection will have a combination of streams whose data will exceed 2^64 than a single stream that needs to transfer more than 2^64? Why not also allow more than 2^64 packets? At what point do we stop or don't stop any why? I argue that 2^64 is "large enough." In other words, for all intents and purposes 2^64 is infinity in the context of a QUIC connection. The explanation that Ian Swett provided, that " the thinking was that if we allow 2^32 streams and 2^64 packets " that the max connection level flow control value becomes the " limiting factor of connection lifetime does not explain the *need* for a number larger that 2^64. Yes, one infinity can be larger than another, but in practice we just do not care: we are unlikely to hit 2^64 packets, 2^64 bytes per stream, or 2^64 bytes per connection. 2^64 is a very large number that is easy to use because it fits into a standard integer size. Including a 2^74 number in the draft would do well with an explicit justification. > On 24 August 2017 at 23:15, Dmitri Tikhonov wrote: > > That's the thing: every QUIC implementation will have code to > > handle -- and unit tests to test -- a condition that will never occur. > > As I said, you don't have to send that much. If you have a limit of > 2^50, then when someone sends you a value of 2^40 or higher, stop > paying attention to the flow control limit and rely on your own limit. > It's not that hard. You made my point. - Dmitri. From nobody Fri Aug 25 10:44:56 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB581321F6 for ; Fri, 25 Aug 2017 10:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 DIsc6BLlpYfk for ; Fri, 25 Aug 2017 10:44:53 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4211321B0 for ; Fri, 25 Aug 2017 10:44:53 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dlIf3-0001mY-QQ for quic@ietf.org; Fri, 25 Aug 2017 19:44:50 +0200 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 1dlIex-0002qY-TE for quic@ietf.org; Fri, 25 Aug 2017 13:44:47 -0400 Received: (qmail 8799 invoked from network); 25 Aug 2017 17:44:42 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 17:44:41 -0000 To: gorry@erg.abdn.ac.uk, =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: quic@ietf.org References: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> <599FE330.9010101@erg.abdn.ac.uk> From: Christian Huitema Message-ID: <17aada09-9172-afaf-ac1e-0c6bcb6ada2e@huitema.net> Date: Fri, 25 Aug 2017 10:44:38 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <599FE330.9010101@erg.abdn.ac.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Congestion control algorithm questions X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJY8hyefn/FOeAH6Zsqubs62ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23Lx5/dhlsn9rCnnauHParxOrb0NcNtDvNf3// WNJLl96L7luqTUvkABhG0pb+4sVgYOEkjsX7F8KmpUaZQHV+SWsC1ltxhvDAAiytf1zpGXO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKOHi0RYvlOYvJoUtCbvS/b6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZiLxqZAYuxlObtK9AVlftneNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5lorSoCYRNcdNYFM9Dkt7piwO7IVXITpPh1qZI 46Rz116scTfxWu56NIzAhSqR2Y59MV9e6qt4y0llDRDaFA2tZcPw1eMmeklA3MQEw0NwP6IDPa8Q GWJY81iEsidlXaP4/sbpzuwjGHyC+YDvAYilEDMDfIyv/8g9jBVB+FIvPIqaxFsYxzp73yKmZ7FG FxtqMg== 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, 25 Aug 2017 17:44:55 -0000 On 8/25/2017 1:43 AM, Gorry Fairhurst wrote: > On 25/08/2017, 09:26, Mirja K=C3=BChlewind wrote: >> Hi Christian, >> >> just one minor side comment: >> >>> Am 25.08.2017 um 07:52 schrieb Christian Huitema= : >>> >>> 1) Are all packets candidate for retransmission? >>> =C2=A0=C2=A0=C2=A0=C2=A0 No. Only those that contain important date.=C2= =A0 There is no need to >>> even acknowledge the other packets. >> You need to acknowledge all packets because the loss rate is/may be >> input for congestion control. >> >> Mirja >> > I agree there is a need to report *all* (or ACK virtually all) > received segments - that doesn't mean the sender has to retransmit > "lost" segments, but is one important input to a congestion controller > that is "safe"=C2=A0 for deployment outside of a controlled environment= =2E Yes, Mirja and Gory, you are both right. All received packets shall be reported. But this goes back to Martin's original criticism of the recovery draft. The reliance on pseudo-code obscures the reasoning, and may leave aside important questions. So my original 3 point list should be continued with another three points noted below. When it comes to congestion control, there is a need for a similar effort of explanation and simplification, but that should come later. =C2=A0=C2=A0 4) Should all packets be acknowledged? =C2=A0=C2=A0 Yes. All received packet numbers need to be reported in the = ACK. This is important both for congestion control, since loss of acknowledgements may indicate a problem with the connection, and for ACK trimming, which is described below. There is a subtle difference between the need to be reported and the need to trigger acknowledgements. Packets that do not contain retransmissible data, such as pure ACK, should not trigger acknowledgement. Acknowledging pure acknowledgements would trigger an "ACK of ACK" ping pong storm, and that must be avoided. The pure ACK packets will be acknowledged the next time an important packet triggers an acknowledgement. =C2=A0=C2=A0 5) When should acknowledgements be sent? =C2=A0=C2=A0 Acknowledgements should be sent shortly after important pack= ets have been received. There is tension between sending ACK too late, which will confuse senders, and sending ACK too frequently, which causes excessive network load. Different implementations of TCP have implemented different strategies, such as either sending ACK after receiving 2 data packets, or waiting for a short delay and sending coalesced ACK for all packets received until then. In that case, the "ACK coalescing delay" should not be larger than a fraction of the RTT, such as 1/4th or 1/10th, or maybe 1 millisecond if the RTT is very short. =C2=A0 6) When should acknowledgement lists be trimmed? =C2=A0=C2=A0 The ACK in QUIC contains a list of acknowledged ranges, sepa= rated by holes. The holes normally correspond to packets that have not yet been received, and maybe also to packets that have already been acknowledged. This is similar to the SACK option in TCP, but with an important difference. In TCP, the holes will be filled eventually by retransmissions. In QUIC, this will not happen, because a given packet number is only used once. The number of holes will thus increase over the lifetime of a connection. In the absence of a trimming strategy, a naive implementation would thus send ACK with ever increasing lists of acknowledged ranges, eventually reaching the maximum number of ranges allowed by the protocol, 255. =C2=A0=C2=A0 Another difference between QUIC and TCP is that in QUIC acknowledgement cannot be reneged. This means that acknowledgements need not be repeated if the receiver who sends the ACK knows that the original sender already received the information. This knowledge can be derived from the "ACK of ACK". If the receiver receives an ACK of its own ACK, it knows that the ranges described in that ACK have been noted as received by the original sender. There is no point in repeating them, and they should be trimmed. --=20 Christian Huitema From nobody Fri Aug 25 10:53:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBFD132961 for ; Fri, 25 Aug 2017 10:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 tItuoJFyL0in for ; Fri, 25 Aug 2017 10:53:09 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 475B81321B0 for ; Fri, 25 Aug 2017 10:53:09 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dlIn4-0005tf-Od for quic@ietf.org; Fri, 25 Aug 2017 19:53:07 +0200 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dlIn0-0005p4-4A for quic@ietf.org; Fri, 25 Aug 2017 13:53:02 -0400 Received: (qmail 21185 invoked from network); 25 Aug 2017 17:53:00 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 17:52:59 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> Date: Fri, 25 Aug 2017 10:52:56 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Congestion Control Questions X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.24) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23RzFmc3O3IOphugn4Ex51FS4zRUbL91ymXBhC J0cAH7Uvt9BA0wpnwT2C6dbzqB08YOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyffo/GRhD1emdVDf5USr7WLeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj23767r3uidg2sat2CaHRbMwJNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxsvuWhj/HxWAMoo5nl4RbwELi4lvgMiKKaq3 z7nBANY6SM0AOBORMyUMHhlRtst11hklgDtVC2Xqa4QCRhTuoCmXPUJkXUk8tGhJsBnmMDbaKcNO SCytRyeT1c4b6jF7f/DKzfOCXnJQjcl9DhaIFtyqmgfXlC5BKKIliXyEzbMHRIbZK0lCbLYw/2Y2 Z+15FA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 17:53:11 -0000 I am looking at the recovery and congestion control draft, and I have a couple of questions regarding congestion control. Congestion control attempts to limit traffic to the capacity of the path, in order to avoid building long queues. When the path is shared, congestion control also aims at giving every participant a fair share. But there is a first question: how do we express the capacity of the path? Is it packets per second or bytes per second? Christian Huitema From nobody Fri Aug 25 12:04:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD2132C13 for ; Fri, 25 Aug 2017 12:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWSkB-6RYA9B for ; Fri, 25 Aug 2017 12:04:38 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (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 6DFC913263F for ; Fri, 25 Aug 2017 12:04:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1503687875; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=yJxnsqK7AprO2doBbw+A1pvC41CF0AVtM6OsgLtrMWw=; b=FjvdpYYBzCiGCHjl0h9cmrzQO4VeQ76kkPyFK4lbfp0aQMJZVr5Sc/ywS2nIeJ7d8O Z0W500TsbDimIlrXE6bERBeXTAw9J+SeDZgo3HmNLq+gnmM8Ccdrpxp5gsukaNBg18Wh hBGc/nMvvxy2lIao54pGdmQuYCz+6WFVG90Oo= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJWGoFaiZr7JVkISPZJFw= X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p5DCF40D4.dip0.t-ipconnect.de [93.207.64.212]) by smtp.strato.de (RZmta 41.4 DYNA|AUTH) with ESMTPSA id 906ba8t7PJ4ZOCu (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 25 Aug 2017 21:04:35 +0200 (CEST) Subject: Re: Congestion Control Questions To: quic@ietf.org References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Roland Zink Message-ID: <54b8b1e8-6f56-d049-e25e-68986abd21d4@zinks.de> Date: Fri, 25 Aug 2017 21:04:29 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 19:04:41 -0000 With TCP the congestion control happened in the kernel outside the reach of most programmers. Now with QUIC you give it to app programmers. Will they use a fair algorithm or will they try to "optimize" it for their app? What can be done if somebody use a not so fair scheme? Packets can be short or long, so usually the link capacity is given in bytes per second or bits per second. Roland Am 25.08.2017 um 19:52 schrieb Christian Huitema: > I am looking at the recovery and congestion control draft, and I have a > couple of questions regarding congestion control. Congestion control > attempts to limit traffic to the capacity of the path, in order to avoid > building long queues. When the path is shared, congestion control also > aims at giving every participant a fair share. But there is a first > question: how do we express the capacity of the path? Is it packets per > second or bytes per second? > > Christian Huitema > From nobody Fri Aug 25 12:09:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEAA132BC2 for ; Fri, 25 Aug 2017 12:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAxWdpU336CI for ; Fri, 25 Aug 2017 12:09:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1152B126E64 for ; Fri, 25 Aug 2017 12:09:15 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by m0122330.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v7PJ1Wec003149; Fri, 25 Aug 2017 20:09:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=dsL0DZZdG6HtBv+AiDj3l+9Mh0IRNetM6s8bYyFV35M=; b=fo8Zd0NogICiHObKlmwqdZOOUwIwlGELbCEOVK3Pw41NTC2U8iXa6lPU1z0VKovN/1sj vOI6gVgA9WzcZO2aqrnLdI2vjtZ0pVRj/vr2GuSZLSfDRvpEJ1cAkkterinmU6RWFijE G4jmSwLp8IStHTy5+X6a01l0RkWNkRtWgq0ZGw01aCz5LqBuY4NDRvLT0iNjC3o0PL74 AfkBRyBMGYjeewu6kQ8gZiF6QVp31yCVpBz1rcY3tJq4ykP8pPdiLwcdvNNwBgdGUf1K 5AMvIEIoRdi5fAxE3FrKxTLC0Sa7OidKvKHsD4YY7WZFYvgFQLqVy2vbfup+HtQX6h8D cw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0b-00190b01.pphosted.com with ESMTP id 2cecysms40-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Aug 2017 20:09:13 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7PJ5lnA025853; Fri, 25 Aug 2017 15:09:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2cegnw67tu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Aug 2017 15:09:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 25 Aug 2017 15:09:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 25 Aug 2017 15:09:07 -0400 From: "Salz, Rich" To: Roland Zink , "quic@ietf.org" Subject: Re: Congestion Control Questions Thread-Topic: Congestion Control Questions Thread-Index: AQHTHcsIukDjHbl4HkOm+rcWcYTj0KKVsWyA//++PYA= Date: Fri, 25 Aug 2017 19:09:07 +0000 Message-ID: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <54b8b1e8-6f56-d049-e25e-68986abd21d4@zinks.de> In-Reply-To: <54b8b1e8-6f56-d049-e25e-68986abd21d4@zinks.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1b.0.161010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.148] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708250287 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708250286 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Aug 2017 19:09:17 -0000 4p6iIFdoYXQgY2FuIGJlIGRvbmUgaWYgc29tZWJvZHkgdXNlIGEgbm90IHNvIGZhaXIgc2NoZW1l Pw0KICAgIA0KUHJvYmFibHkgbm90aGluZywgYW5kIHRoYXQgaXMgb2theS4gIFdlIGNhbm5vdCBj b250cm9sIHdoYXQgYXBwbGljYXRpb25zIGRvLg0KDQo= From nobody Fri Aug 25 12:43:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0269132C3E for ; Fri, 25 Aug 2017 12:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMCrxxMXqIyO for ; Fri, 25 Aug 2017 12:43:26 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC899132C3F for ; Fri, 25 Aug 2017 12:43:25 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id 130so4056165qkg.0 for ; Fri, 25 Aug 2017 12:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gQnXlUSpInnNBWuoemXjin0sYtNIUf6hu5F+kQ2oW4k=; b=Vxs+EYBixSZcEPI/pWLJPi/xyyAdyxZlhFpDz6Kn4E1jRbGAp2aIJwjUOPNVArUKF2 qf+Gckpt89gPJBGXgSeDKELCuvEvQxhKQddl/4V2mfIHX4IpliPDrQhJGNzARCzWPZvQ fmeUoZglQvNYkXNPdKzQGV2BlhUlFqu3v7DoR9NlzG8Lt170qZp9mseHc6RRnpKNNV4+ C2OB0QI8U1EYJhxloZ1dHJw2zdYWB8vybqiodwEy2hsN+KbFwWkgH23OblPAkH3xLBHm mZ3R2OwyBT8hifx5DKG2yY5q3rb4dYfMFeroWpzFPibII3WdmCE+7pMELdDevwIAK+HW VUrA== 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=gQnXlUSpInnNBWuoemXjin0sYtNIUf6hu5F+kQ2oW4k=; b=bmjbhBFj5KP9jISQcE8tm/W3F7Q19e8shQkpG9o4wJT2MunZZ1RZM19rurpakkgFLe TuLOkhdduhlyQ9PQX8YgRVIoPf3ifOWDwf3iIyDJcvBpIfn52ee1OsObayrgZGN7KGEv ZJbQUnVgTX80M5vkOmr3VU9PF+Ow1ReXdwXdr+yM5fP2blxE4KPC85HIMJB/amMagH26 MqyjP0Oi26I6jysbcpni7nwHAM+G1BrK0TS5NJt8NofiCDHm937h0PPrsowl4Do0A+Rl GBho5QbyuKvxrfrf/CGURqv/OsDqXRUmTLdQHmvRxvjT+I/vhUE52cOxeBl3k5dl/Xjy 1XxA== X-Gm-Message-State: AHYfb5i2RqkbKV/bq8fMfeQ7tTyEQfT52ru28vklZrK5NwWVeXDfnNNo pMqYOJ1yn4IoyXpD/1LgVy7a5TRGThoGxqw= X-Google-Smtp-Source: ADKCNb5vmj9K13Gh38dKiEYX9J5ajoqWIJJwXDeKoOWjO9P0A7aMNmFEMkQk/rTkqs6YFHBN0tQfp1UZ7sa40doJQo8= X-Received: by 10.55.138.71 with SMTP id m68mr15175338qkd.137.1503690204853; Fri, 25 Aug 2017 12:43:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.209.26 with HTTP; Fri, 25 Aug 2017 12:43:24 -0700 (PDT) In-Reply-To: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Victor Vasiliev Date: Fri, 25 Aug 2017 12:43:24 -0700 Message-ID: Subject: Re: Congestion Control Questions To: Christian Huitema Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0767ee83ab0f0557992846" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Aug 2017 19:43:28 -0000 --94eb2c0767ee83ab0f0557992846 Content-Type: text/plain; charset="UTF-8" That has historically varied across TCP implementations. Linux TCP does congestion control in unit of packets, while FreeBSD one does it in unit of bytes. Google QUIC used to have both, but we eventually settled on bytes as it performed better in our experiments. Pacing rate appears to be almost always expressed in bits per second, so typically packets per second is converted to bytes per second using MSS as packet size for that purpose. On Fri, Aug 25, 2017 at 10:52 AM, Christian Huitema wrote: > I am looking at the recovery and congestion control draft, and I have a > couple of questions regarding congestion control. Congestion control > attempts to limit traffic to the capacity of the path, in order to avoid > building long queues. When the path is shared, congestion control also > aims at giving every participant a fair share. But there is a first > question: how do we express the capacity of the path? Is it packets per > second or bytes per second? > > Christian Huitema > > --94eb2c0767ee83ab0f0557992846 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That has historically varied across TCP implementations.= =C2=A0 Linux TCP does congestion control in unit of packets, while FreeBSD = one does it in unit of bytes.=C2=A0 Google QUIC used to have both, but we e= ventually settled on bytes as it performed better in our experiments.
<= br>
Pacing rate appears to be almost always expressed in bits per= second, so typically packets per second is converted to bytes per second u= sing MSS as packet size for that purpose.

On Fri, Aug 25, 2017 at 10:52 AM, Chris= tian Huitema <huitema@huitema.net> wrote:
I am looking at the recovery and congestion control draft= , and I have a
couple of questions regarding congestion control. Congestion control
attempts to limit traffic to the capacity of the path, in order to avoid building long queues. When the path is shared, congestion control also
aims at giving every participant a fair share. But there is a first
question: how do we express the capacity of the path? Is it packets per
second or bytes per second?

Christian Huitema


--94eb2c0767ee83ab0f0557992846-- From nobody Fri Aug 25 12:56:07 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BDC132C43 for ; Fri, 25 Aug 2017 12:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ypcVifMgj6Sc for ; Fri, 25 Aug 2017 12:56:04 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71331132C40 for ; Fri, 25 Aug 2017 12:56:04 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7PJr2qg012071; Fri, 25 Aug 2017 20:55:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=LjcbccL36d7phbxVHsYOSoKzoVQcS7mvbj62ANhN5/w=; b=YUS2OuAyTq/9xvFvtZZQpT9U4usmw86QwHS701h37lx+idUD8PJ4DET630y78tn+LABo 6JZO78LhQ4kCQIFtWC+2Mj0nzAprug3WodwA1nEMwDyBz5vdqAvs0D2wmg/QL38UyZ0v SHerw8V+zRsJfi69mqrlK16UU1F8/bqoo9Y5QUi8qWtXdecmDCYXoIgngqhHzQj2MNds 7QmJzS42d/typhhrslAiZG8NvOKRYBxKeG7ShFoGWYVmIS7CNrkH+5+kcP7KmfSAN1M2 n9r4V8zw239oD4D3phZsK1+ECuqEJc3dgTCvtc0ecb9ZU4zwMMvQZfhjrIXWNcfB8zfI Og== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2cj70gdk78-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 25 Aug 2017 20:55:27 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v7PJpKZV008505; Fri, 25 Aug 2017 15:55:26 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2cegnuwm2q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 25 Aug 2017 15:55:26 -0400 Received: from usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 25 Aug 2017 12:55:25 -0700 Received: from usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) by usma1ex-dag1mb6.msg.corp.akamai.com ([172.27.123.65]) with mapi id 15.00.1263.000; Fri, 25 Aug 2017 12:55:25 -0700 From: "Lubashev, Igor" To: Christian Huitema , "gorry@erg.abdn.ac.uk" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "quic@ietf.org" Subject: RE: Congestion control algorithm questions Thread-Topic: Congestion control algorithm questions Thread-Index: AQHTHJ0rmjoBO7j45UmR5fTvriIGE6KVCLgAgAArAACAAATYAIAAlzMA//+tcnA= Date: Fri, 25 Aug 2017 19:55:25 +0000 Message-ID: <689097676a46426f959069548d7b841a@usma1ex-dag1mb6.msg.corp.akamai.com> References: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> <599FE330.9010101@erg.abdn.ac.uk> <17aada09-9172-afaf-ac1e-0c6bcb6ada2e@huitema.net> In-Reply-To: <17aada09-9172-afaf-ac1e-0c6bcb6ada2e@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.39.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708250300 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-25_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708250300 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 25 Aug 2017 19:56:06 -0000 VGhlcmUgaXMgYSBjb25mbGljdCBiZXR3ZWVuICJQYWNrZXRzIHRoYXQgZG8gbm90IGNvbnRhaW4g cmV0cmFuc21pc3NpYmxlIGRhdGEsIHN1Y2ggYXMgcHVyZSBBQ0ssIHNob3VsZCBub3QgdHJpZ2dl ciBhY2tub3dsZWRnZW1lbnQiIGFuZCB0aGUgbmVlZCBmb3IgdHJpbW1pbmcgQUNLIGxpc3RzLiAg SW4gYSBkZWdlbmVyYXRlIGNhc2UsIHlvdSBjYW4gaGF2ZSAiaW1wb3J0YW50IiBwYWNrZXRzIGFy cml2aW5nIHdpdGggcGFja2V0IG51bWJlciBnYXBzLCBzbyB0aGUgcmVjZWl2ZXIgaXMgc2VuZGlu ZyBBQ0tzIHdpdGggYW4gZXZlciBncm93aW5nIG51bWJlciBvZiBnYXBzLiAgSG93ZXZlciwgc2lu Y2UgdGhlc2UgYXJlICJwdXJlIEFDSyIgcGFja2V0cywgdGhlIHNlbmRlciBkb2VzIG5vdCBBQ0sg dGhlbSwgcHJldmVudGluZyB0aGUgcmVjZWl2ZXIgZnJvbSB0cmltbWluZyB0aGVzZSBBQ0sgbGlz dHMuDQoNCi0gSWdvcg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBDaHJp c3RpYW4gSHVpdGVtYSBbbWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXRdIA0KU2VudDogRnJpZGF5 LCBBdWd1c3QgMjUsIDIwMTcgMTo0NSBQTQ0KVG86IGdvcnJ5QGVyZy5hYmRuLmFjLnVrOyBNaXJq YSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KQ2M6IHF1aWNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBDb25nZXN0aW9uIGNvbnRyb2wgYWxnb3JpdGhtIHF1ZXN0 aW9ucw0KDQoNCg0KT24gOC8yNS8yMDE3IDE6NDMgQU0sIEdvcnJ5IEZhaXJodXJzdCB3cm90ZToN Cj4gT24gMjUvMDgvMjAxNywgMDk6MjYsIE1pcmphIEvDvGhsZXdpbmQgd3JvdGU6DQo+PiBIaSBD aHJpc3RpYW4sDQo+Pg0KPj4ganVzdCBvbmUgbWlub3Igc2lkZSBjb21tZW50Og0KPj4NCj4+PiBB bSAyNS4wOC4yMDE3IHVtIDA3OjUyIHNjaHJpZWIgQ2hyaXN0aWFuIEh1aXRlbWE8aHVpdGVtYUBo dWl0ZW1hLm5ldD46DQo+Pj4NCj4+PiAxKSBBcmUgYWxsIHBhY2tldHMgY2FuZGlkYXRlIGZvciBy ZXRyYW5zbWlzc2lvbj8NCj4+PiDCoMKgwqDCoCBOby4gT25seSB0aG9zZSB0aGF0IGNvbnRhaW4g aW1wb3J0YW50IGRhdGUuwqAgVGhlcmUgaXMgbm8gbmVlZCANCj4+PiB0byBldmVuIGFja25vd2xl ZGdlIHRoZSBvdGhlciBwYWNrZXRzLg0KPj4gWW91IG5lZWQgdG8gYWNrbm93bGVkZ2UgYWxsIHBh Y2tldHMgYmVjYXVzZSB0aGUgbG9zcyByYXRlIGlzL21heSBiZSANCj4+IGlucHV0IGZvciBjb25n ZXN0aW9uIGNvbnRyb2wuDQo+Pg0KPj4gTWlyamENCj4+DQo+IEkgYWdyZWUgdGhlcmUgaXMgYSBu ZWVkIHRvIHJlcG9ydCAqYWxsKiAob3IgQUNLIHZpcnR1YWxseSBhbGwpIA0KPiByZWNlaXZlZCBz ZWdtZW50cyAtIHRoYXQgZG9lc24ndCBtZWFuIHRoZSBzZW5kZXIgaGFzIHRvIHJldHJhbnNtaXQg DQo+ICJsb3N0IiBzZWdtZW50cywgYnV0IGlzIG9uZSBpbXBvcnRhbnQgaW5wdXQgdG8gYSBjb25n ZXN0aW9uIGNvbnRyb2xsZXIgDQo+IHRoYXQgaXMgInNhZmUiwqAgZm9yIGRlcGxveW1lbnQgb3V0 c2lkZSBvZiBhIGNvbnRyb2xsZWQgZW52aXJvbm1lbnQuDQoNClllcywgTWlyamEgYW5kIEdvcnks IHlvdSBhcmUgYm90aCByaWdodC4gQWxsIHJlY2VpdmVkIHBhY2tldHMgc2hhbGwgYmUgcmVwb3J0 ZWQuIEJ1dCB0aGlzIGdvZXMgYmFjayB0byBNYXJ0aW4ncyBvcmlnaW5hbCBjcml0aWNpc20gb2Yg dGhlIHJlY292ZXJ5IGRyYWZ0LiBUaGUgcmVsaWFuY2Ugb24gcHNldWRvLWNvZGUgb2JzY3VyZXMg dGhlIHJlYXNvbmluZywgYW5kIG1heSBsZWF2ZSBhc2lkZSBpbXBvcnRhbnQgcXVlc3Rpb25zLiBT byBteSBvcmlnaW5hbCAzIHBvaW50IGxpc3Qgc2hvdWxkIGJlIGNvbnRpbnVlZCB3aXRoIGFub3Ro ZXIgdGhyZWUgcG9pbnRzIG5vdGVkIGJlbG93LiBXaGVuIGl0IGNvbWVzIHRvIGNvbmdlc3Rpb24g Y29udHJvbCwgdGhlcmUgaXMgYSBuZWVkIGZvciBhIHNpbWlsYXIgZWZmb3J0IG9mIGV4cGxhbmF0 aW9uIGFuZCBzaW1wbGlmaWNhdGlvbiwgYnV0IHRoYXQgc2hvdWxkIGNvbWUgbGF0ZXIuDQoNCsKg wqAgNCkgU2hvdWxkIGFsbCBwYWNrZXRzIGJlIGFja25vd2xlZGdlZD8NCg0KwqDCoCBZZXMuIEFs bCByZWNlaXZlZCBwYWNrZXQgbnVtYmVycyBuZWVkIHRvIGJlIHJlcG9ydGVkIGluIHRoZSBBQ0su IFRoaXMgaXMgaW1wb3J0YW50IGJvdGggZm9yIGNvbmdlc3Rpb24gY29udHJvbCwgc2luY2UgbG9z cyBvZiBhY2tub3dsZWRnZW1lbnRzIG1heSBpbmRpY2F0ZSBhIHByb2JsZW0gd2l0aCB0aGUgY29u bmVjdGlvbiwgYW5kIGZvciBBQ0sgdHJpbW1pbmcsIHdoaWNoIGlzIGRlc2NyaWJlZCBiZWxvdy4g VGhlcmUgaXMgYSBzdWJ0bGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBuZWVkIHRvIGJlIHJlcG9y dGVkIGFuZCB0aGUgbmVlZCB0byB0cmlnZ2VyIGFja25vd2xlZGdlbWVudHMuIFBhY2tldHMgdGhh dCBkbyBub3QgY29udGFpbiByZXRyYW5zbWlzc2libGUgZGF0YSwgc3VjaCBhcyBwdXJlIEFDSywg c2hvdWxkIG5vdCB0cmlnZ2VyIGFja25vd2xlZGdlbWVudC4gQWNrbm93bGVkZ2luZyBwdXJlIGFj a25vd2xlZGdlbWVudHMgd291bGQgdHJpZ2dlciBhbiAiQUNLIG9mIEFDSyIgcGluZyBwb25nIHN0 b3JtLCBhbmQgdGhhdCBtdXN0IGJlIGF2b2lkZWQuIFRoZSBwdXJlIEFDSyBwYWNrZXRzIHdpbGwg YmUgYWNrbm93bGVkZ2VkIHRoZSBuZXh0IHRpbWUgYW4gaW1wb3J0YW50IHBhY2tldCB0cmlnZ2Vy cyBhbiBhY2tub3dsZWRnZW1lbnQuDQoNCsKgwqAgNSkgV2hlbiBzaG91bGQgYWNrbm93bGVkZ2Vt ZW50cyBiZSBzZW50Pw0KDQrCoMKgIEFja25vd2xlZGdlbWVudHMgc2hvdWxkIGJlIHNlbnQgc2hv cnRseSBhZnRlciBpbXBvcnRhbnQgcGFja2V0cyBoYXZlIGJlZW4gcmVjZWl2ZWQuIFRoZXJlIGlz IHRlbnNpb24gYmV0d2VlbiBzZW5kaW5nIEFDSyB0b28gbGF0ZSwgd2hpY2ggd2lsbCBjb25mdXNl IHNlbmRlcnMsIGFuZCBzZW5kaW5nIEFDSyB0b28gZnJlcXVlbnRseSwgd2hpY2ggY2F1c2VzIGV4 Y2Vzc2l2ZSBuZXR3b3JrIGxvYWQuIERpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgVENQIGhh dmUgaW1wbGVtZW50ZWQgZGlmZmVyZW50IHN0cmF0ZWdpZXMsIHN1Y2ggYXMgZWl0aGVyIHNlbmRp bmcgQUNLIGFmdGVyIHJlY2VpdmluZyAyIGRhdGEgcGFja2V0cywgb3Igd2FpdGluZyBmb3IgYSBz aG9ydCBkZWxheSBhbmQgc2VuZGluZyBjb2FsZXNjZWQgQUNLIGZvciBhbGwgcGFja2V0cyByZWNl aXZlZCB1bnRpbCB0aGVuLiBJbiB0aGF0IGNhc2UsIHRoZSAiQUNLIGNvYWxlc2NpbmcgZGVsYXki DQpzaG91bGQgbm90IGJlIGxhcmdlciB0aGFuIGEgZnJhY3Rpb24gb2YgdGhlIFJUVCwgc3VjaCBh cyAxLzR0aCBvciAxLzEwdGgsIG9yIG1heWJlIDEgbWlsbGlzZWNvbmQgaWYgdGhlIFJUVCBpcyB2 ZXJ5IHNob3J0Lg0KDQrCoCA2KSBXaGVuIHNob3VsZCBhY2tub3dsZWRnZW1lbnQgbGlzdHMgYmUg dHJpbW1lZD8NCg0KwqDCoCBUaGUgQUNLIGluIFFVSUMgY29udGFpbnMgYSBsaXN0IG9mIGFja25v d2xlZGdlZCByYW5nZXMsIHNlcGFyYXRlZCBieSBob2xlcy4gVGhlIGhvbGVzIG5vcm1hbGx5IGNv cnJlc3BvbmQgdG8gcGFja2V0cyB0aGF0IGhhdmUgbm90IHlldCBiZWVuIHJlY2VpdmVkLCBhbmQg bWF5YmUgYWxzbyB0byBwYWNrZXRzIHRoYXQgaGF2ZSBhbHJlYWR5IGJlZW4gYWNrbm93bGVkZ2Vk Lg0KVGhpcyBpcyBzaW1pbGFyIHRvIHRoZSBTQUNLIG9wdGlvbiBpbiBUQ1AsIGJ1dCB3aXRoIGFu IGltcG9ydGFudCBkaWZmZXJlbmNlLiBJbiBUQ1AsIHRoZSBob2xlcyB3aWxsIGJlIGZpbGxlZCBl dmVudHVhbGx5IGJ5IHJldHJhbnNtaXNzaW9ucy4gSW4gUVVJQywgdGhpcyB3aWxsIG5vdCBoYXBw ZW4sIGJlY2F1c2UgYSBnaXZlbiBwYWNrZXQgbnVtYmVyIGlzIG9ubHkgdXNlZCBvbmNlLiBUaGUg bnVtYmVyIG9mIGhvbGVzIHdpbGwgdGh1cyBpbmNyZWFzZSBvdmVyIHRoZSBsaWZldGltZSBvZiBh IGNvbm5lY3Rpb24uIEluIHRoZSBhYnNlbmNlIG9mIGEgdHJpbW1pbmcgc3RyYXRlZ3ksIGEgbmFp dmUgaW1wbGVtZW50YXRpb24gd291bGQgdGh1cyBzZW5kIEFDSyB3aXRoIGV2ZXIgaW5jcmVhc2lu ZyBsaXN0cyBvZiBhY2tub3dsZWRnZWQgcmFuZ2VzLCBldmVudHVhbGx5IHJlYWNoaW5nIHRoZSBt YXhpbXVtIG51bWJlciBvZiByYW5nZXMgYWxsb3dlZCBieSB0aGUgcHJvdG9jb2wsIDI1NS4NCg0K wqDCoCBBbm90aGVyIGRpZmZlcmVuY2UgYmV0d2VlbiBRVUlDIGFuZCBUQ1AgaXMgdGhhdCBpbiBR VUlDIGFja25vd2xlZGdlbWVudCBjYW5ub3QgYmUgcmVuZWdlZC4gVGhpcyBtZWFucyB0aGF0IGFj a25vd2xlZGdlbWVudHMgbmVlZCBub3QgYmUgcmVwZWF0ZWQgaWYgdGhlIHJlY2VpdmVyIHdobyBz ZW5kcyB0aGUgQUNLIGtub3dzIHRoYXQgdGhlIG9yaWdpbmFsIHNlbmRlciBhbHJlYWR5IHJlY2Vp dmVkIHRoZSBpbmZvcm1hdGlvbi4gVGhpcyBrbm93bGVkZ2UgY2FuIGJlIGRlcml2ZWQgZnJvbSB0 aGUgIkFDSyBvZiBBQ0siLiBJZiB0aGUgcmVjZWl2ZXIgcmVjZWl2ZXMgYW4gQUNLIG9mIGl0cyBv d24gQUNLLCBpdCBrbm93cyB0aGF0IHRoZSByYW5nZXMgZGVzY3JpYmVkIGluIHRoYXQgQUNLIGhh dmUgYmVlbiBub3RlZCBhcyByZWNlaXZlZCBieSB0aGUgb3JpZ2luYWwgc2VuZGVyLiBUaGVyZSBp cyBubyBwb2ludCBpbiByZXBlYXRpbmcgdGhlbSwgYW5kIHRoZXkgc2hvdWxkIGJlIHRyaW1tZWQu DQoNCi0tDQpDaHJpc3RpYW4gSHVpdGVtYQ0KDQoNCg== From nobody Fri Aug 25 13:19:10 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964E2132C57 for ; Fri, 25 Aug 2017 13:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CifKY2uPrM-L for ; Fri, 25 Aug 2017 13:19:07 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92EB2132C4B for ; Fri, 25 Aug 2017 13:19:07 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx1.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1dlL4K-00083M-Sy for quic@ietf.org; Fri, 25 Aug 2017 22:19:05 +0200 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dlL4H-0001ke-9Q for quic@ietf.org; Fri, 25 Aug 2017 16:19:03 -0400 Received: (qmail 3586 invoked from network); 25 Aug 2017 20:18:59 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 20:18:58 -0000 To: quic@ietf.org References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <54b8b1e8-6f56-d049-e25e-68986abd21d4@zinks.de> From: Christian Huitema Message-ID: <8d8203ef-cbe0-357c-129a-bd90c4c11025@huitema.net> Date: Fri, 25 Aug 2017 13:18:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <54b8b1e8-6f56-d049-e25e-68986abd21d4@zinks.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Congestion Control Questions X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.19) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23naGEyVAbe4zpyh6oycJt6gtO4TK/N007CJb7 HK21qZP+a5lsN94OPthJhcFmTS1NYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyXR9zj1AkVzfqLztcCbEg07eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237p0djsrZ/k7aFJneAV66i3WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6sJqelmxqtloshGkSoDyZkT9+DGUWcLTBDsB1igut165p7U6tnoWn4rvJ vZ3bbxFpLgnyX8sS8V14hKmGdBhsM3BZ7pmcPPET1gsbqYqsHO2B1AyhUYt13ZFWiMbSDOe6Tsut 9Ntwqm/jmjsUXZwk2AT7Y9cRih4Det7+7EbH8nOrv5Mi7W1Fe3H2lzs3Ph6Br8hUVhe7ugL65f2h l2QLng== 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, 25 Aug 2017 20:19:09 -0000 On 8/25/2017 12:04 PM, Roland Zink wrote: > With TCP the congestion control happened in the kernel outside the > reach of most programmers. Now with QUIC you give it to app > programmers. Will they use a fair algorithm or will they try to > "optimize" it for their app? What can be done if somebody use a not so > fair scheme? Well, application programmers do have an incentive to not create congestion, because congestion causes losses and delays that degrades the application's performance. But I agree with you, they do not have an incentive to ensure fair sharing. With current in kernel TCP implementations, application programmers can play games by opening multiple connections. With an in-process transport like QUIC, they can achieve the same result by tweaking the parameters of the congestion control algorithm. For example, if QUIC recommends New Reno, they can tweak the increase and decrease coefficients to simulate N connections, and thus get N times their "fair share". At one point, Google QUIC did in fact have a congestion control option to set this "number of simulated connections". The rationale was that they competed with browsers that would open two connections to a given site, so they might just as well simulate two connections. The end game is probably generalized implementations of AQM algorithms in network routers. If the routers implement some variation of fair queuing, it does not matter whether the congestion control implementation strives for fairness or not. That will give a serious incentive to the application to use the congestion control algorithms that best suits their need, which is normally a balance between minimize delays, minimizes losses or maximize throughput. Different applications may well pick different points in that curve. There is of course a ton of research on possible algorithms. But for now, the WG has a simple mandate: specify a congestion control algorithm similar to TCP's New Reno. > > > Packets can be short or long, so usually the link capacity is given in > bytes per second or bits per second. Yes, but there is per packet overhead. Sending 1000 packets with a one byte payload is not the same as sending 1 packet with a 1000 bytes payloa= d. Also, the original New Reno specification was pretty much expressed in terms of packets. For example, in congestion avoidance mode it increases the TCP congestion window by one packet length per round trip. > > > Am 25.08.2017 um 19:52 schrieb Christian Huitema: >> I am looking at the recovery and congestion control draft, and I have = a >> couple of questions regarding congestion control. Congestion control >> attempts to limit traffic to the capacity of the path, in order to avo= id >> building long queues. When the path is shared, congestion control also= >> aims at giving every participant a fair share. But there is a first >> question: how do we express the capacity of the path? Is it packets pe= r >> second or bytes per second? I assume that this will be bytes per second, but I question the decision in the draft to not include the length of ACK in the total. That seems arbitrary. Why exempting ACK and not exempting MAXDATA, for example? It is certainly possible in some network configurations to saturate a low speed uplink by sending too many ACKs for data received through a high speed downlink. Since all packets are acknowledged, summing the length of all packets in flight is much easier than keeping track of what exactly was inside the packets. --=20 Christian Huitema From nobody Fri Aug 25 16:10:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732AD13235C for ; Fri, 25 Aug 2017 16:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMPC1KTAgvvR for ; Fri, 25 Aug 2017 16:10:26 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F04211321BF for ; Fri, 25 Aug 2017 16:10:25 -0700 (PDT) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dlNk7-00046P-Em for quic@ietf.org; Sat, 26 Aug 2017 01:10:24 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dlNk4-0002WR-9l for quic@ietf.org; Fri, 25 Aug 2017 19:10:21 -0400 Received: (qmail 8169 invoked from network); 25 Aug 2017 23:10:18 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 23:10:18 -0000 To: "Lubashev, Igor" , "gorry@erg.abdn.ac.uk" , =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: "quic@ietf.org" References: <140fc0c6-c837-6ab5-cf01-4992994bcfe6@huitema.net> <8F1C9A80-6748-4C69-A80B-F75DEF9EA470@tik.ee.ethz.ch> <599FE330.9010101@erg.abdn.ac.uk> <17aada09-9172-afaf-ac1e-0c6bcb6ada2e@huitema.net> <689097676a46426f959069548d7b841a@usma1ex-dag1mb6.msg.corp.akamai.com> From: Christian Huitema Message-ID: Date: Fri, 25 Aug 2017 16:10:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <689097676a46426f959069548d7b841a@usma1ex-dag1mb6.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Congestion control algorithm questions X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.12) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbFuHJrd6q7ImwszS9kW0E9ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23B87vo0Hv6gLzTRvW2JPnfunAK+xr92ZGK1ua sQ+8DmhGSHfT07utmKWn+J8D/SUmYOEkjsX7F8KmpUaZQHV+Sf+k51CV8HOoCp+bWB2rXxO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpGhWDl86FRLsucalajANCRP6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyQkgRDiy8QPcQDODQQIGrdfeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj237p0djsrZ/k7aFJneAV66i3WezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6sJqelmxqtloshGkSoDyZkT9+DGUWcLTBDsB1igut165p7U6tnoWn4rvJ vZ3bbxFp3KyR40nbeMvs3kY9T/KSuXBZ7pmcPPET1gsbqYqsHO2B1AyhUYt13ZFWiMbSDOe6Tsut 9Ntwqm/jmjsUXZwk2AT7Y9cRih4Det7+7EbH8nOrv5Mi7W1Fe3H2lzs3Ph6Br8hUVhe7ugL65f2h l2QLng== 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, 25 Aug 2017 23:10:27 -0000 On 8/25/2017 12:55 PM, Lubashev, Igor wrote: > There is a conflict between "Packets that do not contain retransmissibl= e data, such as pure ACK, should not trigger acknowledgement" and the nee= d for trimming ACK lists. In a degenerate case, you can have "important"= packets arriving with packet number gaps, so the receiver is sending ACK= s with an ever growing number of gaps. However, since these are "pure AC= K" packets, the sender does not ACK them, preventing the receiver from tr= imming these ACK lists. Good point. But the sender of the ACK can easily elicit a response. I got from Jana that=C2=A0 "After sending 20 pure acks, recent gQUIC versio= ns send a flow control update. This is specified in the draft. This flow control update automatically triggers an ack in the opposite direction, avoiding the need at the receiver of acks to do anything special." Receivers could also send a Ping when the ACK list has grown too long. Either way, they will receive an ACK and they will be able to trim the ACK list. --=20 Christian Huitema From nobody Fri Aug 25 16:38:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1C8B132936 for ; Fri, 25 Aug 2017 16:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ta4u-C_Xoys for ; Fri, 25 Aug 2017 16:38:44 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ADC0132926 for ; Fri, 25 Aug 2017 16:38:44 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dlOBW-0002b3-5h for quic@ietf.org; Sat, 26 Aug 2017 01:38:42 +0200 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dlOBT-00081C-N4 for quic@ietf.org; Fri, 25 Aug 2017 19:38:40 -0400 Received: (qmail 6502 invoked from network); 25 Aug 2017 23:38:37 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Aug 2017 23:38:37 -0000 To: quic@ietf.org References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Christian Huitema Message-ID: Date: Fri, 25 Aug 2017 16:38:36 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Congestion Control Questions X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.27) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJY8hyefn/FOeAH6Zsqubs62ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23RdhU27IuNnOIugRGBOIVcu19b50okW22yP22 bTG8N1hSDKHIhMgL/D00Ju9DvQuNYOEkjsX7F8KmpUaZQHV+SWsC1ltxhvDAAiytf1zpGXO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKOHi0RYvlOYvJoUtCbvS/b6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZpD/g5+4+08bhXiqWVVMe/eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj235oFHEvdNKvU25hFWuKqavINdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxqOpKDLgXbN4hqziyI3RnXo078I0y+3uS4dN KiUgYTBUPKHDFDedHe2UqJa8r6BmbYAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/RufmJqHIgpwQblHGid2pC00i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 23:38:46 -0000 On 8/25/2017 12:43 PM, Victor Vasiliev wrote: > That has historically varied across TCP implementations.=C2=A0 Linux TC= P > does congestion control in unit of packets, while FreeBSD one does it > in unit of bytes.=C2=A0 Google QUIC used to have both, but we eventuall= y > settled on bytes as it performed better in our experiments. > > Pacing rate appears to be almost always expressed in bits per second, > so typically packets per second is converted to bytes per second using > MSS as packet size for that purpose. OK, I suppose we can go with that in the recovery draft, since that does match most TCP implementations. But reading the draft again, I have another question, concerning "recovery". The current recovery draft says that "Recovery is a period of time beginning with detection of a lost packet. It ends when all packets outstanding at the time recovery began have been acknowledged or lost."That's OK, it can be implemented. But that's different from the actual New Reno spec. In New Reno, implementations enter discovery when a packet is lost, and exit discovery when the packet is finally successfully retransmitted and acknowledged. But there is no such thing as packet retransmission in QUIC. When a packet is lost, the corresponding frames may or may not be retransmitted. So the text in the recovery draft finesses that, by requesting that the entire flight be "acknowledged or lost", but not actually retransmitted. Which goes back to the reliance on pseudo code. It would be nice if there was text explaining how the QUIC algorithm differs from New Reno, and why. --=20 Christian Huitema From nobody Sun Aug 27 19:55:53 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363661323FD for ; Sun, 27 Aug 2017 19:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPBMW4Gjzxn2 for ; Sun, 27 Aug 2017 19:55:49 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9487D1321A0 for ; Sun, 27 Aug 2017 19:55:49 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id 77so21074963itj.0 for ; Sun, 27 Aug 2017 19:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ldIKXwAfuzejnINIW3VIlNbuh67xMH/NjFRahnj1rQU=; b=HSvHl+QF+7uV4AL7zAvCV8es3KaQYupJUEurXZnUK+DlX0gdXWF0Exq4kZUoBLXXxK HSeCseBXI5IQQS2TTU3QVPfqHY2vXMV1Zqpm5VTLkTaD1kMT8rClwo8YU2Jc4Ae/W4Q5 //0eL2iLouVXdimws9zU8dZai4WFwD04IAlpYMi0e8phHlUMDocwXDISXVN32ZKLv2aq MCyxuXS3/Y8AGnfbWveK513RrXpQIwHADheyeqMfBW/7etRVYVKbUdZveGdlPL9EAfoC vgdlV5ygbb2iXQqrrqvq6s7DK5VpWSWgPrwrqDzUIHwdiYl05S0Tq+MbFRXlgEPG+593 RqBg== 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=ldIKXwAfuzejnINIW3VIlNbuh67xMH/NjFRahnj1rQU=; b=nVReTumd4Z8tbUuGQvLzBXDaBmx+TrO0W0Vfxv+pZ78GSpgTjoDhZ/Z7mufDTo4xzX 5uRqcS7ny8bv22g7O0X9i3JvfO7C607mWOGsYmIMt9ItBWT6A3K0gbbw2LOK9XNdi3AX PKGQOxx5A1HuJkQN/ljrW++mOSuVoO3fa9G4DyzAgmzs1jtcfXtr8ppB8Hzu1qu0lxK8 q7Ypc8KpriihdNWjEjUCp2FjscMXD/A9GlgyKEVLR8SRwUZY3vpc40YZjtQLzSeABuIz 11vLFO8/Si9++GGShnZoSYB20flrbooc9HjhB1TZPi7NzO780Od54OQwduoRTvCMQt3z 0OFg== X-Gm-Message-State: AHYfb5jpdszopXtJg401WN94R4tthrmrRrRUtnOGLdS1EiTrIGlXMGH5 dBEQx3cA1Ag4nXNeqbGVE4XDwCGV76VE X-Received: by 10.36.110.149 with SMTP id w143mr4763025itc.21.1503888948947; Sun, 27 Aug 2017 19:55:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Sun, 27 Aug 2017 19:55:47 -0700 (PDT) In-Reply-To: <20170825132458.GB17110@ubuntu-dmitri> References: <20170823205057.GA8231@ubuntu-dmitri> <20170824131556.GA11713@ubuntu-dmitri> <20170825132458.GB17110@ubuntu-dmitri> From: Martin Thomson Date: Mon, 28 Aug 2017 12:55:47 +1000 Message-ID: Subject: Re: Why is MAX_DATA in units of 1024 octets? To: Dmitri Tikhonov Cc: Ian Swett , 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: Mon, 28 Aug 2017 02:55:51 -0000 On 25 August 2017 at 23:24, Dmitri Tikhonov wrote: > On Fri, Aug 25, 2017 at 08:26:48AM +1000, Martin Thomson wrote: >> Most of the integers we have need to be encoded. That naturally leads >> to multiples of 8 bits. That's the first reason for having the >> numbers as they are. > > That's not what I wrote. Yes, but I'm disagreeing with you. From nobody Mon Aug 28 06:27:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7556E132803 for ; Mon, 28 Aug 2017 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAuPWJhmtWL0 for ; Mon, 28 Aug 2017 06:27:31 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22810124B18 for ; Mon, 28 Aug 2017 06:27:31 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id w42so2008861qtg.5 for ; Mon, 28 Aug 2017 06:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=JCpWYJ5rkB+CH0FiO/5HTeO0+UGJgbT0//jQSza0sOk=; b=nP2RfyPrzXAs7rSu2fDrvHSCYXAD3U0LGkpgI2N49z/5LY0P9d/aFbvpoKo2CKD0mc gDLro6A4Y6Xw8SCphXeiywoP0auWR4C+ANpt0K11hNkuDzLqNSJiIyhYASH7QBO8d5VX R4zLkOvt/mqT51R059BR2uxov7U9cgpCG/FuVVh37rfcDEmcB+nGhTV1XL/7sUG3Qbng IwmTfk6142i5P8ilJ/YZb52ImaNLzIrULtGzKFUwZDH8i1C+V9SiT0cpFOtrwBr18ihb 1QrIDxqnAHL1zu/Bbq/YrfAScjms/JHtcisLtARnVpJsPNmzIGKUyRC+Qivc0FHFsvge uOCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=JCpWYJ5rkB+CH0FiO/5HTeO0+UGJgbT0//jQSza0sOk=; b=O7X0NOC5k6jk9PEA3DUMYeCWEhPOr1Q8L+4VqawrdFxWCoYHqYbDJ7B5/1fJn673f3 c9alwQ1qWEhyg5H93Q5f3F4IUzW4lgW488xDwAb0uUzJHDEiU2oyJ1k6k+at4AOtw7Ln a4Gh9teEoJ63rG9kb6F0PdmUmOACpHfHp5dcUyaKk92sJG5hr2tRSU1g2G+FGjdus/nJ rCzdzY3ekNsAcKpTXktfSe+A5Kqq3EfHiNT/OtT+NY/WkPe3jOL3UwtlAmXCM9BmLO3+ gPIVtAJCatUlQsAM+LTLT5Myg5jmQQSiz4BTrG+q6/g7H74c2I5EmIfOokAUIK8QlzK/ Jrzg== X-Gm-Message-State: AHYfb5gDJm9+rzgJaH1zOIK2+eh2648E9kdA4UNhUJ9GmAtAGT/AHmSt chwprAYNw8tMq9s4 X-Received: by 10.200.46.170 with SMTP id h39mr852313qta.170.1503926850187; Mon, 28 Aug 2017 06:27:30 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id p64sm224605qkd.94.2017.08.28.06.27.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 28 Aug 2017 06:27:29 -0700 (PDT) Date: Mon, 28 Aug 2017 09:27:17 -0400 From: Dmitri Tikhonov To: Martin Thomson Cc: Ian Swett , IETF QUIC WG Subject: Re: Why is MAX_DATA in units of 1024 octets? Message-ID: <20170828132716.GA22394@ubuntu-dmitri> References: <20170823205057.GA8231@ubuntu-dmitri> <20170824131556.GA11713@ubuntu-dmitri> <20170825132458.GB17110@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: Mon, 28 Aug 2017 13:27:35 -0000 On Mon, Aug 28, 2017 at 12:55:47PM +1000, Martin Thomson wrote: > On 25 August 2017 at 23:24, Dmitri Tikhonov wrote: > > On Fri, Aug 25, 2017 at 08:26:48AM +1000, Martin Thomson wrote: > >> Most of the integers we have need to be encoded. That naturally leads > >> to multiples of 8 bits. That's the first reason for having the > >> numbers as they are. > > > > That's not what I wrote. > > Yes, but I'm disagreeing with you. OK, I should have written "that's not what I meant," for encoding itself is not the issue. (In regards to encoding, however, I do not see how the need to encode integers "naturally leads to multiples of 8 bits." It is convenient to have an *encoded representation* be a multiple of 8 bits, not the value itself.) The [draft-ietf-quic-transport] document states that it "describes the core QUIC protocol, including the conceptual design." I think the limitations associated with the packet numbers and byte offsets should be explained. The questions are: 1. Why are there packet number and byte offset limits? In other words, why are there limits on the duration of a connection? (That's the "conceptual design" part). 2. How are particular limits chosen? Since QUIC is a transport protocol, it will be compared to TCP. The draft does that in several places, and QUIC invariably ends up being better than TCP. Yet TCP does not place a limit on the amount of data that can be sent over a single connection. - Dmitri. From nobody Mon Aug 28 06:41:31 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6618132936 for ; Mon, 28 Aug 2017 06:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JF0ZISmpsrIT for ; Mon, 28 Aug 2017 06:41:28 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C94132932 for ; Mon, 28 Aug 2017 06:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ok0QzbGA//DbWqdNzz+w+vHyukZ0rAbZ5AvFSyJAVxg=; b=EG5nP2wbqUcmdJKHaNfHFHjwDb5sbUXjnckrET3SjtEVG0/yn/6V1k+kLb4yg5QpW50JTErLAnscp0MJygAqABtQBWzwN+WIJtJMvEWyKShUzHyrPTZwC99xRWi6OoLgDUTnb4O+bKUiMTp0ST7velyJndYrh4mjiAd3UZLEf24= Received: from DB5PR07MB1237.eurprd07.prod.outlook.com (10.164.41.139) by DB5PR07MB0934.eurprd07.prod.outlook.com (10.161.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 13:41:25 +0000 Received: from DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::a018:f768:ce8d:8996]) by DB5PR07MB1237.eurprd07.prod.outlook.com ([fe80::a018:f768:ce8d:8996%13]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 13:41:25 +0000 From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" To: Christian Huitema , "quic@ietf.org" Subject: RE: Congestion Control Questions Thread-Topic: Congestion Control Questions Thread-Index: AQHTHcsJ9s2B0yvSYEKjKsDMEaQiFqKVeT0AgABBtwCABA35YA== Date: Mon, 28 Aug 2017 13:41:25 +0000 Message-ID: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.69.101.84] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB5PR07MB0934; 6:fEmhNewQ7LBuMn2MbzTaAD+ZuU0DhHRprX0vAaQSxON7THE5JIjA/XyK7fmHa4Uo1imziERXzSCUYCxOfyGLoqAXJ6IDgbLobxnf7usfK46R4WMB+w2vEqmLvsE7ypHTJAx1oCMtRlDt6Oa64bJoLMiFLdQA93jExIWxHy6g/vmj9flXjJj5rToMewNsW2Vox7+aEVbq++475j8YV3EcZDqE81UT7M4dteSNp/u94fD2MIOSlJ3K8uXxY3tVsgU1nKIavCWLGdll01VulGXU77GUbbvEf5rmAp/8ux1KZhXfPC4iBkjQnjkpT7ga8zBYp7Od9kZljF69eZYXsrsZ3Q==; 5:U+0cJBTO+jHD2cRCK59d+e/oX3V34NvKygbh4bZ9GX7gE3F6KtwoJNww4zmisepEn05DZ9olf5ZZac83EQCIdvHnY9g3VShkPMF3CpRVJDmOLoCm+ldSypr8/LqeRUKAFdkoqz8ka+Mmy+2TVv9nWA==; 24:27H4M9JbHyN+lmQLfrae/3Brcw78U3KPrmD7JWqksSFbKR/gnzcGDZjVhTidEm6lqcT4Liw0l2Gw0v6789WlcL25liV4gv2nQnqw64u0kGU=; 7:Xw5DGtd7oDz1Z/irdscouMl9aD4Pras0avhvWhqjHVXAZa2i6tYcrspvbavDlK5+O/mkMPjMzxRFeAGZrSwU6LhpdMaoZYHE4M32rjbvqLtSMh2JYIm9tVdtnaa5aakx69xlZgRIMgbbeagZB5HpwdI4g3yZJJnitPxbczXY6IrVgLDSp4yuTDQVLT7XteSllx2ElUJz4hoooYxihYaLqq/zPlipQRLX2UNgkdErzYI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 8f14eaba-2449-410b-7985-08d4ee1a7a45 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB5PR07MB0934; x-ms-traffictypediagnostic: DB5PR07MB0934: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.swindells@nokia.com; x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR07MB0934; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR07MB0934; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(106356001)(6116002)(2950100002)(105586002)(3846002)(6246003)(9686003)(99286003)(7696004)(53936002)(7736002)(14454004)(101416001)(305945005)(102836003)(74316002)(3480700004)(66066001)(189998001)(86362001)(8936002)(8676002)(81156014)(2906002)(5660300001)(81166006)(3280700002)(50986999)(68736007)(5250100002)(25786009)(2900100001)(2501003)(3660700001)(33656002)(55016002)(229853002)(6506006)(478600001)(6436002)(97736004)(7116003)(54356999)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:DB5PR07MB0934; H:DB5PR07MB1237.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 13:41:25.2453 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR07MB0934 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 28 Aug 2017 13:41:30 -0000 PiBXaGljaCBnb2VzIGJhY2sgdG8gdGhlIHJlbGlhbmNlIG9uIHBzZXVkbyBjb2RlLiBJdCB3b3Vs ZCBiZSBuaWNlIGlmIHRoZXJlIHdhcw0KPiB0ZXh0IGV4cGxhaW5pbmcgaG93IHRoZSBRVUlDIGFs Z29yaXRobSBkaWZmZXJzIGZyb20gTmV3IFJlbm8sIGFuZCB3aHkuDQoNCkkgdGhpbmsgdGhpcyBz dGF0ZW1lbnQgYWN0dWFsbHkgZ2V0cyB0byB0aGUgcm91dGUgb2YgdGhlIHByb2JsZW0uIA0KTXkg dW5kZXJzdGFuZGluZyAocHJlc3VtcHRpb24pIGlzIHRoYXQgYSBRdWljIGltcGxlbWVudGF0aW9u IGRvZXNuJ3QgaGF2ZSB0byB1c2UgTmV3IFJlbm8gb3IgYW55IHBhcnRpY3VsYXIgYWxnb3JpdGht IC0gYW4gaW1wbGVtZW50YXRpb24gY291bGQgdXNlIEJCUiBmb3IgaW5zdGFuY2UgaWYgaXQgd2Fu dHMuIEhvd2V2ZXIgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHJlcXVpcmVtZW50cyB0aGF0IGFueSBh bGdvcml0aG0gbXVzdCBtZWV0IHRvIGJlIGEgY29uZm9ybWluZyBxdWljIGltcGxlbWVudGF0aW9u IC0geW91ciBwcmV2aW91cyBleGNlbGxlbnQgbGlzdCBvZiBzdGF0ZW1lbnRzL2V4cGxhbmF0aW9u cyBzdW1tZWQgdXAgbWFueSBvZiB0aGVzZSAoU2hvdWxkIGFsbCBwYWNrZXRzIGJlIGFja25vd2xl ZGdlZCwgZXRjKS4gQ3VycmVudGx5IGhvd2V2ZXIgdGhlIHNwZWMgaW50ZXJ3ZWF2ZXMgdGhlIGdl bmVyaWMgcmVxdWlyZW1lbnRzIHdpdGggcHNldWRvIGNvZGUgZm9yIGEgcGFydGljdWxhciBpbXBs ZW1lbnRhdGlvbiBzdWdnZXN0aW9uLiBJdCBtYXkgd2VsbCBiZSB3b3J0aCBoYXZpbmcgYSBzdWdn ZXN0ZWQgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29yaXRobSwgYnV0IHRoaXMgc2hvdWxkIHByb2Jh Ymx5IGJlIHNlcGFyYXRlZCBpbnRvIGFuIGFwcGVuZGl4L3NlcGFyYXRlIHNlY3Rpb24gd2l0aCB0 aGUgZnVuZGFtZW50YWwgYmVoYXZpb3VycyBhbmQgcmVxdWlyZW1lbnRzIGNsZWFybHkgZGVmaW5l ZCBmaXJzdC4NCg0KVGhvbWFzDQo= From nobody Mon Aug 28 06:45:02 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D3132936; Mon, 28 Aug 2017 06:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aNZ_kyOitPD; Mon, 28 Aug 2017 06:44:47 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03B713292B; Mon, 28 Aug 2017 06:44:46 -0700 (PDT) X-AuditID: c1b4fb3a-5ffff700000051a3-73-59a41e4c21e5 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 81.9F.20899.C4E14A95; Mon, 28 Aug 2017 15:44:44 +0200 (CEST) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 28 Aug 2017 15:44:43 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KXxxXt0zw5cZbXqsAtX4WAHDOzXCoOSn2u3FU+OOANk=; b=JdSXr+D4oHVNMkVHOyha3T3raP9CTRewbgSBATlKxoWkylpgjPmfSHCZtGEgVlE336E3gZ8Z4Ue8o1K9DW5Ln9lVWeda/2flZwZCRdsHkTQ4z4aV2fvKAVkWTuyVj0dp93x+nXfhqEMMLoMczkr0Hbf4T3uCI+9XG8BxsCYRmy4= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB110.eurprd07.prod.outlook.com (10.242.138.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 13:44:43 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::787a:c6a2:f24c:1326]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::787a:c6a2:f24c:1326%16]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 13:44:43 +0000 From: Ingemar Johansson S To: "rmcat WG (rmcat@ietf.org)" , tsvwg IETF list CC: QUIC IETF mailing list Subject: SCReAM congestion control with ECN support Thread-Topic: SCReAM congestion control with ECN support Thread-Index: AdMgA7+OopcqECc5TgW2pH9Wr69HXQ== Date: Mon, 28 Aug 2017 13:44:42 +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.87] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB110; 6:+O3UZqBG7H1LqKDsJCsa9EKkrmrywTAnF+V7LhQL7VOIh/NY+UTYqV4LUybEkkpjjtke/LVKjsnsiK54QgXCI68iDyqh+iBhhbAaLhQ9CGNV5CJwP0hvw8W+YnQ5FoPVZT6G1K90Z3uzApvKrcYBjSByYANdxbV6zeN0yZPcPugp7Jt+soSQiV9QSe25QiQ6HBTYZsol7px1bA3pq3tPkFaIWLIev9Brtu54DhB5bebL7izI4VyxBcC1/GghzhQmMoMuqBPLayVkiWdQ7+ycZ+pTFx5srKN88CZLDxZyzN4oy1gY9EQnHfa7VfDkkaWIlTN9tZerTOwJBrnO0dJFSw==; 5:hbx0hIQT8tRh8f93SWh8yLZDj2x8YxB0XUNUGJ9rfAdYBPniXgZw4BoHCj5xgs3DVfwuqj7CwoYc9t/Ka60liAusammIcuuM9d+uAaG4pOOCNLcz+KI6PXqSrdbkHsNf1Y3VC6wcJVRWO+n88cewiw==; 24:qAD+Rz8DxjSWTNBW/6T/A15XxOs1ujAWmTXuHl+mLwt9k2auqJtx8aBreBM4Im0LUYfDvhcWkzYyO1+r6Y1h9LoGpyLz2LkXZifYEiUKzZ8=; 7:Jp8zt2jkIcvDCklxpT9bcuH07aLB4C8rJK9FazuDXIIMCzSPn6hVAbcKjOr1j8RgHveu0Xp7uczJo5P6quWsNpzi+FdF9GaWZFZdHms+41/iGa/fiKWQliE+eYIgq+axANnXE0kmWtjOlrHisia1fl0qy5USU0/5s0V+6gj0uZsK89O9xD4HTD+J93PfCjByjK2hiaZQvza62asmWWD6PnINM88Qofsi73zOpTtoJR4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f893e510-ac98-4a85-5228-08d4ee1af015 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DBXPR07MB110; x-ms-traffictypediagnostic: DBXPR07MB110: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(21748063052155)(192278398808882); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB110; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB110; x-forefront-prvs: 0413C9F1ED x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(189002)(199003)(606006)(6506006)(101416001)(99286003)(66066001)(55016002)(236005)(74316002)(54896002)(6306002)(9686003)(7696004)(33656002)(5660300001)(14454004)(8676002)(966005)(450100002)(68736007)(50986999)(81166006)(81156014)(6436002)(5250100002)(189998001)(54356999)(790700001)(6116002)(4326008)(102836003)(3846002)(25786009)(2900100001)(3660700001)(3280700002)(97736004)(86362001)(9326002)(2906002)(19609705001)(478600001)(7736002)(53936002)(106356001)(105586002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB110; H:DBXPR07MB351.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=ingemar.s.johansson@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 13:44:42.9165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB110 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SaUhUYRSG++YuXicHrpPLadKoAaHGZiyNEhMzCvKHkWSECqKD3lRya65Z GpIpGk7uKKb9UHHQtCzMpUky9eZStDhJmUpZrkMuaJqISZozn4H/nvO+53AWDkNIqykZExWb wGli1dFyWkyWBjxTKn336gIPT40ed8+u2On+cGiBdu+Z/UZ7Ez463arIDwWJPcO56KhETuPi FSqOzDKmxE+cuDGRVkqnIv0xLbJkgD0Kk39GSRNL2S4Et5citUi8ya8RGHJbCFNAsjkELBnb aOwUiWAqp4fEwSiCupI2ZKqnWU+oFVbMbMNehPaVdEqLGIZgFZBXy5vkXawb/P7USuMUd1ib HbfArILut43mUpJ1gqbCO2ZdwgZBR9uUeTzEOsL3lREzE6w9DE+Ui/AKLOhe9BGYbeHn+Lq5 LbD7QPd3N5Ydob/8LjKNDGyGBWyUtyBsqKC5YG6Lz0H+aj+Bk0ZFkL+wTGHjIDzuyNtqlgLd T2ZJzFHwq8FA4oKPFNQWZ9G4swO8T4vAehUFmfMNCB+Yg5r6DIS3CYPFoRwqHynKti2EOQ4M fSNUmfkA1vCmdILEugoGi4tozM5QXTlDYFbCvXWB3K5XIIs6ZMtzPB8T4eqq4jRRYTwfF6uK 5RKeos3v6Wxa89CjTuMpAbEMkltJJqeqAqWUOpFPihEQMITcRjLsoAuUSsLVScmcJi5Ecy2a 4wW0hyHl9hLvl4YAKRuhTuCucFw8p/nvihhLWSo6EzLQ5xN8aEOqr//iZNjhnD6QXNjTa938 uetDgN43+Ourm71XBZmiwFkz3VzUHv1u+oKQfSk+l7D1ryxRaJWPLKYn7dIrZ4xzpzNrMhKX 57MOuDwYPp+wPGZoPNlaRY15CNcX7Z+nBBp+yNr23zobLnjajRUOull5+bv4NVwOvS8n+Uj1 EQWh4dX/AGGbLa45AwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 28 Aug 2017 13:44:55 -0000 --_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Just in case that there are still people around who question the benefits w= ith ECN. The SCReAM congestion control code has now been updated to support ECN. You= can find more info + some rudimentary videos from a real test at https://github.com/EricssonResearch/scream#ecn-explicit-congestion-notifica= tion Something QUIC related. Implementing ECN support in Linux is very straightf= orward. Look for instance in https://gist.github.com/jirihnidek/95c369996a8= 1be1b854e for the details. /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com A mistake is to commit a misunderstanding Bob Dylan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Just in case that there are still people around who = question the benefits with ECN.

 

The SCReAM congestion control code has now been upda= ted to support ECN. You can find more info + some rudimentary videos fr= om a real test at

https://github.com/EricssonResearch= /scream#ecn-explicit-congestion-notification

 

Something QUIC related. Implementing ECN support in = Linux is very straightforward. Look for instance in https:/= /gist.github.com/jirihnidek/95c369996a81be1b854e for the details.

 

/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<= /o:p>

 

Ericsson AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

A mistake is to commit a misunderstanding
       =             &nb= sp; Bob Dylan
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

 

--_000_DBXPR07MB351EFC36B64990A8FE5A860C29E0DBXPR07MB351eurprd_-- From nobody Mon Aug 28 10:02:43 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0A71326EA for ; Mon, 28 Aug 2017 10:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwYE8zkcqzr9 for ; Mon, 28 Aug 2017 10:02:40 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 04F5213234B for ; Mon, 28 Aug 2017 10:02:40 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:79bd:af46:1240:1202]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id B7B651B0021A; Mon, 28 Aug 2017 18:02:37 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk Subject: Re: Congestion Control Questions To: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Christian Huitema , "quic@ietf.org" References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Mon, 28 Aug 2017 18:02:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:02:42 -0000 On 28/08/2017 14:41, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: >> Which goes back to the reliance on pseudo code. It would be nice if there was >> text explaining how the QUIC algorithm differs from New Reno, and why. > > I think this statement actually gets to the route of the problem. > My understanding (presumption) is that a Quic implementation doesn't have to use New Reno or any particular algorithm - an implementation could use BBR for instance if it wants. However there are a number of requirements that any algorithm must meet to be a conforming quic implementation - your previous excellent list of statements/explanations summed up many of these (Should all packets be acknowledged, etc). Currently however the spec interweaves the generic requirements with pseudo code for a particular implementation suggestion. It may well be worth having a suggested congestion control algorithm, but this should probably be separated into an appendix/separate section with the fundamental behaviours and requirements clearly defined first. > > Thomas > > The charter calls for congestion control using a standardized congestion controller as a default scheme for QUIC. That I was assuming was RENO-based, as Christian noted. I can really see merits in having a generic requirements document for congestion control requirements - although I am not keen though on seeing a Reno-like implementation only in an annexe; I guess the RENO-based spec could alternately become a separate document. I'm expecting in future, there may be other CC's that are specified by the IETF, probably based on algorithms that the IETF has evaluated reached consensus upon - BBR isn't one of those yet. Gorry From nobody Mon Aug 28 10:23:15 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ECA1326EC for ; Mon, 28 Aug 2017 10:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNqPoUQidEmu for ; Mon, 28 Aug 2017 10:23:11 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30B33132D17 for ; Mon, 28 Aug 2017 10:23:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3xgzB43j19zMp6H; Mon, 28 Aug 2017 19:23:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1GAPhk2GI7X; Mon, 28 Aug 2017 19:23:07 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (pD9E11F2C.dip0.t-ipconnect.de [217.225.31.44]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 28 Aug 2017 19:23:07 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Congestion Control Questions From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 28 Aug 2017 19:23:06 +0200 Cc: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , Christian Huitema , "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> To: gorry@erg.abdn.ac.uk X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:23:13 -0000 My thinking actually was that the recovery and congestion control = schemes are in a separate document because this gives you the = flexibility to specify alternatives in future. If there are parts in = this document that are mandatory for all future instances of this = version of QUIC or specify requirements, they should go into the main = transport spec. However, I think all we really need in the main spec is = a requirement to do congestion control at all; everything else in the = recovery/cc draft should be sender-side only and can therefore be = changed without requiring any negotiation or changes by the other end. Mirja > Am 28.08.2017 um 19:02 schrieb Gorry Fairhurst : >=20 > On 28/08/2017 14:41, Swindells, Thomas (Nokia - GB/Cambridge, UK) = wrote: >>> Which goes back to the reliance on pseudo code. It would be nice if = there was >>> text explaining how the QUIC algorithm differs from New Reno, and = why. >> I think this statement actually gets to the route of the problem. >> My understanding (presumption) is that a Quic implementation doesn't = have to use New Reno or any particular algorithm - an implementation = could use BBR for instance if it wants. However there are a number of = requirements that any algorithm must meet to be a conforming quic = implementation - your previous excellent list of statements/explanations = summed up many of these (Should all packets be acknowledged, etc). = Currently however the spec interweaves the generic requirements with = pseudo code for a particular implementation suggestion. It may well be = worth having a suggested congestion control algorithm, but this should = probably be separated into an appendix/separate section with the = fundamental behaviours and requirements clearly defined first. >> Thomas > > > The charter calls for congestion control using a standardized = congestion controller as a default scheme for QUIC. That I was assuming = was RENO-based, as Christian noted. >=20 > I can really see merits in having a generic requirements document for = congestion control requirements - although I am not keen though on = seeing a Reno-like implementation only in an annexe; I guess the = RENO-based spec could alternately become a separate document. I'm = expecting in future, there may be other CC's that are specified by the = IETF, probably based on algorithms that the IETF has evaluated reached = consensus upon - BBR isn't one of those yet. >=20 > Gorry >=20 From nobody Mon Aug 28 10:30:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA18513293C for ; Mon, 28 Aug 2017 10:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BRBL_LASTEXT=1.449, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ievo4lGHPUG0 for ; Mon, 28 Aug 2017 10:30:44 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 55D671326EC for ; Mon, 28 Aug 2017 10:30:44 -0700 (PDT) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:79bd:af46:1240:1202]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E5AF81B0021A; Mon, 28 Aug 2017 18:30:42 +0100 (BST) Reply-To: gorry@erg.abdn.ac.uk Subject: Re: Congestion Control Questions To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Cc: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" , Christian Huitema References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: <0cede96f-fe08-9b38-dc7a-3727926b142a@erg.abdn.ac.uk> Date: Mon, 28 Aug 2017 18:30:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:30:46 -0000 On 28/08/2017 18:23, Mirja Kühlewind wrote: > My thinking actually was that the recovery and congestion control schemes are in a separate document because this gives you the flexibility to specify alternatives in future. If there are parts in this document that are mandatory for all future instances of this version of QUIC or specify requirements, they should go into the main transport spec. However, I think all we really need in the main spec is a requirement to do congestion control at all; everything else in the recovery/cc draft should be sender-side only and can therefore be changed without requiring any negotiation or changes by the other end. > > Mirja > This also seems like it would work. I suspect RFC8085 gives a basic requirement anyway to do CC. Gorry > >> Am 28.08.2017 um 19:02 schrieb Gorry Fairhurst : >> >> On 28/08/2017 14:41, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote: >>>> Which goes back to the reliance on pseudo code. It would be nice if there was >>>> text explaining how the QUIC algorithm differs from New Reno, and why. >>> I think this statement actually gets to the route of the problem. >>> My understanding (presumption) is that a Quic implementation doesn't have to use New Reno or any particular algorithm - an implementation could use BBR for instance if it wants. However there are a number of requirements that any algorithm must meet to be a conforming quic implementation - your previous excellent list of statements/explanations summed up many of these (Should all packets be acknowledged, etc). Currently however the spec interweaves the generic requirements with pseudo code for a particular implementation suggestion. It may well be worth having a suggested congestion control algorithm, but this should probably be separated into an appendix/separate section with the fundamental behaviours and requirements clearly defined first. >>> Thomas >>> >> The charter calls for congestion control using a standardized congestion controller as a default scheme for QUIC. That I was assuming was RENO-based, as Christian noted. >> >> I can really see merits in having a generic requirements document for congestion control requirements - although I am not keen though on seeing a Reno-like implementation only in an annexe; I guess the RENO-based spec could alternately become a separate document. I'm expecting in future, there may be other CC's that are specified by the IETF, probably based on algorithms that the IETF has evaluated reached consensus upon - BBR isn't one of those yet. >> >> Gorry >> > From nobody Mon Aug 28 12:36:08 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A171126BF0 for ; Mon, 28 Aug 2017 12:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAU0e-P_6bTe for ; Mon, 28 Aug 2017 12:36:05 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C222A132937 for ; Mon, 28 Aug 2017 12:36:04 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dmPpK-0004dV-8q for quic@ietf.org; Mon, 28 Aug 2017 21:36:03 +0200 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 1dmPpC-0006lS-Gl for quic@ietf.org; Mon, 28 Aug 2017 15:35:58 -0400 Received: (qmail 28718 invoked from network); 28 Aug 2017 19:35:52 -0000 Received: from unknown (HELO [IPv6:2607:fb90:82a0:6d6f:2466:175d:6ffc:f245]) (Authenticated-user:_huitema@huitema.net@[172.58.47.110]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Aug 2017 19:35:52 -0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14G60) In-Reply-To: <0cede96f-fe08-9b38-dc7a-3727926b142a@erg.abdn.ac.uk> Date: Mon, 28 Aug 2017 12:35:51 -0700 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <0cede96f-fe08-9b38-dc7a-3727926b142a@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Subject: Re: Congestion Control Questions X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJZYP2pkjqshrWYL747BjInHND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23rwwrSbvAiN3f328xGcoP9Hmh7ILS3qjFQK1L qJUJK/tNFWovo5DGlmytNdYe4oSQYOEkjsX7F8KmpUaZQHV+SejOO+5k046wqf0SEutzqoO2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpOWca0Z0beD6jMx95O4U5K/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZrbZ/ndEh9ec371RUQFhBneNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj23767r3uidg2sat2CaHRbMwJNdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5looBbz0N8zFVWswza5GpJSAk078I0y+3uS4dN KiUgYTBUhNxbuZQC2ov60+tfEU0tmoAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/RufmJqHIgpwQblHGid2pC00i13zjCiwPgdt77s k1WBMw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 19:36:07 -0000 I agree with Mirja. It would be much clearer to separate recovery and conges= tion. -- Christian Huitema=20 > On Aug 28, 2017, at 10:30 AM, Gorry Fairhurst wrote= : >=20 >> On 28/08/2017 18:23, Mirja K=C3=BChlewind wrote: >> My thinking actually was that the recovery and congestion control schemes= are in a separate document because this gives you the flexibility to specif= y alternatives in future. If there are parts in this document that are manda= tory for all future instances of this version of QUIC or specify requirement= s, they should go into the main transport spec. However, I think all we real= ly need in the main spec is a requirement to do congestion control at all; e= verything else in the recovery/cc draft should be sender-side only and can t= herefore be changed without requiring any negotiation or changes by the othe= r end. >> Mirja > This also seems like it would work. I suspect RFC8085 gives a basic requir= ement anyway to do CC. >=20 > Gorry >=20 >>> Am 28.08.2017 um 19:02 schrieb Gorry Fairhurst : >>>=20 >>> On 28/08/2017 14:41, Swindells, Thomas (Nokia - GB/Cambridge, UK) wrote:= >>>>> Which goes back to the reliance on pseudo code. It would be nice if th= ere was >>>>> text explaining how the QUIC algorithm differs from New Reno, and why.= >>>> I think this statement actually gets to the route of the problem. >>>> My understanding (presumption) is that a Quic implementation doesn't ha= ve to use New Reno or any particular algorithm - an implementation could use= BBR for instance if it wants. However there are a number of requirements th= at any algorithm must meet to be a conforming quic implementation - your pre= vious excellent list of statements/explanations summed up many of these (Sho= uld all packets be acknowledged, etc). Currently however the spec interweave= s the generic requirements with pseudo code for a particular implementation s= uggestion. It may well be worth having a suggested congestion control algori= thm, but this should probably be separated into an appendix/separate section= with the fundamental behaviours and requirements clearly defined first. >>>> Thomas >>>>=20 >>> The charter calls for congestion control using a standardized congestio= n controller as a default scheme for QUIC. That I was assuming was RENO-base= d, as Christian noted. >>>=20 >>> I can really see merits in having a generic requirements document for co= ngestion control requirements - although I am not keen though on seeing a Re= no-like implementation only in an annexe; I guess the RENO-based spec could a= lternately become a separate document. I'm expecting in future, there may be= other CC's that are specified by the IETF, probably based on algorithms tha= t the IETF has evaluated reached consensus upon - BBR isn't one of those yet= . >>>=20 >>> Gorry >>>=20 >=20 From nobody Tue Aug 29 07:37:39 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3F132D01 for ; Tue, 29 Aug 2017 07:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYFMVA99hX8q for ; Tue, 29 Aug 2017 07:37:16 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2CDC132D65 for ; Tue, 29 Aug 2017 07:37:14 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id s143so17875588ywg.0 for ; Tue, 29 Aug 2017 07:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GSQtIYtHg3msdcV8RnuUSjRqVFDCwldGnPCrvHMGCbA=; b=Z7TIOYNwggBsuIvvFZSrRAertplbPGEVG929zjuyX6QClbM6Aj8G5lZYyWqjtkEyVr muOx+DFMljESnZHiKLQs4PWw2CE8Vh1WsF/fpj2+tx0MWNlRmQR3GSiMEtIyoiV6l2r0 ov1RDDABTy3BdCgAtsU6Z5Zjcufrti3CpLZC3rHbYNFISirlf8BdBGYYGtzEPBCjxMEB 0EK/XK+wzpjcUU94K6iTtQxMZV8VJsadbwWqvwM8nmE7t3giBTiOjxssfGFlMUejbbci kWvcwcXswtXrE+sRIa8hUFVn6nyMj93CmeRRVWO4Gawx6DS4Iblj/FG3TXKIJF+7xRUJ zLGw== 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=GSQtIYtHg3msdcV8RnuUSjRqVFDCwldGnPCrvHMGCbA=; b=D9GRlzkI0po20m87lS4ha3sDi8EIiXc74KUot5ktbvDIJBbOTOot+SH3eyKLWg3dtY 02fwjBuwyLY8bP3eyK+giUkmkwYURIvNqMmu3/FjOQ4YkvSthDt6s8p/YzT04zNwCw58 KHZH0Xdhi8ZQe8lNV64Ix2GJ2OszADNyb/zqa4ceKmFTvMC4q1F6DxtY2I0Ocfa77FF9 DZTYPgQzUKtPmNyzq0nXiRs5ltXsbv3VjeXYDelV91f58mXvkbBHucm42T4KWafA38L2 Eu7tvJL8+KUOz6moxA8hQpNbUlRiGBBuv+7qw1tSY6Enjri0rEpxdHTRvwJKKblCcInt 9JIg== X-Gm-Message-State: AHYfb5il22RJhW2b/SRvjiDoAvv7MR3qF/aLgVLZR+g8j0xOBOUEiy6p hC5PE34/OPkLZ7iT19B66Do7/4Vl4Q== X-Received: by 10.37.88.86 with SMTP id m83mr564332ybb.170.1504017434038; Tue, 29 Aug 2017 07:37:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Tue, 29 Aug 2017 07:37:13 -0700 (PDT) In-Reply-To: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> From: Spencer Dawkins at IETF Date: Tue, 29 Aug 2017 09:37:13 -0500 Message-ID: Subject: Re: Congestion Control Questions To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "gorry@erg.abdn.ac.uk" , "Swindells, Thomas (Nokia - GB/Cambridge, UK)" , "quic@ietf.org" , Christian Huitema Content-Type: multipart/alternative; boundary="001a114166d4e456cf0557e558d9" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 29 Aug 2017 14:37:27 -0000 --001a114166d4e456cf0557e558d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, On Mon, Aug 28, 2017 at 12:23 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > My thinking actually was that the recovery and congestion control schemes > are in a separate document because this gives you the flexibility to > specify alternatives in future. That was certainly my understanding, when we were doing the charter. > If there are parts in this document that are mandatory for all future > instances of this version of QUIC or specify requirements, they should go > into the main transport spec. However, I think all we really need in the > main spec is a requirement to do congestion control at all; I would support that ... but, just to take a QUIC(!) sample ... > everything else in the recovery/cc draft should be sender-side only and > can therefore be changed without requiring any negotiation or changes by > the other end. I'm hoping that's true, but feel I should ask if people are thinking about behavior that's NOT sender-side only, right about here, in this thread. Spencer --001a114166d4e456cf0557e558d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FWIW,

On Mon, Aug 28, 2017 at 12:23 PM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
My thinking actually was that the recovery and congesti= on control schemes are in a separate document because this gives you the fl= exibility to specify alternatives in future.

That was certainly my understanding, when we were doing the charter.
=C2=A0
If there are parts in thi= s document that are mandatory for all future instances of this version of Q= UIC or specify requirements, they should go into the main transport spec. H= owever, I think all we really need in the main spec is a requirement to do = congestion control at all;

I would support= that ... but, just to take a QUIC(!) sample ...
=C2=A0
everything else in the recovery/cc draft should = be sender-side only and can therefore be changed without requiring any nego= tiation or changes by the other end.

I'= m hoping that's true, but feel I should ask if people are thinking abou= t behavior that's NOT sender-side only, right about here, in this threa= d.

Spencer=C2=A0
--001a114166d4e456cf0557e558d9-- From nobody Wed Aug 30 01:46:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831561326FE for ; Wed, 30 Aug 2017 01:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IEB_R9nJ2UWD for ; Wed, 30 Aug 2017 01:46:39 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 668B8132705 for ; Wed, 30 Aug 2017 01:46:37 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id v7U8jsnZ025261 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Aug 2017 10:45:54 +0200 Received: from [2001:638:809:ff1f::8295:dc3a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dmycz-0007fF-Sv; Wed, 30 Aug 2017 10:45:37 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Congestion Control Questions From: "Philipp S. Tiesel" In-Reply-To: Date: Wed, 30 Aug 2017 10:45:53 +0200 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> To: Spencer Dawkins at IETF 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, 30 Aug 2017 08:46:41 -0000 > On 29. Aug 2017, at 16:37, Spencer Dawkins at IETF = wrote: =E2=80=A6 > everything else in the recovery/cc draft should be sender-side only = and can therefore be changed without requiring any negotiation or = changes by the other end. >=20 > I'm hoping that's true, but feel I should ask if people are thinking = about behavior that's NOT sender-side only, right about here, in this = thread. At the moment, I see one case where this assumption does not hold: = purely ECN based congestion control. In this case, the receiver must = agree to notify the sender about ECN marked packets.=20 Can be mitigated easily by negotiation ECN and fall back to loss based = CC if not available, but this _is_ some kind of negotiation. I guess requiring sender-side behaviour only unless negotiated otherwise = will do the trick.=20 AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Wed Aug 30 08:03:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85546132D42 for ; Wed, 30 Aug 2017 08:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETh5TkbyzAJx for ; Wed, 30 Aug 2017 08:03:31 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991CF132C44 for ; Wed, 30 Aug 2017 08:03:31 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id t188so32583471ywb.1 for ; Wed, 30 Aug 2017 08:03:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Td9wu0IeVF2G466wtbCC8e9BumnQK7Z1ZsDtYxCkVuE=; b=WyoLZEfRBU2EL1kjACG9WKEb1/LPn3ItI3FxZtiCa1mGY5840UngNGqRxGT5v3tUpR JTuY3v/EczS/GortmsQONCsoYJ0qlvpDtlGm6anmrOSn/jPotwAM6DX8NVpHgVYq9i9H ntniVbKNpHXFeT0j/PX1D991eevhJakanjGJ3E0BrQYq0SzpiXRxP7eNZNa/jlPdWW3o A4R/0mfVfJDV2l+RH7E2OthkJ+ApidmLuKDgxpg4i9/XeXpZ13onG5yzEjBssCPMU2J3 RLhLxbn7E/W2B57YTBFdMa7QNLa8h4FF/6IAPN/Uq4t+2HsbOWC1ATGKx9KHBZNwQ9Wd 8dXA== 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=Td9wu0IeVF2G466wtbCC8e9BumnQK7Z1ZsDtYxCkVuE=; b=lpKxjFOpH1jBXFIrMFuA6qzVLf0qAA7bvHPci8xjDL6dvlQNnXLGEicoBa/FxngQ9P lZiwhp92v3xbiQUuMwudQtYDJDHRzukOp+v6Wfe3JuujftSwZqSDD4XEtGa488ySZRKm DCkjMKGOiNGTI7Nq/wx6bBbltp32XF3V98rSiFkfhroa87QMohR348+MdlDpJeWMaRO2 hxxpY6QL4gahv5gk6uqaUUPMgQJK8oMydN1gOQ8WgFCeJk3h8gSEOi+XgSzCDh3uxpWu Lt1U3FhtMin5F8DaNAXVaUAqR0UXK2IVuQXEAhwViB2o2xlu+5rIWR2ST53oG6Y44yTa e3LQ== X-Gm-Message-State: AHYfb5jHaY8zK+J+3Wime7FdNRvt8Pj3+YmYxTDeZvKRJpZJzqJJrJWL 1qQGmf/HSm6gyFPmm1HseZMk/tBA2w== X-Received: by 10.129.102.213 with SMTP id a204mr1510690ywc.57.1504105410652; Wed, 30 Aug 2017 08:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Wed, 30 Aug 2017 08:03:30 -0700 (PDT) In-Reply-To: <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> From: Spencer Dawkins at IETF Date: Wed, 30 Aug 2017 10:03:30 -0500 Message-ID: Subject: Re: Congestion Control Questions To: "Philipp S. Tiesel" Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a11490146b4f0c60557f9d465" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Aug 2017 15:03:33 -0000 --001a11490146b4f0c60557f9d465 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Philipp, On Wed, Aug 30, 2017 at 3:45 AM, Philipp S. Tiesel wrote: > > > On 29. Aug 2017, at 16:37, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > =E2=80=A6 > > > everything else in the recovery/cc draft should be sender-side only and > can therefore be changed without requiring any negotiation or changes by > the other end. > > > > I'm hoping that's true, but feel I should ask if people are thinking > about behavior that's NOT sender-side only, right about here, in this > thread. > > At the moment, I see one case where this assumption does not hold: purely > ECN based congestion control. In this case, the receiver must agree to > notify the sender about ECN marked packets. > Can be mitigated easily by negotiation ECN and fall back to loss based CC > if not available, but this _is_ some kind of negotiation. > > I guess requiring sender-side behaviour only unless negotiated otherwise > will do the trick. I knew that, but BOY, it didn't come out in my question! I think I've been talking about ECN enough lately that I'm taking it as a given, especially based on the last testing results I saw in Prague. Thanks for making that explicit. Anything else? :-) Spencer --001a11490146b4f0c60557f9d465 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Philipp,

On Wed, Aug 30, 2017 at 3:45 AM, Philipp S. Tiesel <phils@in-p= anik.de> wrote:

> On 29. Aug 2017, at 16:37, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>= ; wrote:

=E2=80=A6

> everything else in the recovery/cc draft should be sender-side only an= d can therefore be changed without requiring any negotiation or changes by = the other end.
>
> I'm hoping that's true, but feel I should ask if people are th= inking about behavior that's NOT sender-side only, right about here, in= this thread.

At the moment, I see one case where this assumption does not hold: p= urely ECN based congestion control. In this case, the receiver must agree t= o notify the sender about ECN marked packets.
Can be mitigated easily by negotiation ECN and fall back to loss based CC i= f not available, but this _is_ some kind of negotiation.

I guess requiring sender-side behaviour only unless negotiated otherwise wi= ll do the trick.

I knew that, but BOY, it d= idn't come out in my question! I think I've been talking about ECN = enough lately that I'm taking it as a given, especially based on the la= st testing results I saw in Prague. Thanks for making that explicit.
<= div>
Anything else? :-)

Spencer=C2= =A0
--001a11490146b4f0c60557f9d465-- From nobody Wed Aug 30 12:04:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1301326EA for ; Wed, 30 Aug 2017 12:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAMBLyZvHUVK for ; Wed, 30 Aug 2017 12:04:24 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC411323A3 for ; Wed, 30 Aug 2017 12:04:24 -0700 (PDT) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dn8Hl-0002Op-Fc for quic@ietf.org; Wed, 30 Aug 2017 21:04:22 +0200 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 1dn8Hi-00047U-Sc for quic@ietf.org; Wed, 30 Aug 2017 15:04:19 -0400 Received: (qmail 26102 invoked from network); 30 Aug 2017 19:04:18 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Aug 2017 19:04:17 -0000 To: quic@ietf.org References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> From: Christian Huitema Message-ID: <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> Date: Wed, 30 Aug 2017 12:04:16 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4AA7309D716AA7967EE4283B" Content-Language: en-US Subject: Re: Congestion Control Questions X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJackVDEeh/s63C3hq8BP19aND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA234ik/DN0gU7FVTx+H3XHvIdLrUi7cn2NORKNn NPpYi2d5gP5tg586ukfF7IE6RHCFYOEkjsX7F8KmpUaZQHV+ST61TfxIvi8LwOTvVrRIhaC2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpIuW2VxLnS94njDgTNmyTXH6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGySp0MH0HE4kSRPFR6vKg+PTeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj235bvepmUNZsalPsiyi0NyxkWezJa7xDQcOg5ET5/LmCvakjSWDcjZyDseb0cBFM1p7J 0ZI2Cud2W8ULqpclZpX6sJqelmxqtloshGkSoDyZkYWbGwW5p2QNYx3a2iv3sPXl+SLIUlja/PsD mRv++1lEXefWTq/nEzScNhmC97Sx5XBZ7pmcPPET1gsbqYqsHO2B1AyhUYt13ZFWiMbSDOe6Tsut 9Ntwqm/jmjsUXZwk2AT7Y9cRih4Det7+7EbH8nOrv5Mi7W1Fe3H2lzs3Ph6Br8hUVhe7ugL65f2h l2QLng== 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, 30 Aug 2017 19:04:26 -0000 This is a multi-part message in MIME format. --------------4AA7309D716AA7967EE4283B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote: > Anything else? :-) > I can think of cooperative schemes between the peers. For example, the receiver has a good idea of the packet reordering properties of the network, how long can an out of order packet be delayed. One can imagine the receiver passing that information to the sender in a special frame, for more efficient recovery. The receiver could also observe properties of the received stream such as bunching of packets, or some clever statistical analysis that we have not thought off yet. That too could be passed in a special frame. The peers could also negotiate a lower priority congestion algorithm, e.g. using LEDBAT instead of New Reno. All this is of course speculative. And maybe it points to the need for a simple extension mechanism, so we can experiment with this sort of things. I could think of: * defining an extension ID as a 32 bit number; * adding a supported extension list in the transport parameters, with an implicit negotiation, * adding an extended frame format, starting with a length and a 32 bit extension ID. But to come back to your original question, we can certainly start by assuming that congestion control and recovery algorithms are sender only.= --=20 Christian Huitema --------------4AA7309D716AA7967EE4283B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote:
Anything else? :-)


I can think of cooperative schemes between the peers. For example, the receiver has a good idea of the packet reordering properties of the network, how long can an out of order packet be delayed. One can imagine the receiver passing that information to the sender in a special frame, for more efficient recovery. The receiver could also observe properties of the received stream such as bunching of packets, or some clever statistical analysis that we have not thought off yet. That too could be passed in a special frame. The peers could also negotiate a lower priority congestion algorithm, e.g. using LEDBAT instead of New Reno.

All this is of course speculative. And maybe it points to the need for a simple extension mechanism, so we can experiment with this sort of things. I could think of:

* defining an extension ID as a 32 bit number;
* adding a supported extension list in the transport parameters, with an implicit negotiation,
* adding an extended frame format, starting with a length and a 32 bit extension ID.

But to come back to your original question, we can certainly start by assuming that congestion control and recovery algorithms are sender only. 

-- 
Christian Huitema
--------------4AA7309D716AA7967EE4283B-- From nobody Wed Aug 30 13:03:06 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1507D132946 for ; Wed, 30 Aug 2017 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com header.b=aPZbWZM2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=IdkMtmJf Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PT_5ud0odHNm for ; Wed, 30 Aug 2017 13:03:03 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B4A1326EC for ; Wed, 30 Aug 2017 13:03:03 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v7UK1W3p023235 for ; Wed, 30 Aug 2017 13:03:01 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=u1xsTkdCwKVpYCoL4A6qU0OHIAGcPQk/k2NCoomgm9I=; b=aPZbWZM2vxz/ZJf8SW0+BYXNLAm4/K3Da7Du8dhb8iQ5jzv+BFAYR1sEIYjtHfqw63at EfaePnrFWSF/2wRh1y/CRVtgGZdMbWjbk2KTTE397QNEyP02+o25HnOBt8UoKw9xzt9/ SlKiL9EI3gYCDsF/KAud/62YdZoIfAaNQeg= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0b-00082601.pphosted.com with ESMTP id 2cnsxcuahk-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 30 Aug 2017 13:03:01 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 30 Aug 2017 16:03:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u1xsTkdCwKVpYCoL4A6qU0OHIAGcPQk/k2NCoomgm9I=; b=IdkMtmJfE/5vqr/1dahIhw5oXWG/8SXVDfudizGwIhqKHWH3hMTGLNO0naXbjde2lt9/jYrX+ld6Aaye0+zh/vfTVVKaetG+UKMYDSODyS6AR5YqnUVI6iwmMngM3DyZab9ty8hOF125dY+uMwSckWpJhkJIM8QiP6kuDDiEN/s= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1244.namprd15.prod.outlook.com (10.173.209.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Wed, 30 Aug 2017 20:02:59 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.01.1385.014; Wed, 30 Aug 2017 20:02:59 +0000 From: Roberto Peon To: "quic@ietf.org" Subject: Intermediary-assisted retransmission at layer(s) below 3. Thread-Topic: Intermediary-assisted retransmission at layer(s) below 3. Thread-Index: AQHTIcr6kd+tNkw3GE2WROWrjx59Og== Date: Wed, 30 Aug 2017 20:02:59 +0000 Message-ID: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:896c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1244; 20:EpbNP+aeF6gtDuy6ojUh3mYEuov+5wqXGTXYFY/qMZk00GeXKlGr039WS84CYKUK1YUI28B3oajwBoG7Fu10Y6xG2EZHSlCOT8RWU1Dc+qVsyr0hmSez92n/OlqxAx9nPz68U9riCaYqvumtzPbXIJkmNkWJIlnbMwIwRh8cqXU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7ea5026d-db43-47da-db25-08d4efe21ce1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DM5PR15MB1244; x-ms-traffictypediagnostic: DM5PR15MB1244: x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1244; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1244; x-forefront-prvs: 041517DFAB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(2900100001)(82746002)(2501003)(6916009)(189998001)(2906002)(6486002)(77096006)(5640700003)(6506006)(33656002)(68736007)(97736004)(54896002)(8676002)(81156014)(6512007)(81166006)(6306002)(110136004)(1730700003)(86362001)(53936002)(99286003)(83716003)(3280700002)(14454004)(8936002)(50986999)(54356999)(478600001)(102836003)(2351001)(105586002)(36756003)(6116002)(5660300001)(106356001)(3660700001)(558084003)(101416001)(7736002)(25786009)(6436002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1244; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_355A28782E3A4929B4180550EA61BC7Cfbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 20:02:59.0887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1244 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-30_08:, , signatures=0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 20:03:05 -0000 --_000_355A28782E3A4929B4180550EA61BC7Cfbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSByZWNlbnQgZW1haWwgZnJvbSBDaHJpc3RpYW4gSHVpdGVtYSBhYm91dCBjb25nZXN0aW9uIHJl bGF0ZWQgdGhpbmdzIGdvdCBtZSB3b25kZXJpbmcgaWYgd2XigJlkIGRpc2N1c3NlZCBzaWduYWxp bmcgdG8gaW50ZXJtZWRpYXJpZXMgYWJvdXQgd2hldGhlciBvciBub3QgdGhleeKAmXJlIHN1cHBv c2VkIHRvIGhlbHAgd2l0aCByZXRyYW5zbWlzc2lvbi4gSGFzIHRoYXQgZGlzY3Vzc2lvbiBoYXBw ZW5lZCB5ZXQ/DQoNCi09Ug0KKFJvYmVydG8gUGVvbiBmb3IgdGhvc2Ugd2hvIGRvbuKAmXQga25v dyB5ZXQgOykgKQ0K --_000_355A28782E3A4929B4180550EA61BC7Cfbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <1B2E3EECFE48E34598C465391AD9CF73@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 cmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCglj b2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIHJl Y2VudCBlbWFpbCBmcm9tIENocmlzdGlhbiBIdWl0ZW1hIGFib3V0IGNvbmdlc3Rpb24gcmVsYXRl ZCB0aGluZ3MgZ290IG1lIHdvbmRlcmluZyBpZiB3ZeKAmWQgZGlzY3Vzc2VkIHNpZ25hbGluZyB0 byBpbnRlcm1lZGlhcmllcyBhYm91dCB3aGV0aGVyIG9yIG5vdCB0aGV54oCZcmUgc3VwcG9zZWQg dG8gaGVscCB3aXRoIHJldHJhbnNtaXNzaW9uLiBIYXMgdGhhdCBkaXNjdXNzaW9uIGhhcHBlbmVk IHlldD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oUm9iZXJ0byBQZW9uIGZvciB0aG9zZSB3aG8gZG9u4oCZdCBrbm93IHll dCA7KSApPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_355A28782E3A4929B4180550EA61BC7Cfbcom_-- From nobody Wed Aug 30 15:30:29 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2017A12426E for ; Wed, 30 Aug 2017 15:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 DXSgYRTWhF9d for ; Wed, 30 Aug 2017 15:30:25 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A6D81200F3 for ; Wed, 30 Aug 2017 15:30:25 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id t188so37977881ywb.1 for ; Wed, 30 Aug 2017 15:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GpxGpiBuiWD0EJ7V8L6p6QrXLhcf2I522gFIKsT7NVE=; b=A3LinXNCCwxcm/3iqHalp7C7qUaObnIxpzl5a3WesIWVc/80SsuwEs0D3yAyzVt7tD 2e4jIM628jE51kDpPTsWlRtRzyDCC/wzBYhPRF9JXvuaam/SFQmN1sbmyKpheNsdhbgm RMO+LftUfj07Z++N9pHOmd8vzHC06b3N6iTyf4PrbG2k7Mo3JLjacK16obACVFanDB3O EsL7EqUkE97pVeBR0A6IVc3M0zol7ovYCMYwWLoHvpTUGmxCNM62MVppofPtDP/A3G2f vvJxioANgq8bkpnnO7pKz1KXO6+G9UMT2nYXOpTl1QcAL/5WVDNaavxv8ivt0agliZ7/ htTw== 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=GpxGpiBuiWD0EJ7V8L6p6QrXLhcf2I522gFIKsT7NVE=; b=p0tgcCN2OIPnVI5Z/kykNiaIq7UrsqsH7aj5uU44AvHtZV98e7koLXJItlggB9I2K0 G7un7mIHzEkX9bpk9RN/yZCBGXKYiLTaCCoKiEGEl61aA9Wub+f4sR3fAROOn1rYSoj+ KYUtUU+u+dCqKYocWeRXL0RNMGZFky5LE5zClDSp9UL/v5HRjtG9UXBlrINMoibMSnIr UQ/CZ/e3axb+yhGbGKmKddAALh4hBTHpuJyBY2efS5mMPvS+reLnIK/B8q3fTJrrV4nZ y7sK9wMs4wRmnHz2WPeZkG6aHEWFUfKJES4WUEqoOKDOKrwrgNW3MoOyFhSGeTiPmJAd UdCA== X-Gm-Message-State: AHYfb5hBJaeAS1HeBTBbjGhifYW+H3zyC2dy99q2aRdFdcVV8Nn4rDEr BBfvEyklarUPrGghHF1smWBxQOG35A== X-Received: by 10.37.215.198 with SMTP id o189mr2859624ybg.38.1504132224259; Wed, 30 Aug 2017 15:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Wed, 30 Aug 2017 15:30:23 -0700 (PDT) In-Reply-To: <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> From: Spencer Dawkins at IETF Date: Wed, 30 Aug 2017 17:30:23 -0500 Message-ID: Subject: Re: Congestion Control Questions To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0602b0ec1a1605580012b6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 30 Aug 2017 22:30:27 -0000 --94eb2c0602b0ec1a1605580012b6 Content-Type: text/plain; charset="UTF-8" Hi, Christian, On Wed, Aug 30, 2017 at 2:04 PM, Christian Huitema wrote: > > > On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote: > > Anything else? :-) > > > I can think of cooperative schemes between the peers. For example, the > receiver has a good idea of the packet reordering properties of the > network, how long can an out of order packet be delayed. One can imagine > the receiver passing that information to the sender in a special frame, for > more efficient recovery. The receiver could also observe properties of the > received stream such as bunching of packets, or some clever statistical > analysis that we have not thought off yet. That too could be passed in a > special frame. The peers could also negotiate a lower priority congestion > algorithm, e.g. using LEDBAT instead of New Reno. > > All this is of course speculative. And maybe it points to the need for a > simple extension mechanism, so we can experiment with this sort of things. > I could think of: > > * defining an extension ID as a 32 bit number; > * adding a supported extension list in the transport parameters, with an > implicit negotiation, > * adding an extended frame format, starting with a length and a 32 bit > extension ID. > > But to come back to your original question, we can certainly start by > assuming that congestion control and recovery algorithms are sender only. > Thanks for your thoughts on this (which sound very useful to me), and I'm fine making that starting assumption (modulo ECN, which I *hope* people think is a baseline for transport functionality in 2017, which is why *I* forget to mention it). ADs have to ask ... ;-) Spencer --94eb2c0602b0ec1a1605580012b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Christian,

On Wed, Aug 30, 2017 at 2:04 PM, Christian Huitema <huite= ma@huitema.net> wrote:
=20 =20 =20



On 8/30/2017 8:03 = AM, Spencer Dawkins at IETF wrote:
Anything else? :-)


I can think of cooperative schemes between the peers. For example, the receiver has a good idea of the packet reordering properties of the network, how long can an out of order packet be delayed. One can imagine the receiver passing that information to the sender in a special frame, for more efficient recovery. The receiver could also observe properties of the received stream such as bunching of packets, or some clever statistical analysis that we have not thought off yet. That too could be passed in a special frame. The peers could also negotiate a lower priority congestion algorithm, e.g. using LEDBAT instead of New Reno.

All this is of course speculative. And maybe it points to the need for a simple extension mechanism, so we can experiment with this sort of things. I could think of:

* defining an extension ID as a 32 bit number;
* adding a supported extension list in the transport parameters, with an implicit negotiation,
* adding an extended frame format, starting with a length and a 32 bit extension ID.

But to come back to your original question, we can certainly start by assuming that congestion control and recovery algorithms are sender only.=C2=A0

Thanks for you= r thoughts on this (which sound very useful to me), and I'm fine making= that starting assumption (modulo ECN, which I *hope* people think is a bas= eline for transport functionality in 2017, which is why *I* forget to menti= on it).

=C2=A0ADs have to ask ... ;-)
Spencer
--94eb2c0602b0ec1a1605580012b6-- From nobody Wed Aug 30 22:20:11 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6369D124207 for ; Wed, 30 Aug 2017 22:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7N1HrCwUtKF for ; Wed, 30 Aug 2017 22:20:07 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54DE1321A7 for ; Wed, 30 Aug 2017 22:20:07 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id s143so40523656ywg.0 for ; Wed, 30 Aug 2017 22:20:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jsfov/8uxEwi5Eijy/w+h3iHHFwl7gMhoKsd5HjED9s=; b=Dv9gdKblGdQg6Ko9MZz75q+Auq1BmtgqrSmyirgYS0ifnHFrl0vNA7CM5UTzhC93UH pOWsx0rWJQpiPSU5K3FyYWLO8a3q6ahdiW4ARw3dAK/x8G70erXdzlq8btHwx+32Xa7H mVb67TRDlb8P89V48YAKN7gn+IrRXvqau1kQ/jfOLL7iDxxpYSjtMWO8e7jyIDa6fRwW GRfHGmEVtOaiMw9JINTqs9nw3DLLX+TqkKb2ByNtnnz9o3ZNZELtzEQnmxvUoJ6JVpAD ff8ZbY5cNRsCC0ueUjNXj5dnBoWbuEElfEKL3MI+cMLcnoTWAG1BCjZg01TJ+sC3P1uJ +ziQ== 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=Jsfov/8uxEwi5Eijy/w+h3iHHFwl7gMhoKsd5HjED9s=; b=d4JuFbN89fjN6pLmdGKrliNB75k7Lxc3zMA20zWYoS4VMOZP+Lu+LF0XvqKonOEuUk zmdHzmxVcetP/8OaI2WfxTqlfUk1R2+Y1mYqahjIq5f4zP1lebjCkBMpOvIwE7ZpgjDG 73GogCTyjnCk7aiR0NJs4g3LUSiC1hgCLaYR1CxEpjrzpd5nVucDh9jrZCmoEHDWZmpY 2JuKwGUjNWTI3yBVacXdGX07HacWnDr/oh+D5n3VVlVSg1inLC9ee+WCgBbMXEdtTgsR XlB01dsiOv9BsoZgWLLwHrgS2SkJyGCl1mA9Sg+vZaiBA9bDOyVT7T9AvWqGU75waJDM +/PQ== X-Gm-Message-State: AHYfb5ilXJ1pEu0IGzJ/+UiUaVUwxzx5/mXRWuDsqj07Gw1SOnySwNI0 RunhB499mk73w1WCBytTLym8veF3v/uI X-Google-Smtp-Source: ADKCNb7+UMWUhkB9Q4tBd7m/n9whZhPtkODcXyDcfGdwlO1FXlIInV9ZYWSDEj1MvjTmeVoFmUUbTLEXEMWnMuGlSag= X-Received: by 10.37.176.67 with SMTP id e3mr3303643ybj.226.1504156806344; Wed, 30 Aug 2017 22:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.206 with HTTP; Wed, 30 Aug 2017 22:20:05 -0700 (PDT) In-Reply-To: References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> From: Jana Iyengar Date: Wed, 30 Aug 2017 22:20:05 -0700 Message-ID: Subject: Re: Congestion Control Questions To: Spencer Dawkins at IETF Cc: Christian Huitema , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045e6f8c21de32055805cc1b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 05:20:10 -0000 --f403045e6f8c21de32055805cc1b Content-Type: text/plain; charset="UTF-8" A few thoughts: - On recovery: NewReno's mechanism in TCP is exactly as Christian says, but that's because that was the only way to implement a recovery period in TCP. The motivation of the "recover" period in NewReno was for two reasons: (i) to avoid multiple cutbacks within an RTT, and (ii) to allow clocking out of retransmissions on "partial acks". I'm happy to go into the details of these if necessary, but for now I'll point to the sacks paper for more detailed analysis. The actions required during recovery changes quite a bit with QUIC, since we do not have the same problems. Specifically, QUIC does not *need* the concept of partial acks, since all acks carry detailed information. QUIC is probably closer to loss recovery with TCP SACK than NewReno, but even there, RFC 6675 (which specifies a loss recovery algorithm with TCP SACK) is conservative because of the possibility that a receiver might renege on previously SACKed blocks. A QUIC receiver cannot renege on any received packets, so we do not need to wait for the equivalent of the "cumulative ack" point to move past the recovery point. So, the QUIC algorithm waits for an RTT to ensure that there aren't multiple cwnd cutbacks within an RTT, which is exactly what is specified. I agree that describing all this in the doc would be useful, and I'll get to doing that shortly. - On bytes vs packets: as Victor said, bytes is the right thing to do congestion control on since congestion is expected to be in bytes, not packets, but gating should be in packets. This is what the spec tries to express. - On ACK frames: it was a conscious decision to not include acks in congestion control because they also cannot be gated by congestion control. This point can certainly be debated, but I would suggest that we tread a bit carefully when thinking about ACKs and congestion control, since CC tends to be quite sensitive to ACK timing. - I agree that more text needs to be written around the pseudo code but I'm not keen to split the congestion control and loss recovery mechanisms into two docs yet. I'd be happy to reconsider this when we've fleshed the doc out more -- I do see the merit in splitting them, but from an editorial perspective, I'd suggest that we leave them together for now and split them later if needed. On Wed, Aug 30, 2017 at 3:30 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Christian, > > On Wed, Aug 30, 2017 at 2:04 PM, Christian Huitema > wrote: > >> >> >> On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote: >> >> Anything else? :-) >> >> >> I can think of cooperative schemes between the peers. For example, the >> receiver has a good idea of the packet reordering properties of the >> network, how long can an out of order packet be delayed. One can imagine >> the receiver passing that information to the sender in a special frame, for >> more efficient recovery. The receiver could also observe properties of the >> received stream such as bunching of packets, or some clever statistical >> analysis that we have not thought off yet. That too could be passed in a >> special frame. The peers could also negotiate a lower priority congestion >> algorithm, e.g. using LEDBAT instead of New Reno. >> >> All this is of course speculative. And maybe it points to the need for a >> simple extension mechanism, so we can experiment with this sort of things. >> I could think of: >> >> * defining an extension ID as a 32 bit number; >> * adding a supported extension list in the transport parameters, with an >> implicit negotiation, >> * adding an extended frame format, starting with a length and a 32 bit >> extension ID. >> >> But to come back to your original question, we can certainly start by >> assuming that congestion control and recovery algorithms are sender only. >> > > Thanks for your thoughts on this (which sound very useful to me), and I'm > fine making that starting assumption (modulo ECN, which I *hope* people > think is a baseline for transport functionality in 2017, which is why *I* > forget to mention it). > > ADs have to ask ... ;-) > > Spencer > --f403045e6f8c21de32055805cc1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few thoughts:

- On recovery: NewReno&= #39;s mechanism in TCP is exactly as Christian says, but that's because= that was the only way to implement a recovery period in TCP. The motivatio= n of the "recover" period in NewReno was for two reasons: (i) to = avoid multiple cutbacks within an RTT, and (ii) to allow clocking out of re= transmissions on "partial acks". I'm happy to go into the det= ails of these if necessary, but for now I'll point to the=C2=A0sacks paper=C2=A0for more d= etailed analysis. The actions required during recovery changes quite a bit = with QUIC, since we do not have the same problems. Specifically, QUIC does = not *need* the concept of partial acks, since all acks carry detailed infor= mation.=C2=A0

QUIC is probably closer to loss= recovery with TCP SACK than NewReno, but even there, RFC 6675 (which speci= fies a loss recovery algorithm with TCP SACK) is conservative because of th= e possibility that a receiver might renege on previously SACKed blocks. A Q= UIC receiver cannot renege on any received packets, so we do not need to wa= it for the equivalent of the "cumulative ack" point to move past = the recovery point. So, the QUIC algorithm waits for an RTT to ensure that = there aren't multiple cwnd cutbacks within an RTT, which is exactly wha= t is specified.

I agree that describing all = this in the doc would be useful, and I'll get to doing that shortly.

- On bytes vs packets: as Victor said, bytes is the = right thing to do congestion control on since congestion is expected to be = in bytes, not packets, but gating should be in packets. This is what the sp= ec tries to express.

- On ACK frames: it was a= conscious decision to not include acks in congestion control because they = also cannot be gated by congestion control. This point can certainly be deb= ated, but I would suggest that we tread a bit carefully when thinking about= ACKs and congestion control, since CC tends to be quite sensitive to ACK t= iming.

- I agree that more text needs to be writte= n around the pseudo code but I'm not keen to split the congestion contr= ol and loss recovery mechanisms into two docs yet. I'd be happy to reco= nsider this when we've fleshed the doc out more -- I do see the merit i= n splitting them, but from an editorial perspective, I'd suggest that w= e leave them together for now and split them later if needed.

On Wed, Aug 30, 201= 7 at 3:30 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gma= il.com> wrote:
Hi, Christian,

On Wed, Aug 30, 2017 at 2:04 PM, Christian Huitema <h= uitema@huitema.net> wrote:
=20 =20 =20



On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote:
Anything else? :-)


I can think of cooperative schemes between the peers. For example, the receiver has a good idea of the packet reordering properties of the network, how long can an out of order packet be delayed. One can imagine the receiver passing that information to the sender in a special frame, for more efficient recovery. The receiver could also observe properties of the received stream such as bunching of packets, or some clever statistical analysis that we have not thought off yet. That too could be passed in a special frame. The peers could also negotiate a lower priority congestion algorithm, e.g. using LEDBAT instead of New Reno.

All this is of course speculative. And maybe it points to the need for a simple extension mechanism, so we can experiment with this sort of things. I could think of:

* defining an extension ID as a 32 bit number;
* adding a supported extension list in the transport parameters, with an implicit negotiation,
* adding an extended frame format, starting with a length and a 32 bit extension ID.

But to come back to your original question, we can certainly start by assuming that congestion control and recovery algorithms are sender only.=C2=A0

Thanks = for your thoughts on this (which sound very useful to me), and I'm fine= making that starting assumption (modulo ECN, which I *hope* people think i= s a baseline for transport functionality in 2017, which is why *I* forget t= o mention it).

=C2=A0ADs have to ask ... ;-)
=

Spencer<= /div>

--f403045e6f8c21de32055805cc1b-- From nobody Wed Aug 30 22:52:37 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F7C13219C for ; Wed, 30 Aug 2017 22:52:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deo_Lqj83a1L for ; Wed, 30 Aug 2017 22:52:34 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8649132191 for ; Wed, 30 Aug 2017 22:52:34 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h127so40834412ywf.3 for ; Wed, 30 Aug 2017 22:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D1fiyminOJuAJhPWLIOqgCsYw9CU5BHdmb9ELmt8/Yk=; b=G5K0kQ06kV0lBAm5k5T3ca6mt4dqIIQiiIAzOYLnnZSFobp78Y3hgUyaIbFHPR+O99 Je7qpyxs5q73DS89ZbuAILCIYwaij7G3frdvlTKXbINxclQBDClgNcaKn4fFlPOAQF6t H/+BvOH0hBAr57QVT54zh1mTqSFuQ8V/YG8UiaVmgHxQANAdRkEN/rrn/HgTWGINH7XW 90LnG6gBv8Z/Kq2I2joBW2uSvUUi89JojwOWgRyZfV5Qwe9AbaExnMumapazEPV55Thh 6S/wuvxEpGpQbzpmD9VOSXGVb5nhz8UXZdEyi5JwarjCdLIW/9QheLnr/LMRJpp7qLPd jLFQ== 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=D1fiyminOJuAJhPWLIOqgCsYw9CU5BHdmb9ELmt8/Yk=; b=kTSRjMJSyTnsq5XkxIK8Q8u4Lf7odcKYB1EET2Gle8ZcJOTq0f/laKpTJyiHlqQ9Xz fswOWzH088Xa4Y4e+JU6Jm3D5CbSy/xHjuD4BjxNsuXo53os6/8mVYiBuLVeYqw3bHUN Rc6wv2dcAfFjDuV0/vPDc2ILuIVWQ9iZ06MP5ql+VdC1DOGTvsgc4fKrBC5EhTHBr0bS VFbdfAIiYw7i6IXpF+5zE1er8Wa/vloCADBh9UX1/diX2Xs/FCpmWYQcUoEOaJvgpK6i 2xgyokRfmiFCHkjwNdNfVeio2mt+00dciNbQ+aGmdrLZCcSs8mpj1+CTt9nffOgX9vp/ VKsA== X-Gm-Message-State: AHYfb5ij45GNW6NFtIjZoXYUXzUzUIjhxjaSNsnBCtqWTJuJZQsKUsy8 XhASoaNA1spPVOUD+QT0gX8+0p+KZWC3 X-Google-Smtp-Source: ADKCNb4K3y8DH9ugjeKbcF4yHoa36q4O636drDtstwapd70IrptsXxn7pEQqlM+dzZSIRvLcRlld1FU/jPqHpwzdqy8= X-Received: by 10.129.173.96 with SMTP id l32mr3369417ywk.275.1504158753767; Wed, 30 Aug 2017 22:52:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.223.206 with HTTP; Wed, 30 Aug 2017 22:52:33 -0700 (PDT) In-Reply-To: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> References: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> From: Jana Iyengar Date: Wed, 30 Aug 2017 22:52:33 -0700 Message-ID: Subject: Re: Intermediary-assisted retransmission at layer(s) below 3. To: Roberto Peon Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045e9fea34a14405580640f6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 05:52:36 -0000 --f403045e9fea34a14405580640f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Welcome back from the dead, Roberto! You seem to have woken up in the wrong company, but still ... I don't think we discussed this specific issue, but I believe (and the chairs can correct me if I'm wrong) that the general issue of explicit signaling to intermediaries is largely out of scope for the wg. The wg's scope is limited to "consider the impact of the protocol on network management practices", largely because parallel efforts (SPUD, then PLUS) were going after the signaling to intermediaries in a more general fashion, and partly because this discussion ends up being a massive rat-hole of never-ending agony. Again, my opinion, others may disagree. That said, there have been a slate of recent discussions on exposing some amount of connection info to middleboxes, particularly to allow them to passively measure RTT, but that's not the issue you asked about. On Wed, Aug 30, 2017 at 1:02 PM, Roberto Peon wrote: > A recent email from Christian Huitema about congestion related things got > me wondering if we=E2=80=99d discussed signaling to intermediaries about = whether or > not they=E2=80=99re supposed to help with retransmission. Has that discus= sion > happened yet? > > > > -=3DR > > (Roberto Peon for those who don=E2=80=99t know yet ;) ) > --f403045e9fea34a14405580640f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Welcome back from the dead, Roberto! You seem to have woke= n up in the wrong company, but still ...

I don't thi= nk we discussed this specific issue, but I believe (and the chairs can corr= ect me if I'm wrong) that the general issue of explicit signaling to in= termediaries is largely out of scope for the wg. The wg's scope is limi= ted to "consider the impact of the protocol on network management prac= tices", largely because parallel efforts (SPUD, then PLUS) were going = after the signaling to intermediaries in a more general fashion, and partly= because this discussion ends up being a massive rat-hole of never-ending a= gony. Again, my opinion, others may disagree.

That= said, there have been a slate of recent discussions on exposing some amoun= t of connection info to middleboxes, particularly to allow them to passivel= y measure RTT, but that's not the issue you asked about.



On Wed, Aug 30, 2017 at 1:02 PM, Roberto Peon <fenix@fb.co= m> wrote:

A recent email from Christian Huitema about congesti= on related things got me wondering if we=E2=80=99d discussed signaling to i= ntermediaries about whether or not they=E2=80=99re supposed to help with re= transmission. Has that discussion happened yet?

=C2=A0

-=3DR

(Roberto Peon for those who don=E2=80=99t know yet ;= ) )


--f403045e9fea34a14405580640f6-- From nobody Wed Aug 30 23:09:05 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472D213219C for ; Wed, 30 Aug 2017 23:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=bqdD9Lay; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=chtzLYRe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1qSwtbzWbdG for ; Wed, 30 Aug 2017 23:09:01 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFB7132144 for ; Wed, 30 Aug 2017 23:09:01 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id BD3DF21E51; Thu, 31 Aug 2017 02:09:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 31 Aug 2017 02:09:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=PScN7iLlXwhCYrAZfT jYAP0OT7YsdACMy45BPNQgrUU=; b=bqdD9LayX+Do0zjD3OG5bJ5PwSq+JcxdDh XEx5Jf8aSk7B9T1p5qS+LyzSD958T0TuZ8y2xKHVCS2PULdQynufmjJTtTu/5WeI I4AmERWb3opxVccTLIjwuuZG+rXwBF75/T96czrAji3S63ulCwQgPwOUOn05SJpP JgEr51OcahgUR4bb4+8/us3C+l2mBmhrBIHvdOx/klVbr8dqZj22lqPb7jWYoU3k JTvIWd7umUpCdBBouWLMh8CZHS8yI2osuNBDpZA+LQOSi5avNGT5oKZSJM+HFhqI eJx1fHdGHSFT/+HKhxWFg+MCn01/3edpadl+dH6EctdtywlAh77Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=PScN7iLlXwhCYrAZfTjYAP0OT7YsdACMy45BPNQgrUU=; b=chtzLYRe y356PHVOK6PywyRgLbCePlAWiS+nRntYbAVuCZ86ri+F45RTi7hrSlSVQDLj2/GS KecflLKNXc//yukSAEAkv/bPMF1P/IXFUoezv5531bhERv97euPq2oFpDKld7fEN 0UgTx/d36MtIe6z0meZnYC4oVE0uUT0piBA7RwARsegiIMIkQgOrCw1dGP9wxVc6 ZP3YrhpgzfKex1etzp2kgwNghimzEvCbeb92pmezQ/O1kWSUFvOdMN/9wT62Qk+t SgUKkA1UDeQw9FStPl42IJM9XIvNFMKLpYSq4WWP3PzgPL/3u95I7SJTvN6P9DuA IF5FAcazR51kPA== X-ME-Sender: X-Sasl-enc: vkN2WykGjcjX6MXJfi2TjCXLp/mqsLdMwila7C7ie+WA 1504159740 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F5C424253; Thu, 31 Aug 2017 02:08:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Intermediary-assisted retransmission at layer(s) below 3. From: Mark Nottingham In-Reply-To: Date: Thu, 31 Aug 2017 16:08:55 +1000 Cc: Roberto Peon , "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:09:04 -0000 On 31 Aug 2017, at 3:52 pm, Jana Iyengar wrote: >=20 > Welcome back from the dead, Roberto! You seem to have woken up in the = wrong company, but still ... >=20 > I don't think we discussed this specific issue, but I believe (and the = chairs can correct me if I'm wrong) that the general issue of explicit = signaling to intermediaries is largely out of scope for the wg. The wg's = scope is limited to "consider the impact of the protocol on network = management practices", largely because parallel efforts (SPUD, then = PLUS) were going after the signaling to intermediaries in a more general = fashion, and partly because this discussion ends up being a massive = rat-hole of never-ending agony. Again, my opinion, others may disagree. >=20 > That said, there have been a slate of recent discussions on exposing = some amount of connection info to middleboxes, particularly to allow = them to passively measure RTT, but that's not the issue you asked about. I think that's a bit strong. The only things explicitly called out of = scope by the charter: """ Extensions that will support partial reliability, and negotiation=20 and use of Forward Error Correction schemes, are out of scope in=20 this version of the working group charter. """ There are of course numerous rat holes in this area, but they have more = to do with extensible frameworks for communicating with middleboxes, as = well as things that look like means of leaking information to them (or = allowing them to exert undue control). I don't know whether configuring = lower-layer "help" with things like like retransmission / FEC falls into = them, so it seems premature to rule them out at this stage (although we = do have to manage the discussion; we have a lot of ground to cover). Discussion of measurement of RTT and friends by middleboxen *is* off the = table until we hear back from the Design Team in Singapore. Welcome back to the circus, Roberto. If you want to open an issue / make = a proposal here, please feel free; I don't think we have anything that = covers it.=20 FYI, if you haven't seen it already, this might help: https://github.com/quicwg/base-drafts/projects Then again, it might scare you away. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Aug 30 23:54:27 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DEB71321BF for ; Wed, 30 Aug 2017 23:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BXTeJzbv5sB for ; Wed, 30 Aug 2017 23:54:25 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE9E41321EC for ; Wed, 30 Aug 2017 23:54:24 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4201:9721:3d78:bb14:8d21:4012]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v7V6sL8X013894 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 31 Aug 2017 06:54:22 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9721:3d78:bb14:8d21:4012] claimed to be mb.local Subject: Re: Intermediary-assisted retransmission at layer(s) below 3. To: Jana Iyengar , Roberto Peon Cc: "quic@ietf.org" References: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> From: joel jaeggli Message-ID: <407a2423-8da4-eb1b-b12c-0c22c7f8ca16@bogus.com> Date: Wed, 30 Aug 2017 23:54:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Thunderbird/56.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:54:27 -0000 On 8/30/17 22:52, Jana Iyengar wrote: > Welcome back from the dead, Roberto! You seem to have woken up in the > wrong company, but still ... > > I don't think we discussed this specific issue, but I believe (and the > chairs can correct me if I'm wrong) that the general issue of explicit > signaling to intermediaries is largely out of scope for the wg. The wg's > scope is limited to "consider the impact of the protocol on network > management practices", largely because parallel efforts (SPUD, then > PLUS) were going after the signaling to intermediaries in a more general > fashion, and partly because this discussion ends up being a massive > rat-hole of never-ending agony. Again, my opinion, others may disagree. As someone who encouraged that language to be included, my concerns were that the properties of a "flow" not become so opaque that hashing became ineffective both on ECMP Paths orLAG bundles, and similarly that ipfix would still be able to distinguish between flows. State-awareness with respect to the forwarding path is my view incredibly expensive and not desirable any time significant scale is involved. > That said, there have been a slate of recent discussions on exposing > some amount of connection info to middleboxes, particularly to allow > them to passively measure RTT, but that's not the issue you asked about. > > > > On Wed, Aug 30, 2017 at 1:02 PM, Roberto Peon > wrote: > > A recent email from Christian Huitema about congestion related > things got me wondering if we’d discussed signaling to > intermediaries about whether or not they’re supposed to help with > retransmission. Has that discussion happened yet?____ > > __ __ > > -=R____ > > (Roberto Peon for those who don’t know yet ;) )____ > > From nobody Thu Aug 31 00:06:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696B713201E for ; Thu, 31 Aug 2017 00:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8VclipqFYJX for ; Thu, 31 Aug 2017 00:06:00 -0700 (PDT) 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 94114132144 for ; Thu, 31 Aug 2017 00:06:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.41,451,1498546800"; d="asc'?scan'208";a="224948752" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 30 Aug 2017 23:43:18 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 31 Aug 2017 00:05:40 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1263.5 via Frontend Transport; Thu, 31 Aug 2017 00:05:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XA9tE4NWrn84134tYlkFcUeiXSHNNc23JSaO8hgmo6Y=; b=nN0qLfCflAuAWHx/gtSoj/DQuw+oT8LK8sNpyTrXCc+TtAYr32fJzzvzl8oNiYd35qnW+BRYtHYlpypGCjgVuCSm4okNu7aY2jV9dtHxBzRYJEulzpNQRCCPJq92CDUmp0PzIrnBNVd8APfk7WBjukzq2w+JtCZ5WCUGg3eotmQ= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB452.namprd06.prod.outlook.com (10.141.202.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.10; Thu, 31 Aug 2017 07:05:40 +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.0013.012; Thu, 31 Aug 2017 07:05:40 +0000 From: "Eggert, Lars" To: Christian Huitema CC: "quic@ietf.org" Subject: Re: Congestion Control Questions Thread-Topic: Congestion Control Questions Thread-Index: AQHTHcsWoFDSvwSppUG5YTqKQQV+WqKVeT0AgABBtwCABBAkgIAAODeAgAAFuQCAAWP8gIABMCyAgABpgQCAAENFAIAAyYmA Date: Thu, 31 Aug 2017 07:05:40 +0000 Message-ID: <43380043-464F-442E-B285-DF2B3D77DC09@netapp.com> References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> In-Reply-To: <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: 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; BLUPR06MB452; 6:axdD7WVVYLrbShxsbUOHkBtnohDVDfOUH6FifO+nerCkDW5FnNNZ3QiyFk19hrS3CRMnJJokEix/qKHtFzIItOnuYnRyabZSyYydgNN8v01vOYPKJLtbz2J9H9fWFtryQ8bb9lJXnYU0ZgCwIL2F+A1fWAxtyzWGUuzNPg4Rqqfu3m+piBWp65aNeQSjbnVueppIwscdLCqY9MXmD/8iYS9M83VDOqEyQiHq6Dg1rLxnaPmABeZWJChVQEDyJi3enlbl744tpsz2qfLbu2wUA9Vsz34Jqbbw6Uyns8G9tYVisVEIGZirdcQQGYMOU+jEqHsToE1utY9D0/XPO/+BMw==; 5:kPZr+1h+EehDNhoMWDl3BSKrKac2fS06JuYS5kAZG5dUMGiQ8VSqRnbX/wkHoE2Oar8U8+rqqnyuaN4x/wdBXqPYi7mNeh5em418e9zfnQU0PTgNIn6+uqjglJGN8s96m+h7pcJHjQhhU4ogD7Cc5Q==; 24:IcRXoqxg1SYVFiyz35bN6vHdFmA4Ev7Acj69xxOBPv5CSVH8H9a1AQCV0ek+cKdCGzMXX4sAtb1FRocvIai2y0N7AtxCZCS6OARxSJp0TOc=; 7:hOZgrrYvpWvRABR4r4YW3FYX643fNFqoVaUd6eTqo5lxUT0aK644D6TWkg6smhraue370QNtFBEeVyHhhMYTCLF0lhiTDPg4TIaocVtABlOiYSkeue/uD+Cj4DmsSML609IedhH5UPNeLW6EFB/F1Afxx9T0BHHVLd+nBpQw4AEIvDIE05An5ofMcfcuj74+CxZ0KLjNN0jWZwaOuQ+aF5r090ip8W53FS2ofTgYmfU= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e66afbef-3d75-4125-6297-08d4f03eb064 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BLUPR06MB452; x-ms-traffictypediagnostic: BLUPR06MB452: x-exchange-antispam-report-test: UriScan:(268559375225159)(190756311086443); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB452; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB452; x-forefront-prvs: 04163EF38A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(199003)(189002)(377424004)(4326008)(101416001)(6486002)(189998001)(68736007)(6436002)(575784001)(229853002)(86362001)(305945005)(99936001)(3660700001)(53546010)(7116003)(3280700002)(7736002)(5660300001)(36756003)(6506006)(25786009)(50986999)(478600001)(14454004)(105586002)(81156014)(102836003)(6116002)(50226002)(106356001)(6306002)(3480700004)(53936002)(33656002)(2906002)(3846002)(81166006)(6512007)(110136004)(76176999)(97736004)(2900100001)(99286003)(4001150100001)(57306001)(8676002)(966005)(93886005)(77096006)(66066001)(83716003)(8936002)(2950100002)(6916009)(6246003)(82746002)(562404015); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB452; 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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_63248174-9C45-47AD-8F46-6E8B7DAB96FB"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2017 07:05:40.1902 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB452 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, 31 Aug 2017 07:06:02 -0000 --Apple-Mail=_63248174-9C45-47AD-8F46-6E8B7DAB96FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-8-30, at 21:04, Christian Huitema wrote: > I can think of cooperative schemes between the peers. For example, the = receiver has a good idea of the packet reordering properties of the = network, how long can an out of order packet be delayed. One can imagine = the receiver passing that information to the sender in a special frame, = for more efficient recovery. The receiver could also observe properties = of the received stream such as bunching of packets, or some clever = statistical analysis that we have not thought off yet. That too could be = passed in a special frame. The peers could also negotiate a lower = priority congestion algorithm, e.g. using LEDBAT instead of New Reno. You should read "Re-architecting datacenter networks and stacks for low = latency and high performance", which you can get to by searching for = "NDP" on http://conferences.sigcomm.org/sigcomm/2017/program.html and = following the link there. (The ACM DL has this really crappy = referrer-based open-access system.) That paper just won the SIGCOMM best paper award. It's of course about = datacenters, but the idea of receiver-driven congestion control and = loss-recovery is pretty central to its idea. (And to a lot of the = information-centric networking architectures, but they are further from = the current Internet model.) Oh, and make sure you watch https://youtu.be/BO0QhaxBRr0 before reading = the NDP paper :-) Lars --Apple-Mail=_63248174-9C45-47AD-8F46-6E8B7DAB96FB 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----- iQIcBAEBCgAGBQJZp7U/AAoJEFS1wwm/cMFXHjwQALKP83aOyFMTNp7u2vm3T9Ud ioJOPmG8oYI8TohhmNOKG2Ut6V6xL04dIsXAJnijB1xJ7+T2bkoniNZnyksDrHVu tK7la/3s46/plu3IxnaiRBiL/BzGQsrS/KFiUHa+MWbllw4LQ+wXBo2bKC9qfcmq oPEsDjmhg8hgUeeQVTKjY6qB3TskvbRz0OV+3c3ZfWKPrIUXeG6Y/2S99h+bVIHA 3/z2E83HBRrl627DmAnJlQ/7BjUGhNTPpGur4kt8BI/fDSOt2bnfMnlx7o3Iv2Gt 78DjAcEZMWyiWwaAui7VfReubPfIiK6MeMBPVobSA2BXfqQx/PBi1vyMdOhv9pgV ogNbaP2G3yAhhWXVny7mSEk7+W1Z9GDe7pTrIYMICBEMlBadpHA3zGDw5UsE4uei ozGyx20H0jTDIXlLrJoJQE8zzFhuN/tTSGlOd9uTgn3+BlGaLezUH9AWaSo81fwV 94PW8Ce7J/qR0kvRs77efAh7eaCdFLcCBbT7gV9IhhAPiWvdtytBWDbmORXnZqHo uzMcMo+QKV1gc5aHtdZ4gr9aND/wIslRiqC71q56meuiLGEt3vyK36fDZvWv3Dhj jYEJrgO//SEjg3m5fiFA+fUfJdvQnRbPVPiVeMfvZt41577lC5Y3qvAZfYzfSQLb GkzF9XgGneQOHp7dtHFk =Td4e -----END PGP SIGNATURE----- --Apple-Mail=_63248174-9C45-47AD-8F46-6E8B7DAB96FB-- From nobody Thu Aug 31 03:50:22 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEBE1321A5 for ; Thu, 31 Aug 2017 03:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PGVY5puo4yU for ; Thu, 31 Aug 2017 03:50:17 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 325FE13235C for ; Thu, 31 Aug 2017 03:50:17 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id h127so1359043ywf.3 for ; Thu, 31 Aug 2017 03:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P97Bpn9bhPK+6AoBAMnms+VrtcPv9i8RPX2oSlyaKBM=; b=fvR8aD7k8pcBTxvVuiJKd+WfBGBQoeqbHisSkvJDAFIyOjkfp2aF4oz21zwbghpLto AJdp2gSYiaIcTKNtq2r6SiGSj6fmeCo33BnbO0au56NXT7gLDkC26YzPigNlbpMKd83K GMiUcY6UIqXlqK7P1H98MURjmbwuX1UTVwg/Adv0gtnFwSDuVPFKAV77kUhlXOMlhIHi sqg/IGk5/ouyj+EAOzthp7vbGlhYyUIHEUSK2sgfpflz1gUckaB98RdLow9ZEZ0eJ8E4 bdtZ4olMTD1QsZycf6YBIeU8lwUIhO2jScRWNuaypkN21MlC9i3LlZRun+aw0Q5gcIiY BMyQ== 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=P97Bpn9bhPK+6AoBAMnms+VrtcPv9i8RPX2oSlyaKBM=; b=ZheHKQwycUs1SLUi3xkL3IN+4309Rbdhvwdo6M70D10kIRKNKxM9/6YK+mkQ14aMZ3 vkLZPlq+ECc6chRHFMrlXYMwF1ZqKNmZFOztwrzOryEDaKfGQ7l9IScjtkum67KyuR43 9MgwnPEmZtc/qFDgQiVXNJqtBmQ28+Kux2q9lYX+DjemIokJ89+QZAyJbz+M9aP6Mkeh YwxIrSh9rOpuwqaYUf+AW1AN84sZa6KI2vTUzppAbpMa7TsfE0Jzzups6NBG9w90RQoj 1q8rKPcN0sgy4ml/tsCOyhvqlqD2DwmFesCRd9ftX+qY6f3kLgNaBVSdXvAEWCxDuu4K 7LMQ== X-Gm-Message-State: AHYfb5hAn4U8ix6cIrutV6gFnlM6tjRB+ZwoyPyQ5RI8g4RoqSxWFY5n S7MOCtlN3L7UCt4Vy5YgPOyvPpBhrQ== X-Google-Smtp-Source: ADKCNb4iHADbrZIF05RWRq97odMZddaC7DWnixAPrEUu1eYtFz3yzX9qtAvcNOxkAZ0oNS1BygeCEcpEkDtyoFPW520= X-Received: by 10.129.158.140 with SMTP id v134mr4257614ywg.339.1504176616286; Thu, 31 Aug 2017 03:50:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 03:50:15 -0700 (PDT) Received: by 10.37.2.148 with HTTP; Thu, 31 Aug 2017 03:50:15 -0700 (PDT) In-Reply-To: References: <355A2878-2E3A-4929-B418-0550EA61BC7C@fb.com> From: Spencer Dawkins at IETF Date: Thu, 31 Aug 2017 05:50:15 -0500 Message-ID: Subject: Re: Intermediary-assisted retransmission at layer(s) below 3. To: Mark Nottingham Cc: IETF QUIC WG , Jana Iyengar , Roberto Peon Content-Type: multipart/alternative; boundary="94eb2c0b7898e4afeb05580a68d6" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 10:50:20 -0000 --94eb2c0b7898e4afeb05580a68d6 Content-Type: text/plain; charset="UTF-8" As the responsible AD for QUIC ... On Aug 31, 2017 01:09, "Mark Nottingham" wrote: On 31 Aug 2017, at 3:52 pm, Jana Iyengar wrote: > > Welcome back from the dead, Roberto! You seem to have woken up in the wrong company, but still ... > > I don't think we discussed this specific issue, but I believe (and the chairs can correct me if I'm wrong) that the general issue of explicit signaling to intermediaries is largely out of scope for the wg. The wg's scope is limited to "consider the impact of the protocol on network management practices", largely because parallel efforts (SPUD, then PLUS) were going after the signaling to intermediaries in a more general fashion, and partly because this discussion ends up being a massive rat-hole of never-ending agony. Again, my opinion, others may disagree. > > That said, there have been a slate of recent discussions on exposing some amount of connection info to middleboxes, particularly to allow them to passively measure RTT, but that's not the issue you asked about. I think that's a bit strong. The only things explicitly called out of scope by the charter: """ Extensions that will support partial reliability, and negotiation and use of Forward Error Correction schemes, are out of scope in this version of the working group charter. """ There are of course numerous rat holes in this area, but they have more to do with extensible frameworks for communicating with middleboxes, as well as things that look like means of leaking information to them (or allowing them to exert undue control). I don't know whether configuring lower-layer "help" with things like like retransmission / FEC falls into them, so it seems premature to rule them out at this stage (although we do have to manage the discussion; we have a lot of ground to cover). One point to remember is that I haven't seen a lot of explanation as to why we'd want middleboxes to add support for something QUIC-specific, much less HTTP2/QUIC- specific. Why middleboxes would want to do that is also a mystery to me, but not one that matters until I hear why we would want them to do that. I have some willingness to listen to proposals about middleboxes(*) that are targeted more broadly, but significantly less willingness to listen to them in the QUIC working group. If this topic matters to people, I note that the BOF proposal cutoff for IETF 100 is more than a month out, although it's best not to wait until the last minute. https://ietf.org/meeting/important-dates.html#ietf100 Thanks, Spencer (*) who is the responsible AD for STUN and TURN protocol work in TRAM, so can imagine middleboxes without bursting into flames, but that's not in the QUIC working group, either Discussion of measurement of RTT and friends by middleboxen *is* off the table until we hear back from the Design Team in Singapore. Welcome back to the circus, Roberto. If you want to open an issue / make a proposal here, please feel free; I don't think we have anything that covers it. FYI, if you haven't seen it already, this might help: https://github.com/quicwg/base-drafts/projects Then again, it might scare you away. Cheers, -- Mark Nottingham https://www.mnot.net/ --94eb2c0b7898e4afeb05580a68d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As the responsible AD for QUIC ...

On Aug 31, 2017 01:09, "Ma= rk Nottingham" <= mnot@mnot.net> wrote:
O= n 31 Aug 2017, at 3:52 pm, Jana Iyengar <jri@google.com> wrote:
>
> Welcome back from the dead, Roberto! You seem to have woken up in the = wrong company, but still ...
>
> I don't think we discussed this specific issue, but I believe (and= the chairs can correct me if I'm wrong) that the general issue of expl= icit signaling to intermediaries is largely out of scope for the wg. The wg= 's scope is limited to "consider the impact of the protocol on net= work management practices", largely because parallel efforts (SPUD, th= en PLUS) were going after the signaling to intermediaries in a more general= fashion, and partly because this discussion ends up being a massive rat-ho= le of never-ending agony. Again, my opinion, others may disagree.
>
> That said, there have been a slate of recent discussions on exposing s= ome amount of connection info to middleboxes, particularly to allow them to= passively measure RTT, but that's not the issue you asked about.

I think that's a bit strong. The only things explicitly called ou= t of scope by the charter:

"""
Extensions that will support partial reliability, and negotiation
and use of Forward Error Correction schemes, are out of scope in
this version of the working group charter.
"""

There are of course numerous rat holes in this area, but they have more to = do with extensible frameworks for communicating with middleboxes, as well a= s things that look like means of leaking information to them (or allowing t= hem to exert undue control). I don't know whether configuring lower-lay= er "help" with things like like retransmission / FEC falls into t= hem, so it seems premature to rule them out at this stage (although we do h= ave to manage the discussion; we have a lot of ground to cover).

One p= oint to remember is that I haven't seen a lot of explanation as to why = we'd want middleboxes to add support for something QUIC-specific, much = less HTTP2/QUIC- specific.

Why middleboxes would want to do that is also a mystery to me, but not o= ne that matters until I hear why we would want them to do that.

I have some willingness to listen t= o proposals about middleboxes(*) that are targeted more broadly, but signif= icantly less willingness to listen to them in the QUIC working group.
=

If this topic matters to peop= le, I note that the BOF proposal cutoff for IETF 100 is more than a month o= ut, although it's best not to wait until the last minute.=C2=A0


Th= anks,

Spencer

(*) who is the responsible AD for = STUN and TURN protocol work in TRAM, so can imagine middleboxes without bur= sting into flames, but that's not in the QUIC working group, either

=
D= iscussion of measurement of RTT and friends by middleboxen *is* off the tab= le until we hear back from the Design Team in Singapore.

Welcome back to the circus, Roberto. If you want to open an issue / make a = proposal here, please feel free; I don't think we have anything that co= vers it.

FYI, if you haven't seen it already, this might help:
=C2=A0 https://github.com/quicwg/base-drafts/proj= ects

Then again, it might scare you away.

Cheers,


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


--94eb2c0b7898e4afeb05580a68d6-- From nobody Thu Aug 31 09:50:47 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60030132E11 for ; Thu, 31 Aug 2017 09:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdR4qylGk9EA for ; Thu, 31 Aug 2017 09:50:44 -0700 (PDT) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 030FC132CE7 for ; Thu, 31 Aug 2017 09:50:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3xjpKG4R4Gz15N77; Thu, 31 Aug 2017 18:50:42 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5K1WHdSh1Ve; Thu, 31 Aug 2017 18:50:41 +0200 (CEST) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 31 Aug 2017 18:50:41 +0200 (CEST) Subject: Re: Congestion Control Questions To: Christian Huitema , quic@ietf.org References: <87ba9bb8-62f7-4d80-2c6e-ab818b34ab01@huitema.net> <983C9D8E-0540-46D1-A4DB-0F6421568AD5@in-panik.de> <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 31 Aug 2017 18:50:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <9751d270-6167-ce92-4ab9-b9b0f0b8aff6@huitema.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 16:50:46 -0000 Hi Christian, first two quick comments: - delaying ACKs and potentially negotiating about it is under discussion in issue #230 - using e.g LEDBAT is from the transport point of view after all a sender-only decision because it's the sender that need to implement a way to decide when to send out which packet. If the sender needs additional information from the receiver which scheme should be used that should probably be communicated in the application itself. Having that said of course there is theoretically the possibility to implement every algorithm or even parts of the algorithm on each side. The only thing that changes is which information you need to send forth and back between the sender and receiver, e.g. the receiver could just tell the sender continuously the sending rate. However, in quic I think we already decided which information to send, namely all the information available in the ACK frame (+ ECN information where the format is still tbd). And therefore the exact implementation of a congestion control algorithm is a sender-side decision (with an interface to the application to configure the algorithm that should be used). Mirja On 30.08.2017 21:04, Christian Huitema wrote: > > > On 8/30/2017 8:03 AM, Spencer Dawkins at IETF wrote: >> Anything else? :-) >> > > I can think of cooperative schemes between the peers. For example, the > receiver has a good idea of the packet reordering properties of the network, > how long can an out of order packet be delayed. One can imagine the receiver > passing that information to the sender in a special frame, for more efficient > recovery. The receiver could also observe properties of the received stream > such as bunching of packets, or some clever statistical analysis that we have > not thought off yet. That too could be passed in a special frame. The peers > could also negotiate a lower priority congestion algorithm, e.g. using LEDBAT > instead of New Reno. > > All this is of course speculative. And maybe it points to the need for a > simple extension mechanism, so we can experiment with this sort of things. I > could think of: > > * defining an extension ID as a 32 bit number; > * adding a supported extension list in the transport parameters, with an > implicit negotiation, > * adding an extended frame format, starting with a length and a 32 bit > extension ID. > > But to come back to your original question, we can certainly start by > assuming that congestion control and recovery algorithms are sender only. > > -- > Christian Huitema > From nobody Thu Aug 31 14:08:18 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970F2132E26 for ; Thu, 31 Aug 2017 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s3Tr1EPjVKI for ; Thu, 31 Aug 2017 14:07:56 -0700 (PDT) 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 6D9E1132707 for ; Thu, 31 Aug 2017 14:07:56 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id y15so2050935wrc.2 for ; Thu, 31 Aug 2017 14:07:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=EDSsPvUVCqaj96HYFeqUMxZMfEnT+jBfyVawKsTlozA=; b=sDqLhy8jaHQIDm+JSFcrIJuhfu8jJwwunUysdqgTAFDp1wg4JZYviumlgStfOQt54n zNEMfXGUgfxJKSI00u0m7/thY+QZjgGk/bU7CqBFmo9Nxvmtsq6zHKZNVpw5lP6/kvrY SaiyJFwUKkpY4jg3W1g9+iI0AVaekwg+k4HVwEoCtBmJhA47Z/nHcqDPpg3VTuZb3wLT E3JDRwF8Kuws+8ku2idCUdt3HG6zkyeNho1m7hudL50soMM4pG6uimsgLAd+ck9Y7wSh 1MlK4DEk3OQF6jIjsSyUbYxKaZFTwrcgxydcIOS4Uh+eQftELsKQC7/OD06DCboRFN0m lN/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EDSsPvUVCqaj96HYFeqUMxZMfEnT+jBfyVawKsTlozA=; b=XOWBgz7OoWjtjfKQT4h2GShlePqGztcgxW4Cz4YYIZa649K5hBgvnrMLAuG4ABrN8Y FQydflEN1W/jmlmBeLKtH5u9ilAADvA1hZ/4V13AJqxSI5+bdPllcmvR3riZpn3YFgkX 7cTSG0AN9SSlUx7tkIXF1Ve3L4sAN2p3XY9iASE+aLu92sBS6dSZfZ/jvihAtmoMMBVO fNeEZZXdWMbNn7vBKgQhxy3hSdFekgnhboyAfk7D5V9EyOu34/PGWy7qacPz5rUtmtd/ lHYzeNWaRtXC7R4mylZDkbFxWUE2PS+5LSFZ5/0YzMYsjpeCrQOwWITGpa1V8GowSji6 sFig== X-Gm-Message-State: AHYfb5g2/TQDmSBdKmYj9H8xGiZiJ/fuQvx2yw5KRwRseCgBTwGqj+r+ g6KhyegQQMQkBJn7txR7TPQck1mgLXR9 X-Google-Smtp-Source: ADKCNb7e+VAuW88ZkG/RBkbb+TftQ18iLbgH128ktKhWtVFQ6IsjygOaKeu9/Rqt81gko0UhkeoJToxKdpoQUSreNX0= X-Received: by 10.223.196.12 with SMTP id v12mr3692570wrf.17.1504213674760; Thu, 31 Aug 2017 14:07:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.185.56 with HTTP; Thu, 31 Aug 2017 14:07:54 -0700 (PDT) From: Martin Duke Date: Thu, 31 Aug 2017 14:07:54 -0700 Message-ID: Subject: Ack Delay field To: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0828406cc0207b05581309dc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 21:07:58 -0000 --089e0828406cc0207b05581309dc Content-Type: text/plain; charset="UTF-8" Is the 16 bit mantissa thing used in the ACK frame in network order. That is, do I pretend the bits are an integer and rearrange the bytes accordingly, or are the bits specifically laid out as described in the spec? --089e0828406cc0207b05581309dc Content-Type: text/html; charset="UTF-8"
Is the 16 bit mantissa thing used in the ACK frame in network order. That is, do I pretend the bits are an integer and rearrange the bytes accordingly, or are the bits specifically laid out as described in the spec?
--089e0828406cc0207b05581309dc-- From nobody Thu Aug 31 14:28:04 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB42D13248B for ; Thu, 31 Aug 2017 14:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmI0o9ddhCYo for ; Thu, 31 Aug 2017 14:27:46 -0700 (PDT) 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 4CAFA126B7E for ; Thu, 31 Aug 2017 14:27:45 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id f99so6275325ioi.3 for ; Thu, 31 Aug 2017 14:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ROd+/py8FbaMCYwK3lvWZf0EJewk+y8bos6yrMVBhdo=; b=vOnmMGcfCfXWYYRg4SXykVxyHUM8LWHaNRp7vN+7KZUy8M8IV03b7m07ngPYY6yRB/ TKtZRixPRQwRm0+7wVF4UVdhMJRJpicD2+XkN6MCp3R67zNnsOEeemWSA3UFYFCeyFYx mbLBy4CZsc5VHMwGjQMu+vBnlwkGsxg7jzwHIS/GnHkbvtTVtZZfdkYruQtxwXA0erGk HSWLKGnosn/q1J3wne3mXyz3ziphv7xYRQ5uS2BpHWaKhoGM+J5gLQl7MlWPQvoXdonJ UzMtmo+aRwzdp2stC+DWXJKEVDCtc/a5hEgvfGvOuOUnaFsoXCghZ1XpwY78IbDL5qaK VVag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ROd+/py8FbaMCYwK3lvWZf0EJewk+y8bos6yrMVBhdo=; b=tqscl9bjyyoK/0bpYpPHlgZMDGuerFPTJuCfPs5drhu6vVP/uwbeeQYd/IwHynuscQ XxT+ksE0un66TnmFL0uUqL+ADaMCS6DKAy0494ULTGU9clSBGICGKHHlhQHn3ruORDSK FcEYb91z5fRxPwVGELrTExxf5afDxBhcQQvQlSB5QlejIXNiAqE4BxnPEjEoloSgQluh EHoq7O+mbphzfW2WWxR6gFlnoCzueGboWqF+crYazFVCtx9VMmAR+GPX9I+gUtTwo3jK Id6NIHdbakUBuVzAWzuy9Ejc7TTVSp0bUkFRBn75mPX59yUtZePRfLC6O5hxqrxE1uSp Dceg== X-Gm-Message-State: AHPjjUh9HVZQ33dNjWrfC3Nlfm4z/bwRDI9dhB3Zsqdym0yTLQrXGH4s kvRnTeSJRMVea7ie1I4fCP2XNzDVOA== X-Google-Smtp-Source: ADKCNb4wjq0GVqzXvqgj/VcgPFFKEm8uhC2c9qblR418NrK3JTfCgbPe4jUkiUL+WTqeQvsAVA6bvx/LSc9t/tYB7A0= X-Received: by 10.107.47.65 with SMTP id j62mr7288659ioo.180.1504214864686; Thu, 31 Aug 2017 14:27:44 -0700 (PDT) MIME-Version: 1.0 Sender: phluid61@gmail.com Received: by 10.107.38.70 with HTTP; Thu, 31 Aug 2017 14:27:43 -0700 (PDT) Received: by 10.107.38.70 with HTTP; Thu, 31 Aug 2017 14:27:43 -0700 (PDT) In-Reply-To: References: From: Matthew Kerwin Date: Fri, 1 Sep 2017 07:27:43 +1000 X-Google-Sender-Auth: p-3xiiUVIc45RKFdi33kydv0nS8 Message-ID: Subject: Re: Ack Delay field To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11c14504acf44a055813501e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 21:27:50 -0000 --001a11c14504acf44a055813501e Content-Type: text/plain; charset="UTF-8" On 1 Sep. 2017 7:09 am, "Martin Duke" wrote: Is the 16 bit mantissa thing used in the ACK frame in network order. That is, do I pretend the bits are an integer and rearrange the bytes accordingly, or are the bits specifically laid out as described in the spec? I read the 16 bits into an integer (i.e. changing endianness), then masked the low 10 bits. That might just have been complete lack of imagination on my part. I've also never got my code to a point where I can test interop. Cheers -- Matthew Kerwin --001a11c14504acf44a055813501e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 1 Sep. 2017 7:09 am, "Martin Duke" <martin.h.duke@gmail.com> wrote:
Is the 16 bit m= antissa thing used in the ACK frame in network order. That is, do I pretend= the bits are an integer and rearrange the bytes accordingly, or are the bi= ts specifically laid out as described in the spec?

= I read the 16 bits into an integer (i.e. changing endianness), then masked = the low 10 bits. That might just have been complete lack of imagination on = my part. I've also never got my code to a point where I can test intero= p.

Cheers
= --=C2=A0
Matthew Kerwin
<= /div> --001a11c14504acf44a055813501e-- From nobody Thu Aug 31 14:28:38 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE88E1252BA for ; Thu, 31 Aug 2017 14:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.733 X-Spam-Level: X-Spam-Status: No, score=-0.733 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVhAIc3C3YA4 for ; Thu, 31 Aug 2017 14:28:35 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 87715120720 for ; Thu, 31 Aug 2017 14:28:35 -0700 (PDT) Received: from mail-lf0-f47.google.com (mail-lf0-f47.google.com [209.85.215.47]) by linode64.ducksong.com (Postfix) with ESMTPSA id E347E3A01B for ; Thu, 31 Aug 2017 17:28:33 -0400 (EDT) Received: by mail-lf0-f47.google.com with SMTP id y128so3176129lfd.4 for ; Thu, 31 Aug 2017 14:28:33 -0700 (PDT) X-Gm-Message-State: AHYfb5isQ5svEvl+2TDeukyiMzP3Cz+wb5EynBPowKP1KGDVlZnXw/fK rd8SG4Mu9FpAAzSdnPvsLj2XEwLu1Q== X-Google-Smtp-Source: ADKCNb5UfspoDtnQfbJGVVHSpmW1dArp0eTjzRZOWJ0NfQE7+rnxSYcnQmebR99A0T65run+i2P1sYGhtzUywm88pho= X-Received: by 10.46.7.25 with SMTP id 25mr2746463ljh.106.1504214912424; Thu, 31 Aug 2017 14:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.225.23 with HTTP; Thu, 31 Aug 2017 14:28:31 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 31 Aug 2017 17:28:31 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Ack Delay field To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045ebac68564740558135330" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 21:28:38 -0000 --f403045ebac68564740558135330 Content-Type: text/plain; charset="UTF-8" this doesn't directly address your issue, but I want to make sure you remember that the current example in the spec is known to be wrong: https://github.com/quicwg/base-drafts/issues/109 (I somehow blocked out the long conversation from tokyo from my mind and got totally confused when doing the implementation..) On Thu, Aug 31, 2017 at 5:07 PM, Martin Duke wrote: > Is the 16 bit mantissa thing used in the ACK frame in network order. That > is, do I pretend the bits are an integer and rearrange the bytes > accordingly, or are the bits specifically laid out as described in the spec? > --f403045ebac68564740558135330 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this doesn't directly address your issue, but I w= ant to make sure you remember that the current example in the spec is known= to be wrong: = https://github.com/quicwg/base-drafts/issues/109

(I somehow blocked out the long conversation from tokyo from my mind and= got totally confused when doing the implementation..)

On Thu, Aug 31, 2017 a= t 5:07 PM, Martin Duke <martin.h.duke@gmail.com> wrote= :
Is the 16 bit mantissa= thing used in the ACK frame in network order. That is, do I pretend the bi= ts are an integer and rearrange the bytes accordingly, or are the bits spec= ifically laid out as described in the spec?

--f403045ebac68564740558135330-- From nobody Thu Aug 31 14:35:00 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B280132027 for ; Thu, 31 Aug 2017 14:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oU7gQkcP_ywD for ; Thu, 31 Aug 2017 14:34:57 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 E72591252BA for ; Thu, 31 Aug 2017 14:34:56 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id 40so2039682wrv.5 for ; Thu, 31 Aug 2017 14:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+5KlA0cogyb1VCFxwzqi2MC6R2BaAobGyB9MiiwDOyA=; b=j227C6UuuYaEM9T04DNEwQa5xdl0fUU2vmb0OthESnoH7z9zAo1ft+6lAX4zO378g5 aAk9/BZCfIqK6AWFf0Dj0wxLAnGy7UeIRWcZ4dmwxWi6tuBFFmKuRDAwi2DEYPsAy87o ecTzy82DoHaDfHGa2bLMMh+q8rXrUiAa3mmyRjVgm/g+BAB64mDZTBJIvW8ako//nJSC cJJPfnYB6g+yUSCZXkFqDMYP+iSjdkr8kw7xGxvT7a5pMqpAPPOYDrfHd8ls0a1SuXux H4N4SH1lj1J4Vshy2k2VUn9ksPGE9W3Pd2TkZi6IV1O3VFVHoiGqpIh+9+CJfBdbE0+j 1PjQ== 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=+5KlA0cogyb1VCFxwzqi2MC6R2BaAobGyB9MiiwDOyA=; b=XFYRh2APi9BTodk85TdRhUl+md6F0iB991LHqpncxYFjTlzs8j6Lxe6k266mqn+dkI 0Eso+OAHNJTWfjFY/xngcxD1/Hk/w5PIIQ2dZ/oHNEI93zb5Az7G7r7SRxBhWEKTxR2v WF1HUNlc0hnPrfzLrFxWRXmotMREul6SRP7a6yaWEGH2teq1IlH71uNzL1WBQ070lOct uoMNsCrbD5lbYfLofRRNKsOfl+5CCDXCM+lMi1CkuGP4Fm6fvfc22dmyy8Ua7xy6XLGw ZRakqZgvv4BH5Jy8dcnAQOvBEKOe0TZACRsoH4Ho/95NQ3LSkNWHmThC9ZHDUGCfq3Sj FaEw== X-Gm-Message-State: AHYfb5hK0GCUsdNfUpibsS4ZCG/OSefl8OudmuQC7rhG1U0zrjxa2zhg kjbrFMsibDlY528BmMg8JirX84xXqIHE X-Google-Smtp-Source: ADKCNb7EoKQRfsw7kn53MaHxMvuY69LP4sgaW45SNK0b04Tj6ut/eNi+9STu8iTjqXvxtfohbwty64W6sXZjo9LF7mQ= X-Received: by 10.223.134.240 with SMTP id 45mr4622071wry.49.1504215295072; Thu, 31 Aug 2017 14:34:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.163.193 with HTTP; Thu, 31 Aug 2017 14:34:53 -0700 (PDT) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 31 Aug 2017 14:34:53 -0700 Message-ID: Subject: Re: Ack Delay field To: Matthew Kerwin Cc: Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114918ca546ddf0558136a22" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 21:34:59 -0000 --001a114918ca546ddf0558136a22 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 31, 2017 at 2:27 PM, Matthew Kerwin wrote: > On 1 Sep. 2017 7:09 am, "Martin Duke" wrote: > > Is the 16 bit mantissa thing used in the ACK frame in network order. That > is, do I pretend the bits are an integer and rearrange the bytes > accordingly, or are the bits specifically laid out as described in the sp= ec? > > > I read the 16 bits into an integer (i.e. changing endianness), then maske= d > the low 10 bits. That might just have been complete lack of imagination o= n > my part. I've also never got my code to a point where I can test interop. > =E2=80=8BThat's exactly what we did. We treat the "16-bit unsigned float wi= th 11 explicit bits of mantissa and 5 bits of explicit exponent" as a unit16_t in memory, and mask out the various bits. When serializing, we write these 16 bits in network byte order, but store them in host by order.=E2=80=8B --001a114918ca546ddf0558136a22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
O= n Thu, Aug 31, 2017 at 2:27 PM, Matthew Kerwin <matthew@= kerwin.net.au> w= rote:
On 1 Sep. 2017 7:09 am, "Martin Duke" <martin.h.duke@gmail.com> wrote:
Is the 16 bit mantissa thing used in the ACK frame in network orde= r. That is, do I pretend the bits are an integer and rearrange the bytes ac= cordingly, or are the bits specifically laid out as described in the spec?<= /div>

I read the 16 bits into an integer (i.e. changing endianness), then = masked the low 10 bits. That might just have been complete lack of imaginat= ion on my part. I've also never got my code to a point where I can test= interop.

=E2=80=8BThat's exactly what we did. We treat the "16-bit u= nsigned float=C2=A0with 11 explicit bits of mantissa and 5 bits of explicit= exponent" as a unit16_t in memory, and mask out the various bits. Whe= n serializing, we write these 16 bits in network byte order, but store them= in host by order.=E2=80=8B

--001a114918ca546ddf0558136a22-- From nobody Thu Aug 31 14:35:12 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A07E132153 for ; Thu, 31 Aug 2017 14:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=litespeedtech-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vesWgLTUBIPl for ; Thu, 31 Aug 2017 14:35:04 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 F1D90132351 for ; Thu, 31 Aug 2017 14:35:01 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id v20so4057521qtg.3 for ; Thu, 31 Aug 2017 14:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xS+Kn1xx2LDOa8r9gEzt8OgImygNil9NXhLy2QJinKE=; b=PiJVFzGm3VkwyIOjxfGuJctvQQPbVHbAQYsIiwEApnF8oX45X7sXAl9xhZ1Cq97YDQ xT4mXjqq3kZSlvJTBRtRS/HuOznVKRv2kIWZ9I3wQjdkZpIJwV/Th374jWVbWIige8JG HxXT1POSbsKb4sb/6/A+r1Ion9PPyVAFMqztlrLv4HVGCIDX5Vd8vlfbAQifUADh0xP6 BcztleArd2SqsdqepZEwH3QbtFJh7L9C/DY5vcE9S0fScyARNBZ2ZiOckWHc7aJZdqU8 leoCNkTAe+PSLZZGYlahXzCjZINmQWQmn1vQcCvuJMbnKo/dk/HVHaQICm7+Qw9K3r/I fOxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xS+Kn1xx2LDOa8r9gEzt8OgImygNil9NXhLy2QJinKE=; b=F6QW2kXuHogbzeIXjyEvcRve10tuBa1RWUGWknS6jGtDp/2omeTsempsqsmBbehSUX M+3Zo+/mcnJD+oDTB0FY5KdnKCfbVSn6QkGsqmcaSd4iWV3rpukjqXsaGGy5BIyRfUOA ma8iQ7U80GNvxQxC/pFAsRwFwnLhu7toqBbWJxAHJIei5/Nz/ED29ycfgOoqm+pMShwg xLGm5enUqLOoVkDUGp+clcxGFhRbxBPN+xv60Ey62//v0bW2Khdbn89uGy1mPkaxoPHh PaGS8zPkwyDLg4GVnbREl8AEwVRSY9ycMRY+R0Jw3Jiy+2+YDL1f77n8EhXqIeIoYmk4 gIRg== X-Gm-Message-State: AHYfb5h819eXkfjX4e/R0gEjgjQaVylwAYPe87ttB8OVxoPidXuHR7/W sAk5jLzk3fTp1ewSI6Q= X-Google-Smtp-Source: ADKCNb67zINabmf0tjU6NeCFoAvg7ynvKQmTb747Ek9syWKDBLJN90H5lIwN57NOH+McjKak9FipKQ== X-Received: by 10.200.8.169 with SMTP id v38mr9624885qth.85.1504215301212; Thu, 31 Aug 2017 14:35:01 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id d187sm6022819qkg.91.2017.08.31.14.35.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 31 Aug 2017 14:35:01 -0700 (PDT) Date: Thu, 31 Aug 2017 17:34:36 -0400 From: Dmitri Tikhonov To: Martin Duke Cc: IETF QUIC WG Subject: Re: Ack Delay field Message-ID: <20170831213436.GA18477@ubuntu-dmitri> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 21:35:06 -0000 On Thu, Aug 31, 2017 at 02:07:54PM -0700, Martin Duke wrote: > Is the 16 bit mantissa thing used in the ACK frame in network order. Judging by Q040, which implements IETF-like STREAM, RST_STREAM, and ACK frames, yes. - Dmitri. > That > is, do I pretend the bits are an integer and rearrange the bytes > accordingly, or are the bits specifically laid out as described in the spec? From nobody Thu Aug 31 14:39:54 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89AE132223 for ; Thu, 31 Aug 2017 14:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG4xY2v7sAuR for ; Thu, 31 Aug 2017 14:39:50 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 069A81252BA for ; Thu, 31 Aug 2017 14:39:49 -0700 (PDT) Received: from mail-lf0-f43.google.com (mail-lf0-f43.google.com [209.85.215.43]) by linode64.ducksong.com (Postfix) with ESMTPSA id 684D03A0A2 for ; Thu, 31 Aug 2017 17:39:49 -0400 (EDT) Received: by mail-lf0-f43.google.com with SMTP id d17so3319752lfe.1 for ; Thu, 31 Aug 2017 14:39:49 -0700 (PDT) X-Gm-Message-State: AHPjjUjHC/T9aA7Pbjt2kDyuX9QSQC0EXnqwKlPxhoa2yqR2iFSCQSOI M0HfQZDVTMQ5sfhd2RSvupdWe5WwZw== X-Google-Smtp-Source: ADKCNb5auRKH4FWJ4xOWeOWGsZsU1iCkWcQYI9F8VmZ+0ZpuUt8xU+IPXursIhPmmkoCPgjysl6b1/lhwKzDEvRhQxI= X-Received: by 10.25.18.227 with SMTP id 96mr3163701lfs.75.1504215588188; Thu, 31 Aug 2017 14:39:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.225.23 with HTTP; Thu, 31 Aug 2017 14:39:47 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 31 Aug 2017 17:39:47 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Ack Delay field To: Ryan Hamilton Cc: Matthew Kerwin , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="001a113f9058ccbaf30558137b9c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-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, 31 Aug 2017 21:39:53 -0000 --001a113f9058ccbaf30558137b9c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =E2=80=8BThat's exactly what we did. We treat the "16-bit unsigned float wi= th 11 > explicit bits of mantissa and 5 bits of explicit exponent" as a unit16_t = in > memory, and mask out the various bits. When serializing, we write these 1= 6 > bits in network byte order, but store them in host by order.=E2=80=8B > > me too --001a113f9058ccbaf30558137b9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= =E2=80=8BThat's exactly what we did. We treat the "16-bit unsigned= float=C2=A0with 11 explicit bits of mantissa and 5 bits of explicit expone= nt" as a unit16_t in memory, and mask out the various bits. When seria= lizing, we write these 16 bits in network byte order, but store them in hos= t by order.=E2=80=8B

me too

--001a113f9058ccbaf30558137b9c-- From nobody Thu Aug 31 20:17:55 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14598133155 for ; Thu, 31 Aug 2017 20:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 uoK7Mb2r13ry for ; Thu, 31 Aug 2017 20:17:52 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8BB132E5C for ; Thu, 31 Aug 2017 20:17:51 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1dncSl-0001qa-KM for quic@ietf.org; Fri, 01 Sep 2017 05:17:49 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dncSi-0004QN-Cs for quic@ietf.org; Thu, 31 Aug 2017 23:17:40 -0400 Received: (qmail 21260 invoked from network); 1 Sep 2017 03:17:39 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.29]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Sep 2017 03:17:39 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <1b2332bb-9f1f-22ba-c465-e31601439c6e@huitema.net> Date: Thu, 31 Aug 2017 20:17:37 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4440138385994E604526B407" Content-Language: en-US Subject: Re: Ack Delay field X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWwktM+UPDyXniaU9ttNgkND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23UY/mVRzAZ54k0bMuT/J74vzLO0shYmHPpSXw 3S8A3AqhVMKDtr2DACb2QogKNnHwYOEkjsX7F8KmpUaZQHV+SZbCEQkE+Ttak7yNVmHZUfi2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpPLwHqwRykc1ByOUA6hOga/fPQj1kOyxNFg33kI1TaC7CpXSTy88 yKXT59k+LMPEe9c8xjBM0P6LIjoX8H814Oypb0YnYvmU5PphG8LogcC6a8Mrc8quJ4btPpt/2FLu FENuK6ldck0juAg+FVtv+IOo4y6frMgdTo7c9I9ngwHJYd/jKzjiuDYHz/0WYr1rUy6ggDjF/JYa A95R4z1aC/MrWVhqgmvP+ZFPzpqryle+fOag26sJVU91vDlVZmVFHoHOPocIAQXCXdbljHVoU+TL v3Mz7HKrwpxO8UZg9F+1Q0pmjPr72MdmVGuYwG34EPPZ3XKOQW/bgFNkq8wJDYSBnu0lkZpYa9z3 uTkingfVyrFWzpgoFwAM9mR6li7gxnB/3WCT/ywxqGyDcX7ymo81pn6M7II0pBZMP8Q2yl7HZ8cC 5NCzOtKFVG2OgcPUMeKVse1sVhWabI0/+PN3sILCmP4sL9m2Y1BvIAo6egCemilw+ioChJ5n7tfm eH2kchap9/JGM7LGxIWWH81zEGo= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 03:17:54 -0000 This is a multi-part message in MIME format. --------------4440138385994E604526B407 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 8/31/2017 2:39 PM, Patrick McManus wrote: > > > ​That's exactly what we did. We treat the "16-bit unsigned > float with 11 explicit bits of mantissa and 5 bits of explicit > exponent" as a unit16_t in memory, and mask out the various bits. > When serializing, we write these 16 bits in network byte order, > but store them in host by order.​ > > me too > Same here. Maybe worth saying so in the spec. -- Christian Huitema --------------4440138385994E604526B407 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 8/31/2017 2:39 PM, Patrick McManus wrote:


​That's exactly what we did. We treat the "16-bit unsigned float with 11 explicit bits of mantissa and 5 bits of explicit exponent" as a unit16_t in memory, and mask out the various bits. When serializing, we write these 16 bits in network byte order, but store them in host by order.​

me too

Same here. Maybe worth saying so in the spec.
-- 
Christian Huitema
--------------4440138385994E604526B407-- From nobody Thu Aug 31 21:00:36 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737681330A8 for ; Thu, 31 Aug 2017 21:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi_AnuWChBzN for ; Thu, 31 Aug 2017 21:00:20 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F1F132F23 for ; Thu, 31 Aug 2017 21:00:20 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id r203so12461615oih.0 for ; Thu, 31 Aug 2017 21:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0wkACV6P5I6H5FfkobtyPguTXwZ1WjUWf4BFwGoA28M=; b=En1yIrBnPAz1AfWzjPvkkCS3YruolGo3n8lLvCxIwh2AmjV6vYksvOqUZ4gkta1uHS 7WKZPSAHeXfuodYKK0O5usz59i8nemUOPGey3tq50BA3l2LHu8ZCClyXr9eKfwUoK4g3 4QqGk7qLE7jIfnj4zPYDNZtWUYi1YqPKEAb72HVxZwd6wTsBH+4WxBK6bmAF+usfvD2d QZzlq7H8RD/j65ixOEY+AvNr89Zih6faGmxycpNL8Cl4aKikYklazMWzQiT5JDLGVQjV e40fik7IqmoInsPWsRzcjYxcRbDe51X4esmaKRq1+G9fEv7nKEWvyx1IKSaLPbF1+YtE mQ3A== 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=0wkACV6P5I6H5FfkobtyPguTXwZ1WjUWf4BFwGoA28M=; b=r3EzYfwuMPTnamMWsybn+K51ncpevZnsxcra80mhoXGONHL+TUdJ4kc9fTQYO+guQX 5LcV2ymQxa2Iw3eO4Ja7gZ/sFpyLoJedJ0ykJpa6U8sTco5qi7SfDQnN3UsBEme73rxm QkqgsAZ8Yq/N/cP1EEmiJSfrg6oca81i9Xwexa6VLWld3jK3EPRWaKiQtZvPcUKReaZQ /mAOt8JUguWrCGvTAVvnf8gDeUEmatFp3HuoFrQWI/qIry7O8eM4l0TxsDjZM1xf5We+ bdm78SCBPJ+Hr/dmq6omPKsLkQe/LWIlvc2161UiMHN3zTA936+LPCq98sGcsKIlwEaX 3aNQ== X-Gm-Message-State: AHPjjUiOi6p2CTsiRpYIl50kBKbOF2Sts7E/pwy/QtH759oPZu0jdtK0 McqSv5gDCUi3vRVg0ZBvovecg80i8pAq X-Google-Smtp-Source: ADKCNb5mupySABfUx/vdE1xkXz6dVc4hw2DLNsNEp2ESyt41qxUK9eoLLZruXXMOKPp8bPKCPvTO5/WanM1VxUJT/yg= X-Received: by 10.202.236.204 with SMTP id k195mr676259oih.92.1504238419854; Thu, 31 Aug 2017 21:00:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.163 with HTTP; Thu, 31 Aug 2017 21:00:19 -0700 (PDT) In-Reply-To: <1b2332bb-9f1f-22ba-c465-e31601439c6e@huitema.net> References: <1b2332bb-9f1f-22ba-c465-e31601439c6e@huitema.net> From: Martin Thomson Date: Fri, 1 Sep 2017 14:00:19 +1000 Message-ID: Subject: Re: Ack Delay field To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 04:00:22 -0000 On Fri, Sep 1, 2017 at 1:17 PM, Christian Huitema wrote: > On 8/31/2017 2:39 PM, Patrick McManus wrote: >> That's exactly what we did. We treat the "16-bit unsigned float with 11 >> explicit bits of mantissa and 5 bits of explicit exponent" as a unit16_t in >> memory, and mask out the various bits. When serializing, we write these 16 >> bits in network byte order, but store them in host by order. >> > me too > > Same here. Maybe worth saying so in the spec. We already agreed to. #109 is agreed and assigned, awaiting a PR. From nobody Thu Aug 31 21:26:30 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E481330E0 for ; Thu, 31 Aug 2017 21:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFc78jiEcZKX for ; Thu, 31 Aug 2017 21:26:07 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EDA1330DD for ; Thu, 31 Aug 2017 21:26:06 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id s62so3762046ywg.0 for ; Thu, 31 Aug 2017 21:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uMf137DUFFMrLA7veH77zlKC3FX98fzCFYFiU1hrxvE=; b=v13atUjIohsqgiGE2VWYTnjCqHbWuzTtqzd+o080c55OXhfMBpW81ppnaRcVmlzHvx zWfzal8MTI7QTbu1AaQQJbK+2YwtoqqwErwvClvFXHSf3o+0bIxDvofO3jc/rVb84Mdi 8tfqobLDZ/81pOTPfS4irZh+uwJCrTVsIJqSQPIeq7kttfG/4vL3S1WzwwopZ/7bknim 7Z/fLU3wFkNEasrp5WwQgRn2rUD6oihKHp+dPoM7QDVqKR2z7SNW8WBmvdabhkGWATEr Z40dPQh+bbKCv2yDIi+8qSxMet5sX2PWQHvsBI4W+/o7xs9UbqvpSLp88wb8HEg+Kgsp LvkA== 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=uMf137DUFFMrLA7veH77zlKC3FX98fzCFYFiU1hrxvE=; b=MZjzj9kBoH0pIDfGqfe4e81ZbWbToNpUzshhDRdO6p2CIgBEBmx1CrSjKWcsNOeFxF pt3LuOewls4TKoKq6h6NgQmmaLW6q7ER5mJCfqOGsDbWldA0+pnIATFD1Xdt6sgvQTs1 qJjLbJL3LYkNxUvGm67xhICLa/069Pjv3YJ3iZcYHo1a7brWqNHGWqA9wPaYynuHiy5p /5eoOuGyzMaLLz3+KYCEuBG2BkQ1w6n8L2BLukdMpzGHswNtldLTHzBVdzeIrpJSBkZ6 qkjBfboeI4JEKh4qcH2+OUmvjzGtrrUrHaFnFmlePvE0iz1739M9KEI+ntCGKDKi8pFi 8D+g== X-Gm-Message-State: AHPjjUiT81lqZ6WGSjozLEjZJotrH72VCX4EW5EJ1uy5YIWjV3vTOqs1 3K02quJAYOM6D4/HQzJ7XdM8fYPwU48a X-Google-Smtp-Source: ADKCNb4moeu3pG2N43dhfNVN4NV9bX7mV62INd3Jt47hcEnEQ9xaIe0Jp1TZbKNpkQ44GGMNxhSqMCuSeWsm/UdLRnQ= X-Received: by 10.129.202.3 with SMTP id p3mr554165ywi.356.1504239965676; Thu, 31 Aug 2017 21:26:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.82.6 with HTTP; Thu, 31 Aug 2017 21:26:04 -0700 (PDT) In-Reply-To: References: <1b2332bb-9f1f-22ba-c465-e31601439c6e@huitema.net> From: Jana Iyengar Date: Thu, 31 Aug 2017 21:26:04 -0700 Message-ID: Subject: Re: Ack Delay field To: Martin Thomson Cc: Christian Huitema , QUIC WG Content-Type: multipart/alternative; boundary="089e082618a4d05ee90558192807" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Sep 2017 04:26:09 -0000 --089e082618a4d05ee90558192807 Content-Type: text/plain; charset="UTF-8" Yes, it's worth saying in the spec, and I'll spin up a PR for this shortly. On Thu, Aug 31, 2017 at 9:00 PM, Martin Thomson wrote: > On Fri, Sep 1, 2017 at 1:17 PM, Christian Huitema > wrote: > > On 8/31/2017 2:39 PM, Patrick McManus wrote: > >> That's exactly what we did. We treat the "16-bit unsigned float with 11 > >> explicit bits of mantissa and 5 bits of explicit exponent" as a > unit16_t in > >> memory, and mask out the various bits. When serializing, we write these > 16 > >> bits in network byte order, but store them in host by order. > >> > > me too > > > > Same here. Maybe worth saying so in the spec. > > We already agreed to. #109 is agreed and assigned, awaiting a PR. > > --089e082618a4d05ee90558192807 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, it's worth saying in the spec, and I'll spin = up a PR for this shortly.

On Thu, Aug 31, 2017 at 9:00 PM, Martin Thomson <mart= in.thomson@gmail.com> wrote:
On Fri, Sep 1, 2017 at 1:17 PM, Christian Huitema <huitema@huitema.net> wrote:
> On 8/31/2017 2:39 PM, Patrick McManus wrote:
>> That's exactly what we did. We treat the "16-bit unsigned= float with 11
>> explicit bits of mantissa and 5 bits of explicit exponent" as= a unit16_t in
>> memory, and mask out the various bits. When serializing, we write = these 16
>> bits in network byte order, but store them in host by order.
>>
> me too
>
> Same here. Maybe worth saying so in the spec.

We already agreed to.=C2=A0 #109 is agreed and assigned, awaiting a = PR.


--089e082618a4d05ee90558192807--